On 14 July 2013 16:34, Nick Coghlan <ncogh...@gmail.com> wrote: > On 14 July 2013 16:19, Noah Kantrowitz <n...@coderanger.net> wrote: > >> On Jul 13, 2013, at 10:58 PM, Nick Coghlan wrote: >> > On 14 July 2013 12:46, Donald Stufft <don...@stufft.io> wrote: >> > Either the existing APIs are moved to a different name, or they get >> declared stable and pip switches to "internally forked" APIs any time a >> backwards incompatible change is needed for refactoring purposes (see >> runpy._run_module_as_main for an example of needing to do this in the >> standard library). I've had to directly deal with too many issues arising >> from getting this wrong in the past for me to endorse bundling of a module >> that doesn't follow this practice with CPython - if introspection indicates >> an API is public, then it's public and subject to all standard library >> backwards compatibility guarantees, or else we take the pain *once* and >> explicitly mark it private by adding a leading underscore rather than >> leaving it in limbo (contextlib._GeneratorContextManager is a standard >> library example of the latter approach - it used to lack the leading >> underscore, suggesting it was a public API when it's really just an >> implementation detail of contextlib.contextmanager). >> > >> >> Respectfully, I disagree. Pip is not going in to the stdlib, and as such >> should not be subject to the same API stability policies as the stdlib. If >> the PyPA team wants to break the API every release, that is their call as >> the subject matter experts. Pip is not being included as a library at all. >> What should be subject to compat is the defined command line interface, >> because pip is a CLI tool. Independently of this discussion I've already >> been talking to the PyPA team about what they want to consider a stable >> API, but that is a discussion to be had over in pip-land, not here and not >> now. This new category of "bundled for your convenience but still external" >> applications will need new standards, and we should be clear about them for >> sure, but I think this is going too far and puts undue burden on the PyPA >> team. Remember the end goal is simply to get an installer in the hands of >> users easier. >> > > I would also be fine with a solution where "import pip" issues a warning > about API instability if sys.argv[0] indicates the main executable is > something other than the pip CLI. >
Oops, meant to add a point to https://github.com/pypa/pip/issues/1052 for that one. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
