Then I vote for just another key that is a list of the previously-defined scripts that should also have Python version suffixes. Then pip's metadata would contain:
py_versioned_scripts = [ 'pip' ] The installer would know to create additional names for the console script called pip. On Mon, May 19, 2014 at 8:25 PM, Donald Stufft <[email protected]> wrote: > > On May 19, 2014, at 7:48 PM, Daniel Holth <[email protected]> wrote: > >> On Mon, May 19, 2014 at 7:40 PM, Nick Coghlan <[email protected]> wrote: >>> >>> On 20 May 2014 01:38, "Donald Stufft" <[email protected]> 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 > _______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
