Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Optionally skip creation of .gitignore in virtualenv directory #2003

Closed
compwiztobe opened this issue Nov 1, 2020 · 2 comments
Closed

Optionally skip creation of .gitignore in virtualenv directory #2003

compwiztobe opened this issue Nov 1, 2020 · 2 comments

Comments

@compwiztobe
Copy link
Contributor

compwiztobe commented Nov 1, 2020

While version controlling the virtualenv binaries etc. is not desirable, some of us version control pyvenv.cfg as well as other metadata we store about each environment (such as a pip requirements file), to facilitate portability of venv definitions. Before the merge of #1825 in response to #1806, that problem was already easily solvable with a top level .gitignore listing the typical Python bin/, lib/, share/, etc. directories to be ignored.

The * directive in the virtualenv subdirectories cannot be overridden by any .gitignore files in parent directories. If we could pass an option to virtualenv to disable the creation of this blanket * .gitignore, then existing .gitignore files in the venv directory AND all parent directories would continue to work as expected, and we could continue to track chosen config files stored in each environment directory.

For now, here's a workaround:

if [[ ! -f "$venv/.gitignore" ]]; then
  virtualenv $venv
  rm $venv/.gitignore
else
  virtualenv $venv
fi

but I would much rather be able to do this with something like

virtualenv $venv --no-gitignore

to recover the old behavior.

@gaborbernat
Copy link
Contributor

gaborbernat commented Nov 1, 2020

@compwiztobe if you want to force adding some files you can just use:

git add -f venv/pyenv.cfg

The gitignore file is advisory for the add and can be ignored.

Also, I don't think you want to store files you care about within the virtual environment folder, why not store them at the root level then?

@compwiztobe
Copy link
Contributor Author

compwiztobe commented Nov 1, 2020

This is part of a de- and re-hydrating workflow with virtualenvwrapper, where all my venvs are in a venv repository I share between systems. Creating a separate directory for the dried metadata would work but is messier (and might interfere with venv discovery tools and collide with existing venv names).

Forcibly tracking each file by hand means I have to do this for every file, and I still don't get git diff and git status to tell me when new environments or metadata need indexing (for example when I first create or dehydrate a venv). What I'm looking for is for the ignore directives to discriminate between my dehydrated metadata and the hydrated venv binaries.

I'm hoping to upstream this stuff into virtualenvwrapper, including my workaround wrapper premkvirtualenv

if ! grep -q "# track venv metadata" "$1/.gitignore"; then
cat >> "$1/.gitignore" << EOF

# track venv metadata
!.gitignore
!pip-packages
!pythonexec
!pyvenv.cfg
EOF
fi

But the .gitignore file creation could be an issue for other virtualenv use cases (not just my situation with virtualenvwrapper) so I wanted to bring it up here, namely, the creation of a blanket * .gitignore at low-level subdirectory where it cannot be overridden, and with no option to skip creating that file.

I tend to think that leaving control of ignore directives to the repository owner is a good idea. Just as SVN, Bazaar, or Mercurial repos need to handle this from repo root or similar, so too Git users have gotten used to writing ignore directives that suit their needs. The ignore directive created here interferes with that, so I thought a command line option would be useful.

@gaborbernat gaborbernat reopened this Nov 1, 2020
@pypa pypa locked and limited conversation to collaborators Jan 14, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants