If you like yarn I think you will like poetry. Using --user here, no per-project virtualenv, used to have a virtualenv in ~/.env, where i keep everything up to

If you like yarn I think you will like poetry. Using --user here, no per-project virtualenv, used to have a virtualenv in ~/.env, where i keep everything up to date and have many -e installs from ~/src. For production deployments: --user in containers. This means all my projects have to work with the same versions of dependencies. This means all my dependencies have to work with the same versions of dependencies. All my dependencies have to be up to date: all versions must be latest, or next to-be-released. When don't support new versions of other dependencies: I deploy a fork and open a PR. At such, I'm not spending time trying to make obsolete versions work, rather, I'm spending time making new versions work together. My perception is that this strategy offers better ROI than all others which I have tried, not only for me, but for the whole ecosystem. That's also how I made my Python 2 to 3 transition, and have been using 100% Python 3 for a while (once you've ported one big software, porting others and their smaller dependencies is easy). I'm extremely happy about this strategy and my life has just been better since I started working this way, and highly recommend it. For my own (countless) packages: I use setupmeta which simplifies auto-updates (I think it succeeds what pbr tried to achieve).