Why no venv in existing directory?
Hi All, While trying 3.3 beta I found that I cannot use my favorite virtualenv pattern with pyvenv: $ virtualenv . Installing.....done. $ pyvenv . Error: Directory exists: /Users/stefan/sandbox/foo I appreciate that this behavior is documented and was in the PEP from the start: "If the target directory already exists an error will be raised, unless the --clear or --upgrade option was provided." Still, I am curious what the rationale behind this restriction is. For me, being able to "bless" an existing directory with a virtualenv has always been one of its attractions. Thanks, Stefan -- Stefan H. Holek stefan@epy.co.at
Hi Stefan, On 07/19/2012 06:28 AM, Stefan H. Holek wrote:
While trying 3.3 beta I found that I cannot use my favorite virtualenv pattern with pyvenv:
$ virtualenv . Installing.....done.
$ pyvenv . Error: Directory exists: /Users/stefan/sandbox/foo
I appreciate that this behavior is documented and was in the PEP from the start: "If the target directory already exists an error will be raised, unless the --clear or --upgrade option was provided."
Still, I am curious what the rationale behind this restriction is.
I'd have no problem with lifting the restriction. I don't recall any clear rationale; I think it was probably just the simplest implementation initially, and no one ever raised it as an issue in the PEP process. Carl
Hi Carl, On 19.07.2012, at 18:39, Carl Meyer wrote:
Hi Stefan,
On 07/19/2012 06:28 AM, Stefan H. Holek wrote:
While trying 3.3 beta I found that I cannot use my favorite virtualenv pattern with pyvenv:
I'd have no problem with lifting the restriction.
I don't recall any clear rationale; I think it was probably just the simplest implementation initially, and no one ever raised it as an issue in the PEP process.
Thanks for your reply. The feature certainly is on *my* wish-list but I might be alone here. ;-) Stefan -- Stefan H. Holek stefan@epy.co.at
Wiadomość napisana przez Stefan H. Holek w dniu 23 lip 2012, o godz. 09:09:
Hi Carl,
On 19.07.2012, at 18:39, Carl Meyer wrote:
Hi Stefan,
On 07/19/2012 06:28 AM, Stefan H. Holek wrote:
While trying 3.3 beta I found that I cannot use my favorite virtualenv pattern with pyvenv:
I'd have no problem with lifting the restriction.
I don't recall any clear rationale; I think it was probably just the simplest implementation initially, and no one ever raised it as an issue in the PEP process.
Thanks for your reply. The feature certainly is on *my* wish-list but I might be alone here. ;-)
You are not. -- Best regards, Łukasz Langa Senior Systems Architecture Engineer IT Infrastructure Department Grupa Allegro Sp. z o.o. http://lukasz.langa.pl/ +48 791 080 144
FYI, I have created a tracker issue for this: http://bugs.python.org/issue15776 Stefan On 23.07.2012, at 09:09, Stefan H. Holek wrote:
The feature certainly is on *my* wish-list but I might be alone here. ;-)
-- Stefan H. Holek www.jarn.com/stefan
Looks like you can use for that $ pyvenv . --upgrade On Fri, Aug 24, 2012 at 12:19 PM, "Stefan H. Holek · Jarn" <stefan@jarn.com> wrote:
FYI, I have created a tracker issue for this: http://bugs.python.org/issue15776
Stefan
On 23.07.2012, at 09:09, Stefan H. Holek wrote:
The feature certainly is on *my* wish-list but I might be alone here. ;-)
-- Stefan H. Holek www.jarn.com/stefan
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/andrew.svetlov%40gmail.com
-- Thanks, Andrew Svetlov
Yes, you can do the upgrade, but there are a few flaws which keep me from using this: It is pretty common to use virtualenv inside a mercurial checkout. With venv, installation with python3 -m venv my-repos complains that the directory is not empty. With python3 -m venv my-repos --clear I was shocked, because that kills my repository :-( After doing a new clone of my repos, I tried with python3 -m venv my-repos --update This works a little, but does not install the bin/activate source. Finally, I reverted to using virtualenv instead, although I would love to migrate. But this is not enough. Anything I'm missing here? cheers - chris On 24.08.12 13:30, Andrew Svetlov wrote:
Looks like you can use for that $ pyvenv . --upgrade
On Fri, Aug 24, 2012 at 12:19 PM, "Stefan H. Holek · Jarn" <stefan@jarn.com> wrote:
FYI, I have created a tracker issue for this: http://bugs.python.org/issue15776
Stefan
On 23.07.2012, at 09:09, Stefan H. Holek wrote:
The feature certainly is on *my* wish-list but I might be alone here. ;-)
-- Christian Tismer :^) <mailto:tismer@stackless.com> Software Consulting : Have a break! Take a ride on Python's Karl-Liebknecht-Str. 121 : *Starship* http://starship.python.net/ 14482 Potsdam : PGP key -> http://pgp.uni-mainz.de phone +49 173 24 18 776 fax +49 (30) 700143-0023 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/
Minor correction: On 06.01.13 19:10, Christian Tismer wrote:
Yes, you can do the upgrade, but there are a few flaws which keep me from using this:
It is pretty common to use virtualenv inside a mercurial checkout.
With venv, installation with
python3 -m venv my-repos
complains that the directory is not empty. With
python3 -m venv my-repos --clear
I was shocked, because that kills my repository :-( After doing a new clone of my repos, I tried with
python3 -m venv my-repos --update
Sorry, I meant python3 -m venv my-repos --upgrade
This works a little, but does not install the bin/activate source.
-- Christian Tismer :^) <mailto:tismer@stackless.com> Software Consulting : Have a break! Take a ride on Python's Karl-Liebknecht-Str. 121 : *Starship* http://starship.python.net/ 14482 Potsdam : PGP key -> http://pgp.uni-mainz.de phone +49 173 24 18 776 fax +49 (30) 700143-0023 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/
Christian Tismer <tismer <at> stackless.com> writes:
Anything I'm missing here?
The use case was missed during PEP and patch review, so the feature didn't make it into 3.3. Issue #15776 raised the problem; it has been resolved and the feature should appear in Python 3.4. Regards, Vinay Sajip
participants (7)
-
"Stefan H. Holek · Jarn" -
Andrew Svetlov -
Carl Meyer -
Christian Tismer -
Stefan H. Holek -
Vinay Sajip -
Łukasz Langa