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
Allow pyvenv to work in existing directory #59980
Comments
With virtualenv I can do $ virtualenv . but with pyvenv I get
Please allow pyvenv to apply to existing directories. |
Does it mean implicit implying --upgrade option if venv dir is '.'? |
Running pyvenv --clear . should work, but doesn't because of the way the venv directory is initialised - a shutil.rmtree() call is used. This can cause problems on Windows (current directory is regarded as open and so cannot be deleted) and also on Posix, because the inode changes and you get "file not found" errors because e.g. the shell has pointers to the old inode and the venv files are added to the new inode. The attached patch should work, as it deletes the venv directory contents rather than the venv directory itself. I'll just check with Georg that it's OK to commit this - I don't see any problem, as it's a bug-fix rather than a new feature, but I think it best to run it past him. |
I don't like current --clear behavior, it's really useless because now venv just deletes everything from virtual environment. I think venv --clear should cleanup everything which it creates (I mean bin/include/lib for Posix and Scripts/Include/Lib for Windows). Not sure about pyvenv.cfg |
Venvs should be regarded as throwaway; there is really no reason to add other files (e.g. project files) to venvs. Two common patterns are:
The current implementation follows PEP-405, and the functionality was discussed on python-dev before being finalised. |
Well, I see. Agree with your patch then, it is correct. |
LGTM, please apply. |
os.path.isdir("foo") will return True if "foo" is a symlink to a directory, and then shutil.rmtree("foo") will fail: >>> os.path.isdir("foo")
True
>>> os.path.islink("foo")
True
>>> shutil.rmtree("foo")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/home/antoine/opt/lib/python3.3/shutil.py", line 456, in rmtree
"Not a directory: '{}'".format(path))
NotADirectoryError: [Errno 20] Not a directory: 'foo' |
New changeset 0668fc196ce5 by Andrew Svetlov in branch 'default': |
It is bug in shutil.rmtree, right? |
Read the documentation: shutil.rmtree(path, ignore_errors=False, onerror=None)
not a symbolic link to a directory) |
Another *perfect* example how even the most innocuous-seeming patch can be wrong. |
Good point. |
I’m a recent virtualenv user, but before I became a virtualenvwrapper fan I used to create venvs in the project top-level directory (typically a Mercurial clone root), using “virtualenv .”. |
Hm. What I am actually after is to "bless" an existing directory – source files and all – with a virtualenv (or pyvenv). I am not interested in the command deleting anything from anywhere, why thank you. Workflow: $ git clone git@github.com:stefanholek/foo
$ cd foo
$ virtualenv .
$ ./bin/python setup.py develop
$ ./bin/python setup.py -q test This is how I use virtualenv at the moment and I'd rather not lose that ability. Thanks. |
Well, changing it to do that means changing functionality, which is disallowed at this point in the release process. |
I've used option 2 for this, using e.g. "virtualenv env" in the project directory. |
Sorry for being late. I'll make a feature request for 3.4 then. |
|
Le vendredi 24 août 2012 à 18:47 +0000, Éric Araujo a écrit :
Agreed with Eric. The feature could be added correctly in 3.4. |
Reverted. |
New changeset b200acb6bed4 by Andrew Svetlov in branch 'default': |
LGTM. |
New changeset c3c188a0325a by Vinay Sajip in branch 'default': |
Looks good. Thank you. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: