Of all the python packaging solutions, my favorite is pip-tools because it works with a standard venv setup. Poetry has some great features, but the additional overhead of requiring devs to install and learn a new tool are just not worth it. Also now you need to install poetry in your Docker images and/or production environments.

Typically you use poetry to generate a requirements.txt and make your docker image as usual. You do not need poetry in your docker or prod environments, but still benefit from actual dependency resolution.

Thanks for the clarification. It's been a while since I've looked at Poetry. I recall seeing people pull down the binary in their Docker builds and that rubbed me the wrong way. Good to know you don't have to do that.

What we do instead if to install poetry using pip in the local/builder stage and use the virtualenvs.in-project option: https://python-poetry.org/docs/configuration/#virtualenvsin-...

Then in the final stage we copy the virtualenv folder from the builder stage. So in the final image poetry is not installed and everything is still in a virtualenv.

It's definitely more complex than a requirements.txt, but this way we can have everything in the container, skip generating a requirements.txt and also not mix our application dependencies with the system ones.

Note that poetry now has recommendations for CI which also apply to docker builds. https://python-poetry.org/docs/#ci-recommendations

For a good discussion about package managers in python:

https://chriswarrick.com/blog/2023/01/15/how-to-improve-pyth...

From that page: Poetry isn’t compatible with PEP621(metadata in pyproject.toml), or PEP508 (version markers for dependencies in pyproject.toml)

Just some additional context for the discussion. I use poetry, (and pipenv) depending on my use case.

I can never go back to any other system for managing Python dependencies. Poetry was a bit flaky up to around v1.2.x but I'm so glad I stuck with it, since v1.5.x it's been superb.

Since this is a discussion on dependency management in Python - does anyone use rye [0] regularly now? I'm interested in using it but want a little more social validation before I try - some issues with package managers only appear after you've invested considerable time.

[0]: https://rye-up.com/

Rye is a wrapper around pip-tools and hatchling.

So it should be fine as long as those are fine.

Hatchling doesn’t seem to currently allow c extensions.

I don't know if I've just had particularly bad luck, but over the years I've run into multiple situations where upgrading my dependency manager has completely broken dependency installation.

I started using pipenv many years ago since it was the hot new thing, and then it kept happening over and over with new pipenv releases. And then poetry was the hot new thing, so I switched to poetry. And everything was good with poetry for some years... and then within the past few years, it started happening again. New poetry version, something breaks, Google it, set some config toggle, it works. Then another new version, something breaks again, some other config toggle is needed, etc. The least I'd expect of a dependency manager is very careful attention paid to backwards compatibility.

And now, based on this thread, I'm wondering if poetry is falling out of fashion and if these other recommendations, like PDM and rye, are going to be the hot new thing.

I used to have that with Poetry but it's been very stable since 1.5ish. PDM looks interesting but the "doesn't need virtual envs" bit scares me and rye is a personal project that may one day be something more [1]. I don't think I'd switch package manager away from Poetry for the foreseeable unless the folks behind Ruff [2] create one. I love Ruff.

[1] https://github.com/mitsuhiko/rye/discussions/6 [2] https://beta.ruff.rs/docs/

I would recommend PDM. It's similar to poetry but better executed IMO.

setuptools, pip, pip-tools, pipenv, poetry, PDM, rye... I love Python and will never stop using it, but it's refreshing to find Python's philosophy of "there should be one - and preferably only one - obvious way to do it" actually enacted in other languages, like Rust and Go, when it comes to dependency management.

I love the idea, but after using it on a day to day basis, I think I’m jaded with the number of ways to do packaging in python.

I often find my self removing it from the later stages of the multistage Docker images I create just to decrease the amount of contextual overhead. Maybe I’m crazy but npm feels less intrusive for some reason.

while I <3 poetry - they need to speed it up with a complicated hierarchy.

Without doubt the best python dependancy manager.