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. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
