I'm only briefly checking my email before going back to sleep but just thought I'd mention I have a successor to PEP439 mostly written and I was planning on finishing it up based on some feedback i'd gotten and publishing it this week.
More specific response when I'm not half asleep. On Aug 19, 2013, at 7:31 AM, Paul Moore <[email protected]> wrote: > While debate on PEP 439 has died down, I've been thinking about what it > actually means to end users for Python to bundle pip. If we have an explicit > bootstrapping command like get_pip, how much practical benefit is there for > that to be bundled vs having a well-known location for such a script (which > is more or less what we have now)? > > Also, there is the whole question of how much we want to "lock down" what pip > currently provides, as official functionality. (Particularly given the > renewed energy around projects like distlib/distil, etc). > > I'd like to propose that as a first step, we agree and document a *user > interface* that will be officially supported going forward. It would be based > on (a subset of) the pip interface, so that a "bundle pip" strategy is still > the immediate way forward, but by standardising the interface rather than the > implementation, we retain the option to change things behind the scenes if, > for example, distil suddenly takes over the world. > > Users get the benefit of a properly sanctioned "one true way" to manage > packages. And we reserve enough flexibility that we don't accidentally accept > constraints that are stronger than we'd like and stifle innovation. > > To be specific, what I propose is that we agree on the following: > > 1. Python installations provide a bootstrap command (tentatively "python -m > get_pip", I'm not sure this needs to be directly executable, the -m interface > is probably fine). This command may be a no-op if for example we opt for full > bundling (and it will always be a no-op after the first run). > 2. Once bootstrapped, Python will provide a "pip" command (or pip3?) > accessible whenever the "python" command is available (worded this way > because the Windows installer doesn't put "python" on PATH by default). > 3. A specific subset of the current pip interface is provided (to be > documented). I'd suggest we need a minimum of pip install, pip list, pip > uninstall, pip install -U (for upgrades). I don't know what proportion of the > rest of the pip API (various options, requirement files, environment > variables and ini files) we want to lock down - I suggest we start minimal > and add items as needed. > 4. We may want to add a separate note that "python -m pip" will do the same > as the "pip" command, and may be needed to self-upgrade the pip command > ("python -m pip -U pip"). > > We can note for 3.4 that the pip command will be implemented using the > current pip project, and so all of the other features of pip will be > available, but with the proviso that any interfaces not explicitly mentioned > in the standard documentation may be changed or removed as pip changes, and > are not protected by Python's compatibility rules. That gives users a > reasonable level of stability, while still allowing us the room to innovate. > > Does this sound reasonable? It may be obvious to everyone but me that this is > what we're expecting - or I may even be proposing *more* than people expect. > But I think something along the lines of an "interface over implementation" > definition like this would be reasonable. > > If this is a useful proposal and no-one else is already working on something > similar, I'm willing to write this up as a PEP. > > Paul. > _______________________________________________ > Distutils-SIG maillist - [email protected] > http://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] http://mail.python.org/mailman/listinfo/distutils-sig
