homepage

With virtualenv I can do
 $ virtualenv .
but with pyvenv I get
 $pyvenv .
 Error: Directory exists: /Users/stefan/sandbox/foo
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.
You lose not only virtual env but files from your project also.
virtualenv cleans only <env>/Lib directory, that's much better.
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:
1. Use a single place for all venvs (virtualenvwrapper does this)
2. Use a venv in a subdirectory of a project directory
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':
Issue #15776: Allow pyvenv to work in existing directory with --clean.
http://hg.python.org/cpython/rev/0668fc196ce5 

It is bug in shutil.rmtree, right?

> It is bug in shutil.rmtree, right?
Read the documentation:
 shutil.rmtree(path, ignore_errors=False, onerror=None)
 Delete an entire directory tree; path must point to a directory (but
not a symbolic link to a directory)

Another *perfect* example how even the most innocuous-seeming patch can be wrong.

Good point.
I will prepare the patch to fix this.

> Two common patterns are:
>
> 1. Use a single place for all venvs (virtualenvwrapper does this)
> 2. Use a venv in a subdirectory of a project directory
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.

> 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 used to create venvs in the project top-level directory (typically a Mercurial clone root), using "virtualenv ."
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.

> Well, changing it to do that means changing functionality, which is disallowed at this point in the release process.
I think people used to "virtualenv ." can see this as a regression between virtualenv and pyvenv, but if the PEP did not list that use case then it’s too late. I’d suggest we even back out the "pyvenv --clear ." commit, which did not address the needs of the "virtualenv ." users.

Le vendredi 24 août 2012 à 18:47 +0000, Éric Araujo a écrit :
> Éric Araujo added the comment:
> 
> > Well, changing it to do that means changing functionality, which is
> disallowed at this point in the release process.
> I think people used to "virtualenv ." can see this as a regression
> between virtualenv and pyvenv, but if the PEP did not list that use
> case then it’s too late. I’d suggest we even back out the "pyvenv
> --clear ." commit, which did not address the needs of the
> "virtualenv ." users.
Agreed with Eric. The feature could be added correctly in 3.4.

Reverted.

New changeset b200acb6bed4 by Andrew Svetlov in branch 'default':
Delete Misc/NEWS record for reverted #15776.
http://hg.python.org/cpython/rev/b200acb6bed4 

LGTM.

New changeset c3c188a0325a by Vinay Sajip in branch 'default':
Closes #15776: pyvenv now works with existing directories.
http://hg.python.org/cpython/rev/c3c188a0325a 

Looks good. Thank you.