No i mamy kolejny powód, żeby nie używać #PythonPoetry. Właśnie wynaleźli na nowo "reproducible build", i wyszło jak zwykle. Całkiem przeoczyli cały sens tego pomysłu, i zaczęli wymuszać znaczniki czasu na plikach w archiwach źródłowych. A do tego, jak SOURCE_DATE_EPOCH nie jest ustawione, to zamiast wyłączać tę funkcję, wymuszają znacznik zerowy.

Tak więc wszystkie archiwa sdist tworzone przez Poetry i wrzucane na #PyPI dziś mają daty z roku 1970, co powoduje przypadkowe problemy. A najbardziej absurdalne w tym jest to, że ZIP nie obsługuje takich dat, więc kiedy tworzą archiwa binarne wheel, to nadpisuję tę datę inną przypadkową datą 🤦.

https://github.com/python-poetry/poetry/issues/10083

New reason not to use #PythonPoetry just dropped: they reinvented "reproducible builds", poorly. The problem is, they missed the purpose of reproducible builds entirely and they use it for source distributions too, and when you don't use SOURCE_DATE_EPOCH, they force all files to epoch (as in timestamp 0) instead of leaving them alone.

Like, all source distributions created by Poetry and uploaded to #PyPI now have 1970 timestamps that, simply speaking, break stuff. The most absurd thing is that ZIP can't handle that timestamp, so they override it and use another date for wheels 🤦.

https://github.com/python-poetry/poetry/issues/10083

#Gentoo #PEP517

Wow, #pythonPoetry v2 sure introduced many breaking changes. They outsourced `poetry shell` (a very important and IMHO core command for entering a shell with the virtual environment activated) into a plugin (wtf 🤨) that you need to provide separately.

That poetry can't pin itself bit me quite a couple of times with the v2 transition. They also changed the behaviour of the -C flag (running a command from another directory), royally fucking up a complex Makefile I then had to debug 😩

#Python

Nieudany poranek z nowymi wersjami paczek Pythona dla #Gentoo:

1. Projekt, który zwlekał z wydaniem nowej wersji z poprawkami bezpieczeństwa 4 lata, w końcu wydał nową wersję. Oczywiście, jak się robi jedno wydanie na 7 lat, to definitywnie trzeba w tym czasie zmienić system budowania na zepsutą hybrydę #PythonPoetry + #setuptools.

2. Inny projekt wydał nową wersję z popsutymi testami. Na głównej gałęzi działają — widać nikomu nie zależało, żeby przetestować gałąź z wydaniem.

3. Właśnie odkryłem, że kilka paczek na nowo zaczęło używać przestrzeni nazw pkg_resources — a byłem przekonany, że pozbyliśmy się tego gówna lata temu! No i oczywiście, że #Google. A że teraz pkg_resources jest oficjalnie przestarzałe, rzuca ostrzeżeniami, które psują testy w innych paczkach.

A z rzeczy pozytywnych: w redis-py sypie mi się test_lolwut.

#Python

A bad #Python bump morning in #Gentoo:

1. A project that couldn't be bothered to make a release with a security fix for 4 years finally made a release. Of course, if you make one release in 7 years, it is definitely a good idea to replace your build system with a broken #PythonPoetry + #setuptools hybrid.

2. Another project made a release with a bunch of test failures — that were fixed in "master" branch already at the time, but I guess nobody bothered testing the release branch.

3. Just discovered that a bunch of projects are using pkg_resources namespaces again — and we were supposed to have gotten rid of them years ago! Of course it's #Google. And on top of that, since pkg_resources are now throwing deprecation warnings, they are indirectly breaking random other test suites.

On the positive side, test_lolwut is failing for me in redis-py.

:python: Has anyone solved the issue of using poetry to release (to pypi) two different set of packages for either the same name of package, or perhaps with different names?

My issue is that I want to release tdsr (the terminal screenreader) onto pypi, but on mac, it requires pyobj which can only be built on a mac. On Linux, pyobj is not required. I'm down to have a second package called something liketdsr-mac, but is there a way to tell poetry to have optionally installable content?

I've tried this in my pyproject.toml:

[tool.poetry.group.macos.dependencies]
pyobjc = "^11.0 ; sys_platform == 'darwin'"

[tool.poetry.plugins."tdsr.application.plugin"]
"tdsr" = "tdsr:main"
"tdsr-mac" = "tdsr:mac.main"

but when then doing poetry build or poetry publish there's no way to specify the macos dep group, so it only really works for local install. This project is already locally installable though. I want to release it, so I have an easy way to install it across all my machines and can regularly test screenreading for my cli projects.

#python #pythonPoetry

Poetry broke `poetry shell` it has been moved to a plugin and
`eval $(poetry env activate)` doesn't work.

#pythonPoetry #poetryPython

