pip/easy_install mercurial in virtualenv on Python 3.3
With Python 3.3: in a virtualenv/venv, when trying $ pip install mercurial or, after trying several options, $ easy_install mercurial I get the complaint error: Setup script exited with setup.py with python3 needs --c2to3 (experimental) But when I try to do this accordingly, I get in either case again: $ easy_install mercurial --c2to3 error: Setup script exited with setup.py with python3 needs --c2to3 (experimental) Any clue where to put this option? cheers -- chris -- 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/
Some further analysis of the problem: Mercurial is (and should be) installed system-wide. The 'hg' command (at least my homebrew install) uses the normal shebang line "#!/usr/bin/env python" When using virtualenv and python2.7, this works fine. When using virtualenv or venv and python3.3, then the following happens: - The 'python' command gets redirected to python3. - Then the system mercurial is run with the wrong interpreter. That finally made me try to install mercurial using pip, and that caused the question from below. But actually, the "bad thing" IMHO is the naming clash introduced by the symlinks that v(irtual)env is setting: Why does it ignore the otherwise clear distinction between python and python3 ? And who is responsible to make things "right": Should virtualenv avoid this naming problem, or should the mercurial installer become more carefully specify its interpreter? In any case, this is pretty annoying, and hard to explain to users. What fixing do you recommend as a workaround? cheers - chris On 25.02.13 02:33, Christian Tismer wrote:
With Python 3.3:
in a virtualenv/venv, when trying
$ pip install mercurial
or, after trying several options,
$ easy_install mercurial
I get the complaint
error: Setup script exited with setup.py with python3 needs --c2to3 (experimental)
But when I try to do this accordingly, I get in either case again:
$ easy_install mercurial --c2to3 error: Setup script exited with setup.py with python3 needs --c2to3 (experimental)
Any clue where to put this option?
cheers -- chris
-- 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/
Addendum (see the end) On 25.02.13 13:27, Christian Tismer wrote:
Some further analysis of the problem:
Mercurial is (and should be) installed system-wide.
The 'hg' command (at least my homebrew install) uses the normal shebang line
"#!/usr/bin/env python"
When using virtualenv and python2.7, this works fine.
When using virtualenv or venv and python3.3, then the following happens:
- The 'python' command gets redirected to python3. - Then the system mercurial is run with the wrong interpreter.
That finally made me try to install mercurial using pip, and that caused the question from below.
But actually, the "bad thing" IMHO is the naming clash introduced by the symlinks that v(irtual)env is setting:
Why does it ignore the otherwise clear distinction between python and python3 ?
And who is responsible to make things "right": Should virtualenv avoid this naming problem, or should the mercurial installer become more carefully specify its interpreter?
In any case, this is pretty annoying, and hard to explain to users. What fixing do you recommend as a workaround?
cheers - chris
On 25.02.13 02:33, Christian Tismer wrote:
With Python 3.3:
in a virtualenv/venv, when trying
$ pip install mercurial
or, after trying several options,
$ easy_install mercurial
I get the complaint
error: Setup script exited with setup.py with python3 needs --c2to3 (experimental)
But when I try to do this accordingly, I get in either case again:
$ easy_install mercurial --c2to3 error: Setup script exited with setup.py with python3 needs --c2to3 (experimental)
After looking into "pip help install", I tried to run (venv) $ pip install mercurial --install-option="--c2to3" Now the crazy effect is: Installing collected packages: mercurial Running setup.py install for mercurial --c2to3 is only compatible with python3. Pretty confusing... ;-) Is this the right place to ask this question? - chris -- 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/
Hi Christian, On 02/25/2013 07:48 AM, Christian Tismer wrote:
After looking into "pip help install", I tried to run
(venv) $ pip install mercurial --install-option="--c2to3"
Yes, this should be the correct way to pass an option directly to Mercurial's setup.py.
Now the crazy effect is:
Installing collected packages: mercurial Running setup.py install for mercurial --c2to3 is only compatible with python3.
Pretty confusing... ;-)
Indeed. You did this within a Python 3 virtualenv? I don't know how it is possible that Mercurial's setup.py is being executed with Python 2, if you "pip install" it from within a Python 3 virtualenv. You could make your own modified Mercurial tarball with a "print sys.executable" in setup.py and then try to "pip install" that tarball and see what it says?
Is this the right place to ask this question?
Yes. Carl
On 02/25/2013 09:54 AM, Carl Meyer wrote:
On 02/25/2013 07:48 AM, Christian Tismer wrote:
Is this the right place to ask this question?
Yes.
Er, I should check which list I'm actually writing to before answering such questions. I think pip/virtualenv questions are reasonably on-topic for distutils-sig, but there is also a dedicated list that might be an even better place: https://groups.google.com/forum/?fromgroups#!forum/python-virtualenv Carl
Hi Christian, On 02/25/2013 05:27 AM, Christian Tismer wrote:
Some further analysis of the problem:
Mercurial is (and should be) installed system-wide.
The 'hg' command (at least my homebrew install) uses the normal shebang line
"#!/usr/bin/env python"
When using virtualenv and python2.7, this works fine.
When using virtualenv or venv and python3.3, then the following happens:
- The 'python' command gets redirected to python3. - Then the system mercurial is run with the wrong interpreter.
That finally made me try to install mercurial using pip, and that caused the question from below.
But actually, the "bad thing" IMHO is the naming clash introduced by the symlinks that v(irtual)env is setting:
Why does it ignore the otherwise clear distinction between python and python3 ?
When Vinay ported virtualenv to Python 3, we made the decision that since virtualenvs generally have exactly one Python interpreter of one version, that it would be less surprising if every virtualenv always had a "python", regardless of 2v3. I don't know for sure if that was the right choice or not.
And who is responsible to make things "right": Should virtualenv avoid this naming problem, or should the mercurial installer become more carefully specify its interpreter?
In general, I think that it is wrong for system-installed scripts to ever use "/usr/bin/env python" in the shebang line, as that makes it too easy for them to be run with the wrong Python. I know that, for instance, it is the policy of Debian/Ubuntu to not use "#!/usr/bin/env python". I don't know what homebrew's policy is, but I'd suggest raising this as a bug in the Homebrew Mercurial package. Carl
Hi Carl, On 25.02.13 17:47, Carl Meyer wrote:
Hi Christian,
On 02/25/2013 05:27 AM, Christian Tismer wrote:
Some further analysis of the problem:
...
But actually, the "bad thing" IMHO is the naming clash introduced by the symlinks that v(irtual)env is setting:
Why does it ignore the otherwise clear distinction between python and python3 ? When Vinay ported virtualenv to Python 3, we made the decision that since virtualenvs generally have exactly one Python interpreter of one version, that it would be less surprising if every virtualenv always had a "python", regardless of 2v3. I don't know for sure if that was the right choice or not.
Well, I'm struggling quite a bit with that and would love to at least have the option to keep things uniquely named, the same way as the system pythons are. Actually, I would love to have both python2 and python3 in the same virtualenv, for testing purposes, distinguishing the versions by using the different interpreter, only. But installing both versions after another messes things up very much and led to the effect that I always got python3, even if I explicitly ran (virtenv) $ python2 Python 3.3.0 (default, Dec 29 2012, 18:23:00) ...
And who is responsible to make things "right": Should virtualenv avoid this naming problem, or should the mercurial installer become more carefully specify its interpreter? In general, I think that it is wrong for system-installed scripts to ever use "/usr/bin/env python" in the shebang line, as that makes it too easy for them to be run with the wrong Python. I know that, for instance, it is the policy of Debian/Ubuntu to not use "#!/usr/bin/env python". I don't know what homebrew's policy is, but I'd suggest raising this as a bug in the Homebrew Mercurial package.
Thank you. Yes I feared that I would have to prove it to be a hg bug (again), not always the nicest experience ;-) thanks a lot for your answer -- chris -- 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/
On 02/25/2013 10:31 AM, Christian Tismer wrote:
Actually, I would love to have both python2 and python3 in the same virtualenv, for testing purposes, distinguishing the versions by using the different interpreter, only. But installing both versions after another messes things up very much and led to the effect that I always got python3, even if I explicitly ran
(virtenv) $ python2
Python 3.3.0 (default, Dec 29 2012, 18:23:00) ...
That's interesting. I'd expect that if you first created a venv using Python 3, then removed the "python" symlink leaving only "python3", then installed a Python 2 virtualenv in the same location, things would work as you wish them to (at least on Linux/OSX; superimposed venvs don't work at all on Windows AFAIK because the Lib directories aren't versioned).
And who is responsible to make things "right": Should virtualenv avoid this naming problem, or should the mercurial installer become more carefully specify its interpreter? In general, I think that it is wrong for system-installed scripts to ever use "/usr/bin/env python" in the shebang line, as that makes it too easy for them to be run with the wrong Python. I know that, for instance, it is the policy of Debian/Ubuntu to not use "#!/usr/bin/env python". I don't know what homebrew's policy is, but I'd suggest raising this as a bug in the Homebrew Mercurial package.
Thank you. Yes I feared that I would have to prove it to be a hg bug (again), not always the nicest experience ;-)
Well, let's distinguish between "Mercurial bug" and "bug in Homebrew recipe for Mercurial" - usually the latter is the responsibility of Homebrew, not Mercurial. I don't know what the Homebrew people will say, but my guess is you are more likely to see this fixed at the Homebrew level than in Mercurial itself. Carl
Hi Carl, On 25.02.13 18:38, Carl Meyer wrote:
On 02/25/2013 10:31 AM, Christian Tismer wrote:
Actually, I would love to have both python2 and python3 in the same virtualenv, for testing purposes, distinguishing the versions by using the different interpreter, only. But installing both versions after another messes things up very much and led to the effect that I always got python3, even if I explicitly ran
(virtenv) $ python2
Python 3.3.0 (default, Dec 29 2012, 18:23:00) ... That's interesting. I'd expect that if you first created a venv using Python 3, then removed the "python" symlink leaving only "python3", then installed a Python 2 virtualenv in the same location, things would work as you wish them to (at least on Linux/OSX; superimposed venvs don't work at all on Windows AFAIK because the Lib directories aren't versioned).
Probably it would, yes. But I just blindly installed them one after the other, with that slightly funny effect ;-) Not doing this any longer at all...
And who is responsible to make things "right": Should virtualenv avoid this naming problem, or should the mercurial installer become more carefully specify its interpreter? In general, I think that it is wrong for system-installed scripts to ever use "/usr/bin/env python" in the shebang line, as that makes it too easy for them to be run with the wrong Python. I know that, for instance, it is the policy of Debian/Ubuntu to not use "#!/usr/bin/env python". I don't know what homebrew's policy is, but I'd suggest raising this as a bug in the Homebrew Mercurial package.
Thank you. Yes I feared that I would have to prove it to be a hg bug (again), not always the nicest experience ;-) Well, let's distinguish between "Mercurial bug" and "bug in Homebrew recipe for Mercurial" - usually the latter is the responsibility of Homebrew, not Mercurial. I don't know what the Homebrew people will say, but my guess is you are more likely to see this fixed at the Homebrew level than in Mercurial itself.
Yes, you are right. Homebrew is wrong here. The mercurial installer replaces the shebang line, if I do $ pip install mercurial using the python2, which installs fine with homebrew and includes pip. While a homebrew install of mercurial does not adjust that line. ( Quite similar to a lot of packages which are just wrong in homebrew, see pyside (I made my own for py2 and py3)). To get this to an end: It makes little sense to try to install mercurial on python3 at all, since the 2to3 conversion fails! That means my recommendation becomes: - do a system install of mercurial using pip! After that, you have a hg command that also works in a venv on python3 :-) (Sigh!! That was a bit tricky) Now I can write my how-to for OS X: - install homebrew - $ brew install python - $ brew install python3 #(optional, for python3 converts like me) - $ pip install mercurial thanks & cheers -- chris -- 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/
On 02/25/2013 10:31 AM, Christian Tismer wrote:
On 25.02.13 17:47, Carl Meyer wrote:
On 02/25/2013 05:27 AM, Christian Tismer wrote:
Why does it ignore the otherwise clear distinction between python and python3 ? When Vinay ported virtualenv to Python 3, we made the decision that since virtualenvs generally have exactly one Python interpreter of one version, that it would be less surprising if every virtualenv always had a "python", regardless of 2v3. I don't know for sure if that was the right choice or not.
Well, I'm struggling quite a bit with that and would love to at least have the option to keep things uniquely named, the same way as the system pythons are.
I think the best argument for keeping the current behavior as the default is the potential confusion of having a virtualenv activated, typing "python", and getting an interpreter from outside the virtualenv. I think this confusion would likely be more common, if that change were made, than the reverse that you are hitting now. Carl
participants (2)
-
Carl Meyer -
Christian Tismer