On Mon, May 19, 2014 at 9:28 AM, Donald Stufft <donald@stufft.io> wrote:
On May 19, 2014, at 8:16 AM, Bohuslav Kabrda <bkabrda@redhat.com> wrote:
Hi all, (I hope that this hasn't been discussed previously) so I've been trying to find out whether there's an explicit recommendation for creating and naming scripts/entry points depending on Python version that they're built with, but I didn't find any. As an example, setuptools' easy_install uses "easy_install-MAJOR.MINOR" (with dash), while pip uses "pipMAJOR.MINOR" (without a dash). Also, some projects only create "foo-MAJOR.MINOR", while others also create "foo-MAJOR" (and most also create "foo" without any versions). 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
Or better yet, I think it'd make sense to provide setuptools facilites to create these variants in a sensible default way and provide installation flags to alter this behaviour. Right now, it seems to me that every project is doing this on its own, which is not only inconsistent, but it also duplicates lots of efforts and is more error prone than providing one centralized solution (e.g. a function in distutils/setuptools).
Thoughts/comments? Thanks!
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.