I help maintain projects that use uv, PDM, and Poetry. It is really great to see with Poetry 2.0 released last week, that the pyproject.toml format from PEP621 is starting to come together across the tools for project and dependency specification. #Python #PythonPoetry #PDM #uv

What is the correct way to get information about *my* Python package out of the pyproject.toml file? What I used to do was this:

from importlib.metadata import metadata
my_package_metadata = metadata("my_package")
my_package_homepage = my_package_metadata["home-page"]

But now I'm trying to upgrade Poetry from 1.8 to 2.0 and moved a lot of stuff from tool.poetry to the project section and "home-page" returns None all of a sudden. 🙈

#Python #PyprojectToml #PythonPoetry

#Gentoo powinno być już gotowe na testowanie przypadkowych paczek w języku #Python.

Obok #tox i #nox, mamy już: #flit, #hatch, #pdm, #pixi, #PythonPoetry i #uv. Coś przeoczyłem?

/me porównuje z https://www.xkcd.com/1987/

#Gentoo should be prepared for testing random #Python packages now.

In addition to #tox and #nox, we have #flit, #hatch, #pdm, #pixi, #PythonPoetry and #uv. Did I miss anything?

/me compares with https://www.xkcd.com/1987/

#packaging

@pawamoy @mistersql

Ignoring a <4 constraint makes sense, but the fact that a single maximum constraint means it refuses to resolve dependencies that lack a maximum makes no sense in the first place. 🤷

I've been playing with #PDM a bit as a possible replacement for poetry (with this project, even) but haven't been ready to move to it yet. It seems to be missing some convenience features that I rely heavily on - having the `shell` command launch an activated subshell that you can just exit to return to the unactivated venv state is muscle-memory for me, so I constantly end up closing my terminal. And I haven't found a way to make pdm install actual scripts/symlinks for declared entrypoints - you have to always do `pdm run entrypoint [...]` rather than just running `entrypoint [...]` after activating the shell.

I'll have to see if poetry v2 actually fixes all of the things that made me want to switch away from poetry. Maybe it won't be necessary.

#PythonPoetry

@mistersql

This was exactly the problem; thank you! I don't know how I haven't run into this problem before. Must be because I manually changed the Python dep for this project from poetry's default `^3.<minor>` to `>=3.10` specifically to avoid pinning the minor version.

This is definitely an unexpected sharp edge with poetry - particularly considering the diagnostic it gives doesn't even hint as to what the true problem is.

#solution #problem #SharpEdge #debug #debugging #PythonPoetry

New on blog: "Poetry(-core), or the ultimate footgun"

"""
I've been complaining about the Poetry project a lot, in particular about its use (or more precisely, the use of poetry-core) as a build system. In fact, it pretty much became a synonym of a footgun for me — and whenever I'm about to package some project using poetry-core, or switching to it, I've learned to expect some predictable mistake. I suppose the time has come to note all these pitfalls in a single blog post.
"""

https://blogs.gentoo.org/mgorny/2024/12/20/poetry-core-or-the-ultimate-footgun/

#Gentoo #Python #PEP517 #PythonPoetry

Switching from many years of using miniconda to poetry to manage python environment. So far pretty painless but errors in response to some bad command syntax as I learn are ugly. Putting it on 2025 project list to see if I can contribute some time to help fix some. #PythonPoetry

Python packaging discourse continues. I've recommended Poetry for backend devs and I continue to do so, but this article has good criticism on using Poetry to author (open source) libraries.

https://blog.ucodery.com/posts/the-trouble-with-poetry/

#pythonpoetry

Slowly getting the hang of #poetry2nix (packages your :python: #pythonPoetry project with :nixos: #nix). Without a more solid understanding of the nix language and packaging in general, poetry2nix is just pain when Python packages do weird things (like dependency cycles all over the place wtf adafruit?). But now with my 10th or so attempt of rejecting and retrying poetry2nix again, I can package quite some projects of mine with it. 💪

#nix #NixOS

Is Pixi + rattler-build* going to be the death of Poetry? In my limited experience so far, Pixi can do everything Poetry can do, just as easily, but has the added bonus of being language-agnostic and able to build Conda packages. Interested to hear thoughts!

*I think Prefix are working on integrating rattler-build into a `pixi build` command, and once this is finished, I don't see any advantage Poetry has over Pixi.

#pixi #PythonPoetry #prefix #packaging #python #rattlerbuild

I think I have finally™️ (for the third or so time) found myself a solution for :python: #Python development on :nixos: #NixOS that allows me to just work with #pythonPoetry et. al. as on other distros.

The solution is to pre-build an FHSUserEnv in your configuration.nix, e.g. like this¹.

When starting Python dev work, I now execute `fhs` (it's fast!), or directly `fhs -c 'poetry shell'` and everything works as expected, including #PyPI wheels etc.

¹https://gitlab.com/nobodyinperson/nixconfig/-/blob/main/fhs.nix?ref_type=heads

cc @publicvoit