[Distutils] Scripts/Entry Points Python-Version Naming

[Donald Stufft]

On May 19, 2014, at 7:40 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> 
> On 20 May 2014 01:38, "Donald Stufft" <donald at stufft.io> wrote:
> >
> > If we do standardize we should also likely standardize on how we handle
> > alternative interpreters. Things like PyPy, Jython etc.
> 
> The idea of a "py" launcher equivalent for POSIX systems likely has a place in that discussion.
> 
> As far as the original post goes, the main place where I believe this is currently a common issue is on POSIX systems with parallel Python 2 & 3 stacks.
> 
> On Windows, there is only "python", and PATH controls which version you get. You use the "py" command line options to nominate a specific interpreter.
> 
> 

I know Paul would be for it, but I have no problem with defining the versioned binaries to not be created on Windows if that makes more sense there.
> On POSIX, there is generally "python", "python2", "python2.x", "python3" and "python3.y", with "python" referring to the default Python 2 install (except on Arch). CPython provided scripts that exist in both (like pydoc) have a similar naming scheme, while Python 3 only scripts (like pyvenv) omit the Python 2 variants, and the unqualified names refer to the Python 3 version.
> 
> At least pip 1.5+ follows the same naming conventions (I'm not sure about earlier versions).
> 
> 

Earlier versions had pip and pip-X.Y I believe… except on some Linux platforms where they helpfully removes the pip-X.Y and replaced it with pipX.
> So, I think there are two problems here:
> 
> 1. The dual Python 2/3 stacks that are common on POSIX systems
> 2. The more general problem of installing packages for multiple Python interpreters without naming conflicts in POSIX binary directories
> 
> I think we actually solved problem 1 pretty well when implementing ensurepip - the current UI for enabling it is a horrible internal-only hack, but the *behaviour* available when pip is installing itself under ensurepip is exactly what I would like to see standardised on that front (the python.commands extension in PEP 459 already distinguishes between entry points with wrappers to be generated at install time and pre-built scripts).
> 
Yes, when we implemented that my hope (goal?) was that we’d eventually remove the hacks and end up with something based on a standard.
> For the more general case, I don't believe we even have a behavioural precedent to consider following at this point.
> 
> Cheers,
> Nick.
> 
> >
> > -----------------
> > Donald Stufft
> > PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
> >
> >
> > _______________________________________________
> > Distutils-SIG maillist  -  Distutils-SIG at python.org
> > https://mail.python.org/mailman/listinfo/distutils-sig
> >


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20140519/0a1a2edd/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20140519/0a1a2edd/attachment.sig>