I also put virtualenvs in a single centralized location (~/.virtualenvs), and manage their contents via Poetry.
The main reason is that I sync my Git projects via Tresorit (“encrypted Dropbox”). This lets me switch computers without committing and pushing code that is not “ready”; makes it easier to sync all projects I work on to my backup server; and lets me copy around project files that I don’t want to commit (e.g. messy WIP and TODO notes).
This doesn’t work well with virtualenvs inside a repo, because (i) the virtualenvs are not portable, and (ii) syncing a virtualenv is slow. Instead, I sync a Poetry lock file, which makes it trivial to recreate the “same” virtualenv on other machines.
Late reply: I used to do this. These days, I treat my projects like cattle, not pets.[1]
Using nix I made everything reproducible. So given a project name and branch name, everything is checked out (shallow checkout for big projects) and setup for me. If I'm working on another machine, just run "launch org/project <branch>" and profit.
There are edge cases: if I forget to push, I do remote in and do that. When I'm done with a branch, I make it a habit to purge that "instance" of the project. But first I have git go through the project and its submodules (if any) and ensure everything has been pushed and the repo not modified.
Note: my projects are database backed and have state etc. All of that is part of the setup script, per project. If your database is in a customized-state for development for a super specific scenario, then you're probably not automatically testing it and that's a code smell to me.
They are not. The main reason is that I often use a venv in a few projects. This is just laziness really, and I don't think it's any better than what you're recommending.
(not op) One minor reason I'm considering stopping putting virtual envs inside the project is that not all tools I use support ignore files, and it's one extra thing to remember to ignore in each individual project. Putting venv/ in my .gitignore is one thing, but making sure grep, ag, tree, fzf, etc. all ignore it is an additional step. Granted, I believe some of those tools do respect .gitignore.
I just don't see a benefit to having the virtualenv inside the project directory.
What's your rationale for now putting the venv inside the project and ignoring it? À la node_modules.
I've shifted to this after years of your method and like it. I do hate .gitignore expanding arbitrarily. But that's life.