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

Chris Barker chris.barker at noaa.gov
Thu Mar 12 00:06:22 CET 2015


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

> 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".
>

hmm -- that seems odd -- if you re-arranged the path after it was
installed, it would be different???

I think you can count on folks use PATH to determine what they want as
default -- so in python2, setuptools would put
ipython and ipython2

and in the python3 install, it would put:

ipython and ipython3

so if you asked for ipython3 or ipython2, you'd get what you asked for --
and if you asked for ipython the PATH would determine what you'd get.

-CHB





> ~ Ian Lee
> On Mar 11, 2015 3:29 PM, "Andrew Barnert" <abarnert at yahoo.com> wrote:
>
>> 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/
>>
>>
> _______________________________________________
> 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/
>



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150311/8070bf9f/attachment-0001.html>


More information about the Python-ideas mailing list