Python Project-Local Virtualenv Management Redux

People complain lot about python packaging, have complicated setups to work with it, and invent new tools all the time. In the meanwhile, I just use vanilla pip and venv with Debian Stable provided python like a caveman, and I&#x27;m... mostly content? For smaller stuff, I tend to use just Debian provided python packages, for the rest just (project-local) venv. Sure, there is occasionally some hitches, it&#x27;s not perfect, but I haven&#x27;t yet felt the need to reach for anything else.<p>I bring this up because this is such a common topic to complain about, and there is this sentiment that Python packaging is completely broken and unusable. But for me, and I suspect a large quiet userbase, stuff just works fine, and I don&#x27;t think this side gets brought up nearly enough. And for people not actively using Python, it&#x27;s important to note that you don&#x27;t need a rube-goldberg setup like in TFA.

My Python virtual environment and dependency management journey has been the following:<p>1. Just `pip` and `venv`; specifying dependencies via &quot;requirements.txt&quot; and &quot;dev_requirements.txt&quot;, and tool configuration options in bespoke files. Too involved and with too many parts, yet it made do for my use cases.<p>2. `poetry` together with &quot;pyproject.toml&quot;. Big quality of life improvement: commands like `poetry add`, `poetry build` make the process much less involved so one can just focus on actual development. Having all of the tooling configuration in a single place (that being &quot;pyproject.toml&quot;) also helped with context switching.<p>3. `uv` for quick and dirty Python projects, `rye` (with the `uv` backend) for anything above that. In short, I think of `uv` and `rye` as faster siblings of `pip` and `poetry`, respectively. Once you get used to creating virtual and environments and installing dependencies in milliseconds or a few seconds it&#x27;s difficult to go back to it always taking many seconds.<p>In hindsight, I would have been content just using `poetry`, but `uv` and `rye` do make for a faster and hence better developer experience.<p>P.S.: how messed up is it that only now we are agreeing on a convention for putting a project’s virtual environment into an in-project directory called `.venv`?

It&#x27;s funny how people seem to love this node style of a virtualenv in the project.<p>I much, much prefer virtualenvwrapper with it&#x27;s style of keeping the environment outside the project.<p>This way, I don&#x27;t end up with lots of huge directories hidden in the many many projects I check out.<p>The other thing that can&#x27;t happen is accidentally adding the folder to version control.<p>I can have various versions of my project checkout out, and use the same venv between them.<p>I can quickly fire up a venv for the project with a different version of python.<p>I can quickly list all my venvs, and prune them as needed.<p>While people may say &quot;we have infinite storage&quot; my laptop only has 2tb and I fill it up.<p>But each to their own, a lot of people seem to like it.<p>I also use direnv, and the the virtualenvwrapper plugin for zsh, and have defaults - in this case it automatically defaults to the virtualenv with the same name as the directory I enter, but I didn&#x27;t have to do any config for that to happen.

Nice! I&#x27;ve recently discovered direnv too and can&#x27;t believe I&#x27;ve coped this long without it. I currently use virtualenvwrapper and direnv to activate those (I much prefer having the venv root outside of the project dirs; not everything respects gitignore files by default).<p>I didn&#x27;t know about uv and PDM. I use pip-tools and there has been some work to adapt it to support multiple Python interpreters. My main gripe is it can&#x27;t be installed once with pipx, for example, and just work. But it seems difficult. Perhaps uv suffers from the same problem. Interested to see how PDM deals with it.<p>&gt; While direnv has built-in support for the standard library’s venv module, it’s glacial. virtualenv is much faster, but uv is faster, still.<p>I&#x27;ve never been bothered by the speed of venv. It does what it needs to do in milliseconds and it&#x27;s not like I&#x27;m calling it that often. Why is the speed of it important?

I&#x27;m a simple man: pyenv virtualenv + poetry.

I can&#x27;t believe people aren&#x27;t using devcontainers

&gt; I use different mechanisms to manage the virtual environments depending on whether I’m developing a *package* <i>without</i> strict pinning or an *application* <i>with</i> strict pinning.<p>I assume that by “package,” the author means library?

I tried poetry for the first time last night and it was honestly a breeze to get set up and felt much more full featured than pipping about with a requirements.txt