[Distutils] Scripts/Entry Points Python-Version Naming

[Paul Moore]

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.