On Mar 11, 2015, at 6:52 PM, Andrew Barnert <abarnert@yahoo.com> wrote:

On Mar 11, 2015, at 3:45 PM, Ian Lee <ianlee1521@gmail.com> wrote:

Sure, and I agree that called "ipython2" / "ipython3" explicitly is better. I just expected it would default to use whatever "python" is implicitly on my path. E.g. that "python" and "ipython" would use the same interpreter.

That's actually not a bad idea; I didn't even think about it because Unix stuff doesn't "naturally" work that way, but it's probably not too hard to do it "unnaturally".

Maybe setuptools could check "there's something on the path called python that doesn't run the same version of Python that I'm running right now, so only install ipython3.4 and ipython3, not ipython”.


This is a problem that we’ve yet to tackle really (besides special cases for pip itself). You can’t really do it reasonably without not making Wheels, or making wheels that are python version specific. This is because the build process runs on the author’s machine and “bakes” in the names of the commands at that time.

It’s likely going to require figuring out which trade off makes the most sense, adding explicit fooX.Y is one option, but that leaves into question what we do with alternate interpreters like PyPy or Jython (including versioning them, because you might have multiple versions of them installed). It also can cause issues when you have multiple things called “python2” or “python2.7” on your path, which version of “python2” does “foo2” call? Obviously it’s possible to just define something and say “this is what it is” but we need to figure out what that thing should be, and if the trade offs make sense.

On the other side, executing versioned commands with -m is not quite as nice (python2.7 -m pip is more letters than pip2.7 and doesn’t autocomplete) however it is really explicit under which interpreter it’s going to run and support for things like alternate interpreters and multiple versions is built in.

~ Ian Lee

On Mar 11, 2015 3:29 PM, "Andrew Barnert" <abarnert@yahoo.com> wrote:
On Mar 11, 2015, at 2:52 PM, Ian Lee <ianlee1521@gmail.com> wrote:

+1

An issue that I've noticed recently (I haven't had the time to fully track this one down yet, but I suspect it's a setuptools issue) takes a "last one wins" approach to scripts that get written into the same bin directory (e.g. --user installs).

Many packages will install spamX and spamX.Y scripts as well as plain spam, so you can deal with this the same way you deal with Python instead--run ipython3 or ipython3.4 instead of just ipython. (Not to mention ipython_pypy3!) Also, sometimes python2 and python3 will install to different directories (/usr for the one that's part of the system, /usr/local for others, or /Library/Framework/Python/Versions/X.Y/bin...), so "last one wins" isn't even predictable cross-platform; you have to be able to deal with either "last one wins" or "controlled by PATH" when you want to just run "ipython". But really, since these scripts don't need to be run by a shbang or other automated mechanism, and the user who intentionally installs IPython for both 2.7 and 3.4 is going to need some way to manually select the one they want to run each time anyway. So I think this solution isn't too bad: 90% of the time, a script is only installed for one Python version so "last one wins" works trivially; most of the rest of the time, the user has two or more and needs to use "ipython2" vs. "ipython3" rather than just "ipython" because how else could be use both as desired, so "last one wins" is irrelevant.The thing is, I don't think you get this script versioning automatically from setuptools. If you don't, maybe you should?


$ python2.7 -m pip install --user ipython
 
$ head -n1 ~/.local/bin/ipython*
==> /home/ianlee1521/.local/bin/ipython <==
#!/usr/bin/python2.7
 
==> /home/ianlee1521/.local/bin/ipython2 <==
#!/usr/bin/python2.7
 
$ python3.4 -m pip install --user ipython
 
$ head -n1 ~/.local/bin/ipython*
==> /home/ianlee1521/.local/bin/ipython <==
#!/usr/bin/python3.4
 
==> /home/ianlee1521/.local/bin/ipython2 <==
#!/usr/bin/python2.7
 
==> /home/ianlee1521/.local/bin/ipython3 <==
#!/usr/bin/python3.4

So the packages end up in the separate, versioned directories (~/.local/lib/pythonX.Y/site-packages), but with the scripts ending up in the same bin directory, the implicit script "~/.local/bin/ipython" ends up changing to use the hashbang of the Python version which last installed the package (see highlighted above).

I would expect that the implicit script ("~/.local/bin/ipython") should use the implicit python version, e.g. "#!/usr/bin/python".

Alternatively, maybe I just shouldn't ever be installing user versions of both Python 2 and Python 3 versions of a package.


~ Ian Lee

On Wed, Mar 11, 2015 at 1:38 PM, M.-A. Lemburg <mal@egenix.com> wrote:
On 11.03.2015 21:03, David Mertz wrote:
> https://www.python.org/dev/peps/pep-0394/

I think the migration should start with modifying scripts to use

#!/usr/bin/env python2

when they are Python 2 only (*) and

#!/usr/bin/env python3

when they are Python 3 only and

#!/usr/bin/env python

only when they support both Python 2 and 3.

"Explicit is better than implicit" and all that Zen :-)

Once that's done, switching the symlink is really a no-brainer.

The recipe for this is easy too:

1. replace all "#!/usr/bin/env python" with "#!/usr/bin/env python2"
2. migrate your scripts one by one to either Python 3.x or
   to Python 2.7 + 3.4+
3. after migration replace "#!/usr/bin/env python2" with
   "#!/usr/bin/env python3" or "#!/usr/bin/env python" resp.

(*) Some OSes may require to use python2.7, if they don't come
with a symlink from python2 -> python2.7.

--
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Mar 11 2015)
>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>> mxODBC Plone/Zope Database Adapter ...       http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::::: Try our mxODBC.Connect Python Database Interface for free ! ::::::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA