On 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. > > I know Paul would be for it, but I have no problem with defining the versioned binaries to not be created on Windows if that makes more sense there. > 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). > > Earlier versions had pip and pip-X.Y I believe… except on some Linux platforms where they helpfully removes the pip-X.Y and replaced it with pipX. > 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). > Yes, when we implemented that my hope (goal?) was that we’d eventually remove the hacks and end up with something based on a standard. > For the more general case, I don't believe we even have a behavioural > precedent to consider following at this point. > > Cheers, > Nick. > > > > > ----------------- > > 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 > > ----------------- 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
