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

[Ian Lee]

~ Ian Lee

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

> On Mar 11, 2015, at 3:45 PM, Ian Lee <ianlee1521 at 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".
>

I'm not sure this should be a decision at install time to set the hashbang.
Instead I'd propose the hashbangs should end up:

ipython  ==> "#! /usr/bin/env python"
ipython2  ==> "#! /usr/bin/env python2"
ipython3  ==> "#! /usr/bin/env python3"


> ~ 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/
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150311/668cc108/attachment.html>