[Python-ideas] Migration of /usr/bin/python to python3

[Andrew Barnert]

On Mar 11, 2015, at 2:52 PM, Ian Lee <ianlee1521 at 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 at 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 at python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
> 
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150311/6af1566e/attachment-0001.html>