#pythonpoetry — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #pythonpoetry, aggregated by home.social.
-
#PythonPoetry is yet another project that disrespectfully treats human bug reporters with #slop:
https://github.com/python-poetry/poetry/issues/10796#issuecomment-4158910681
-
-
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ą 🤦.
-
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 🤦.
-
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 🤦.
-
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 🤦.
-
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 🤦.
-
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 🤦.
-
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 😩
-
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.
-
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.
-
Poetry broke `poetry shell` it has been moved to a plugin and
`eval $(poetry env activate)` doesn't work. -
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
-
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.
-
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
-
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
-
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
-
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
-
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/
-
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.
-
CW: Strong Opinions on Python Packaging
https://blog.ucodery.com/posts/the-trouble-with-poetry/
Decided to finally write down most of my feelings whenever I find out a package I use or a package I want to help is using Poetry and why that's never a good discovery
-
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. 💪
-
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
-
In case you are wondering why #PythonPoetry is currently broken in #NixOS: Its dependency dulwich has been upgraded by accident. The commit has since been reverted, but that has not yet propagated to all channels. Keep an eye on https://nixpk.gs/pr-tracker.html?pr=307505
-
I've been facing many issues with using #Poetry (#pythonpoetry) with my #Python based #objectdetection project. I love Poetry for publishing packages, but think that #conda would be better since I have to deal with #CUDA and whatnot. Anyone familiar with a way to use `pyproject.toml` for publishing and building packages, even if Poetry isn't being used for dependency management?
For context, here's the project I'm working on: https://github.com/slashtechno/wyzely-detect
-
Learn 'any' and 'all' now, and thank me later 😉
https://www.pythonmorsels.com/any-and-all/
#code #python3 #python #PythonPoetry #dev #programming #tutorial #cheatsheet
-
@bjoernricks @lil5 @inthehands @wholesomedonut That's not very useful without explaining why you think Poetry is better. I mean, the point of having standards is that people can choose the tool that works best for them. Imposing the dogma of your preferred tool on people is bad; giving them what they need to make an informed decision is good.
Personally I still choose pipenv over Poetry for anything that doesn't need to be packaged. I like the simplicity. For things that do need to be packaged, the extra packaging-related features of Poetry do make it more appealing, although personally I have not had the greatest time with it. I prefer to use tox for environment isolation (that would be roughly the equivalent of pipenv in this case) and either hatch or setuptools as the build backend.
-
#PythonPoetry znów uderza. Nie mam już siły tego komentować.
https://github.com/PyCQA/isort/commit/f7a6b0eea57e87155a367e2490b49b40f83c3944
(kontekst: https://pol.social/@mgorny/111010749186924187 )
-
#PythonPoetry strikes again. I don't even have the energy to comment on this anymore.
https://github.com/PyCQA/isort/commit/f7a6b0eea57e87155a367e2490b49b40f83c3944
(context: https://social.treehouse.systems/@mgorny/111010747338617783 )
-
Czy kogoś jeszcze dziwi, że idzie kolejny tutek z serii "jak złe jest #PythonPoetry" (poprzednio https://pol.social/@mgorny/111010749186924187)?
Tym razem: paczka nie deklaruje sekcji `build-system` w `pyproject.toml`, więc budowanie ze źródeł powoduje użycie `setuptools`, które nie buduje poprawnej paczki.
-
Is anyone surprised to learn that yet another toot continues my series on how bad #PythonPoetry is (previously https://social.treehouse.systems/@mgorny/111010747338617783)?
This time: a package that doesn't declare `build-system` in `pyproject.toml`, so building from source triggers implicit `setuptools` fallback that doesn't build a valid package.
-
Humans can't understand the size of time spans, like millions or billions of years.
That is why we have created `poetry install` and `pipenv install -e .` so that you will feel the trillions of years vicerally.
