On May 19, 2014, at 11:36 AM, Paul Moore <[email protected]> wrote:
> On 19 May 2014 15:38, Daniel Holth <[email protected]> wrote: >> On Mon, May 19, 2014 at 9:28 AM, Donald Stufft <[email protected]> wrote: >>> On May 19, 2014, at 8:16 AM, Bohuslav Kabrda <[email protected]> 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
