[Distutils] Scripts/Entry Points Python-Version Naming

Donald Stufft donald at stufft.io
Tue May 20 02:25:57 CEST 2014


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

-------------- 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/db4ca3b4/attachment-0001.sig>


More information about the Distutils-SIG mailing list