[Distutils] Scripts/Entry Points Python-Version Naming

[Donald Stufft]

On May 19, 2014, at 11:36 AM, Paul Moore <p.f.moore at gmail.com> wrote:

> On 19 May 2014 15:38, Daniel Holth <dholth at gmail.com> wrote:
>> On Mon, May 19, 2014 at 9:28 AM, Donald Stufft <donald at stufft.io> wrote:
>>> On May 19, 2014, at 8:16 AM, Bohuslav Kabrda <bkabrda at redhat.com> wrote:
> [...]
>>>> It may seem like an overkill, but wouldn't it be best to standardize:
>>>> - which version is preferred (with or without dash)
>>>> - which of these three variants (foo-MAJOR.MINOR, foo-MAJOR, foo) should be created by default
> [...]
>>> I completely agree and this was something that has been on my radar for awhile.
>>> This also enables universal Wheels for projects that want/require having the
>>> version in the script name because the current way of hacking it yourself
>>> creates a command which is accurate for only one Python version. This is
>>> actually going to "do the wrong thing" in pure python Wheels because a wheel
>>> created with a script like that in Python 3.4 is also valid for Python 3.5 but
>>> the script wrappers will still have "3.4" in them.
>>> 
>>> Personally I feel that foo, fooX, fooX.Y is a reasonable standard and it
>>> matches what Python itself does. Being consistent seems like a reasonable goal
>>> to have with it.
>> 
>> Although I would suggest extending the idea. The version number suffix
>> "3" or "3.4" is a shorthand for referring to the Python environment in
>> which the script should run, including both the version of Python and
>> the set of packages which are importable in that environment, so that
>> for example copies of the "pip" installer for multiple Python
>> environments can exist on the same path. Since multiple Python 3.4's
>> can exist on the same system, this scheme is far too limiting.
>> 
>> Instead, to handle virtualenvs, scripts should be suffixed with the
>> hash of the absolute path to the interpreter and site-packages
>> directory.  So instead of pip-3.4 you get
>> pip-5c280763736b1c7ff400b1ffc87ad5c5e581c0cf32dbead89cbc6a2823a4c4e3 ;
>> the same for e.g. Mercurial
>> hg-5c280763736b1c7ff400b1ffc87ad5c5e581c0cf32dbead89cbc6a2823a4c4e3.
>> This scheme should be able to handle any number of Python versions &
>> environments without confusion.
> 
> :-)
> 
> Unless you have multiple versions of Python on your path and expect to
> be able to use them simultaneously, the unadorned script name ("foo"
> on Unix, "foo.exe" on Windows) should be entirely sufficient. However,
> unfortunately, some people do expect versioned executables to work,
> and have multiple Python executables on their path (it's standard to
> do so for Python 2 and 3 on Unix, after all...) and we should offer
> some support for those cases.
> 
> It seems to me that the only sane approach would be to follow the
> behaviour of Python itself (pythonX and pythonX.Y). And update pip and
> setuptools to automatically generate those forms on install. I'd
> almost argue that on Windows the versioned names should not be
> created, because Python doesn't have versioned names there, but that's
> probably a step too far.
> 
> This is a compatibility-breaking change, though, and would require
> executable names changing for some projects (after all, pip and
> easy_install themselves use different conventions - we'd need to get
> our own house in order before imposing a standard on others!) So it
> would need to be handled carefully, to make sure projects have a
> chance to deal with the impact. At a minimum, all projects would need
> to buy into the idea that versioning executables is no longer under
> their control, but is handled by the tools - projects that object to
> this could make a real mess by adding their own version numbers, or by
> using the old "scripts" approach and abandoning entry points.
> 
> Paul.

If we do standardize we should also likely standardize on how we handle
alternative interpreters. Things like PyPy, Jython etc.

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