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!
Care to elaborate on *why* uv is best in your opinion?
I was hoping to hear actual reasons to use a particular tool, not just people giving me the names of tools I already know about but have not used 😜
Do you run into the type of problems I described with it? When problems arise, are its diagnostics useful and sufficient to identify the problem's cause? Is it reliable? etc.
Are you really saying "uv is better than Hatch, PDM, rye, and all the other alternatives, because I have not tried any of those alternatives"?
Because that's what it sounds like? Which doesn't make much sense as an argument. I must be misunderstanding you?
In case it wasn't clear, my preference for Python tools to actually be #implemented in Python isn't some vi-vs-EMACS or yuck-its-not-Python #religious objection.
It's that when I find a #bug, or a missing #feature with a tool, I'd like to contribute back. I frequently upstream bug fixes and features to such projects.
But if they're written in Rust, or Go, or whatever, I probably won't do that. I won't be able to scratch my itch without learning an entire new language and ecosystem.
@cazabon I'm more of an amateur dabbler in Python.
I disliked Conda and Poetry, and went back to PIP.
I may be missing something as my programming journey is more for mental stimulation and learning than career
Amateurs/hobbyists can benefit from the same types of tools as people who have to work with them all day - but the tradeoffs can be different for them.
pip is a package installer, and is good at that job. But non-trivial software development generally requires additional tools for dependency/package *management* in addition to installation, as well as managing virtual development environments and packaging. I'm sure this is the outside scoop btw 😜
I'll have to try a bunch.
C.
James Bennett
Andreas 🌈
Richie