Is there some per user file I can modify so that python -m venv xxx does not create an unwanted xxx/.gitignore file? It doesn’t seem to have any real content and adds noise to mercurial repos.
There’s a --without-scm-ignore-files flag?
It’s there precisely to stop you from accidentally adding an entire venv to version control. If you want to lock a venv then use a lock file and check that in instead.
The problem is that I won’t remember --without-scm-ignore-files and was asking if there’s some ~/.venvconfig file that could be used to apply these more unusual flags.
As a an aside if I put the venv into a .git controlled folder I assumed it wouldn’t mess with an existing .gitignore. However, it appears venv just overwrites my existing .gitignore which is probably pretty dumb. I feel this is an unwantedf ‘extra’.
Given it just one small file inside the venv directory, which itself should be ignored by your VCS (thus why the .gitignore was added) and there’s not normally a reason for a user to be poking around in there, I’m not sure I understand the practical impact here?
Virtualenv has a config file, if you use it instead of the stdlib venv.
Perhaps a better solution is just adding support for including .hgignore as well, so the directory is ignored by default in your VCS as well? (In theory it could also recurse up the tree to see if we are currently in a Git repo (.git dir), or use git to determine that, and only output the file if so and same with hg if added, but perhaps it could get expensive for a deeply-nested venv.)
Same as everything else in an existing venv directory if you specify a path to one that already exists. Personally I’d have assumed it would have errored if you tried to specify a dir that already exists for your venv, but I guess there’s some kind of use case. AFAIK,
NB, if xxx is shorter than 10 characters (or you just autocomplete it), its shorter to do
python -m venv xxx && rm xxx/.gitignore
I don’t agree that venv or virtualenv has sole use of a directory. Perhaps I’m undisciplined, but it’s my choice as to what the layout should be provided it doesn’t clash with other usage.
It seems you prefer the environment directory to be solely inhabited by venv controlled items.
I disagree with that preference.
As a virtualenv replacement it seems venv lost a useful feature in not having a config file.
Maybe @vsajip can provide more authoritative insight here as the venv maintainer, but I wouldn’t call this just some personal “preference” but the de-facto if not de-jure intended usage. Like with any other package/environment manager, I’d consider it to “own” the directory structure it creates and not expect the user mucking around in there to be a normally supported use case, particularly since it is normally excluded from version control. If you want to put stuff in there, unless you don’t want it checked in to VCS either, you’ll need to manually add all the venv-created subpaths in that directory to your .hgignore (and in that case, you can just add the .gitignore too; all that is the much bigger “noise” in a repo than just a single .gitignore alone).
Keeping the venv contents separate from arbitrary user-created files makes a lot of things much easier for yourself, the user; e.g. it is trivial to delete the venv and recreate it (just rm -r venv), it is automatically excluded from VCS by most stock .*ignore files (or is a one line to do yourself), it makes it obvious what files/directories are “yours” vs the venv’s (and is all in one rather than many), and conceptually, keeps the concerns of the venv separate from your own (checked-in) files.
By contrast, I don’t really understand what advantage there is or usecase that is required to be served by conflating those separate concerns in the same directory?
The stdlib venv isn’t actually intended to be a wholesale replacement of the third-party virtualenv. In fact, virtualenv is roughly a superset of venv, not the other way around. Being outside of the stdlib it is able to be much more actively developed and support more advanced use cases than the stdlib venv, which aims more for stability, simplicity and out of the box functionality.
3 Likes
This was added a couple of years ago, in gh-83417. I was -0.5 on adding it as I prefer Mercurial myself and moreover didn’t want to “pick a side”, but I didn’t want my personal DVCS preference to get in other people’s way, either. I get that it can be annoying to Mercurial users, but I suppose it was worth adding to avoid newbies committing venvs to version control inadvertently.
1 Like
The use case is that we have a lot of ancient projects that were intended for use with virtualenv and which assume the bin, include & lib folders at the top of the project repo. I think these started out in subversion days.
For me this is not a big deal, the .gitignore doesn’t affect mercurial and it’s easy if the project setup is automated to create .hgignore with standard excludes. It would be much harder to use these repos with git.
Currently I usually try to make the venv in subfolders like .py39 or .py314 which as you suggest makes deletion/recreation easier and also allows keeping up with the accelerated development of python.
1 Like