Recent searches
Search options
Where do you store your #Python virtual environments?
@brettcannon central but mostly cause that's poetry defaults. I'll use devcontainers or nix environments these days though
@brettcannon When I use them, a central directory managed by pyenv (its virtualenv plugin), which I like because I don't have to decide or even know where they live in the filesystem.
@brettcannon I'm using direnv nowadays to create, activate and deactivate the venv for a single project
@brettcannon I live dangerously & don't have venvs. Every so often I nuke .local site-packages and reinstall everything, or a python upgrade does it. I am comfy with pip/twine/conda, but I guess I should learn one of those new pipenv/poetry/... thingies?
@data_from_space It's really up to you. I personally still use `py -m venv` directly (hence the Python Launcher for Unix's ideal workflow being what it is 
), but I do still create a virtual environment for every project that requires any installation.
@brettcannon one thing you alluded to in your blog post is reusing global/central venvs across projects. pyenv-virtualenv allows me to editable-install multiple related packages into the same global venv and work on them all at the same time (I've always been curious how people who put the .venv/ locally in one of the package workspaces do this)
@cdwilson I suspect they keep the virtual environment higher up in the directory structure or they just add the editable installs in one project since the edits will simply care over.
@brettcannon I'm all about direnv's pyenv integration lately https://direnv.net/man/direnv-stdlib.1.html#codelayout-pyenv-ltversiongt-code
@tim @brettcannon this is my favorite formulation.
All project necessary environment variables and the required python version declared in one place.
@brettcannon depending on the tool. If I'm using Poetry I let it do whatever it wants, so central place. When I manage it manually, I create a local dir `venv`.
@brettcannon I don't use virtual environments I just containerize the app
@brettcannon The mkvirtualenv/workon tooling uses ~/.virtualenvs and is recognized by IDEs (in my case elpy)
@larstiq I know as I work on one of those tools that recognizes the directory (VS Code) 
@brettcannon Locally so I can browse the code inside using my editor easily.
@brettcannon on Linux, in a central folder, managed with virtualenvwrapper, and when necessary, symliked to the project's folder. On windows, at work, locally in the project, because symliking requires admin permissions on windows for so God forsaken reason.
@brettcannon It depends...
Local dev: Tool decides (pyenv virtualenv, poetry) -> central dir.
Docker images: No virtualenv
Legacy cruft on mutable infra: venv local to codebase.
@brettcannon it depends. I have a global venv that has most libraries installed to use with Jupyter and at work where direct pip access is blocked, but for any Python project that gets its own git-repo, I keep a “venv” folder with the source.
@brettcannon My secret: I essentially never use them. 
Just yesterday I looked at all my UWSGI deployments on my web site and thought "I should probably have each of these on its own virtualenv / venv /conda environment / something" but ... somehow they all keep working on one giant amalgamated system-wide python install, so....
@brettcannon I chose "global/central directory", because that's what virtualenvwrapper does.
However, I use tox a lot, and tox environments tend to be local. They're just not "my" virtual environments in some sense.
@brettcannon missing the “I get so lost every time I have to do this again” option 
@jredville That's why I'm trying to fix it 
@brettcannon 
awesome to hear, and appreciate the write up
G @brettcannon Best place for venv (for me) is in project because it’s obvious where actual packages are installed and makes it easy to delete venv & start over.
My workflows:
- Initialize a venv for project
- Install packages in venv
- Delete venv (start clean or when done testing)
- initialize multiple venv for different Py versions and OS’es in same project
Should be “official” core tool (like rustup and cargo for rust). Should be easily to use/get a new/specific Py version.
That is all :)
@jimkring I would love to get it so we have official, pre-built binaries that can just be downloaded and installed, effectively replacing pyenv. But it requires time and effort, as well as dealing with some potentially nasty issues like macOS security not liking binaries built off-machine w/o them being signed (which mucks with debugging).
@brettcannon thanks for that info. I can see it could be hard to to have official binaries. I'd be OK installing/compiling python from source if needed. The challenge for me is all the different tools/ways to (1) install python, (2) create a venv for a project, and (3) install/manage packages. This results in huge number of possible combinations of solutions to the above. In terms of time and effort, what would you see as one or two good next steps (I or others could take) on a path forward?
@brettcannon Just to clarify about what I mean by "next steps toward": I'd love for python (PSF) to have an "officially designated" tool(s) for this workflow and wondering what steps one might take to move such a thing forward. Just a thought.
@jimkring unifying the UX into a single tool is being actively discussed in https://discuss.python.org/t/python-packaging-strategy-discussion-part-1/22420 . But it is tricky since e.g. for (1) the Windows installer and the macOS installer can install stuff you can't do as a normal build. As for management, I still hope for (3) to get lock files so it's either `pyproject.toml` or a lock file you created. As for (2), https://snarky.ca/classifying-python-virtual-environment-workflows/ exists for a reason (but also good luck convincing everyone they should change to the other way ).
@brettcannon Disappointing 12% neither know nor care. Great documentation just waiting to be read:
https://peps.python.org/pep-0405/