[Distutils] Scripts/Entry Points Python-Version Naming

[Daniel Holth]

Then I vote for just another key that is a list of the
previously-defined scripts that should also have Python version
suffixes. Then pip's metadata would contain:

py_versioned_scripts = [ 'pip' ]

The installer would know to create additional names for the console
script called pip.


On Mon, May 19, 2014 at 8:25 PM, Donald Stufft <donald at stufft.io> wrote:
>
> On May 19, 2014, at 7:48 PM, Daniel Holth <dholth at gmail.com> wrote:
>
>> On Mon, 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.
>>>
>>> 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).
>>>
>>> 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).
>>>
>>> For the more general case, I don't believe we even have a behavioural
>>> precedent to consider following at this point.
>>>
>>> Cheers,
>>> Nick.
>>
>> I think of the problem as having two classes of programs: programs
>> that help you use Python itself (pip, ipython), and applications that
>> are useful on their own (Mercurial). Only the first kind should have
>> the Python version suffix. I find the second kind very interesting,
>> mature applications for which the implementation language is not a
>> nuisance for the user.
>
> I agree with these two classifications, however I'm also not sure if it
> actually matters or if something like Mercurial could just get the versioned
> suffixes and 99% of people just ignore them.
>
> -----------------
> Donald Stufft
> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
>