I am just about fed up with #poetry (for #Python development).
When it works, it's great. But when it doesn't do what you expect, it seems to be virtually impossible to determine why, and the #documentation barely scratches the surface, basically only showing the happy path.
An example that has bugged me for ages: #entrypoints set up with the [tool.poetry.scripts] configuration in pyproject.toml are sometimes silently ignored. `poetry install` doesn't set them up in the #venv.
1/x
It seems to "just happen" in some #projects. `poetry install` should set up executable scripts in the venv's bin dir for them - but it just doesn't do it. And no matter how high you crank the verbosity, it will not emit a single #diagnostic to tell you *why* it isn't doing it. At one point I thought it only happened with projects using src-layout - but I'm not so sure about that now.
Documentation? Of course there's no mention of it. It should Just Work.
2/x
Tonight's example, that finally got me to toot about it... packaging.
The #poetry documentation for #pyproject.toml describes the #include and #exclude config lists. exclude is #automagically pre-populated with the entries from your VCS ignore file, but, and I quote:
"Explicitly declaring entries in include will negate VCS' ignore settings."
Wanna bet on it? I have an entry in my .gitignore file for `docs`. I explicitly list it in `include`.
3/x
With `poetry build`, the docs #directory does not end up in the built #wheel or #sdist/#tarball, no matter what I do. I know it's picking up the ignores from the .gitignore file, because renaming .gitignore fixes the problem.
Running build with maximum verbosity gives 2.9MB of output, showing every file that is getting ignored - and not a single message as to *why* any of them are ignored.
Literally impossible to debug. Docs are silent on this, of course.
4/x
Fellow #Pythonistas, are these issues better with `#uv` or `#rye` or some other tool? I dislike the idea of having to manage Python #projects with #tools written in other languages "because Python wasn't good enough", but tools that actually work, that produce #diagnostics for #problems, and which have #documentation that doesn't assume everything Just Works would be sufficient to get me to change.
5/5
I wasn't familiar with #PDM. Its documentation makes it sound sane; I'll have to check it out.
Thanks!
C.
James Bennett