On Mar 11, 2015, at 4:06 PM, Chris Barker <chris.barker@noaa.gov> wrote:

On Wed, Mar 11, 2015 at 3:52 PM, Andrew Barnert <abarnert@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???

Yes. That's essentially why I said Unix doesn't naturally work that way. But it may be appropriate for this specific use case, even if it's a hack.

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.

That's exactly what we already have; the problem is when python2 and python3 have the same scripts directory--say, /usr/local/bin--they both install a script called /usr/local/bin/ipython, with whichever was installed last overwriting the one that was installed first.

You might argue that this should never come up, but the fact is that it does. When you install python2 and python3 packages from most package managers, they both go into /usr/local, and both install scripts to /usr/local/bin. And on many platforms, even if the system Python is in /usr, it installs scripts to /usr/local/bin (and that's the right thing to do if /usr/bin is only for system binaries or binaries owned by the system package manager).

So, Ian (I think it was him; it's hard to see from this pruned reply...) suggested that just "ipython" should be able to run whatever version of Python is just "python" rather than whichever was installed last. How could we make that work?

One option is to have the script #!/usr/bin/env python. But, while that works great for the case where you've installed ipython2 and ipython3 and want ipython to follow your python, the case Ian is trying to solve, it doesn't work an all for the case where you've installed only ipython3 and want to be able to access it as just plain ipython, which is an even more common case. (I do have 4 versions of ipython installed for different CPython and PyPy versions, but I only have one chardetect, etc., because I don't care which version of Python runs the script, I just care what the script does.

So, the installer hack would solve both problems, on every kind of platform, for every kind of script. But it's a pretty bad hack. Is it worth doing? I'm not sure. But it's worth thinking about why it would get what Ian wants, at least to see why other solutions won't.



-CHB



 

~ 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/



--

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@noaa.gov