[Distutils] Announcement: Pip 10 is coming, and will move all internal APIs
xoviat at gmail.com
Sat Oct 21 14:03:02 EDT 2017
That's generally a good idea, but one significant problem that can occur is
that the Python import system will cache certain libraries, people will run
"pip install," and then they will expect such libraries to be available. I
don't even know exactly how the caching for the import system works, so I
don't want to go and make claims about it that may be incorrect (maybe you
do?). However, it is important to keep that in mind when considering an API.
2017-10-21 6:15 GMT-05:00 Nick Coghlan <ncoghlan at gmail.com>:
> On 21 October 2017 at 20:03, Paul Moore <p.f.moore at gmail.com> wrote:
>> Likely the biggest problems will be for people who call into the pip
>> resolver and build APIs, as I don't know of any alternatives out
>> there. But they were *definitely* breaking anyway, as we've made major
>> changes to that code (and will be making more).
>> Also, I should note that we didn't take this decision lightly. We
>> don't have any particular objection in principle to having a supported
>> stable pip API, it's just that we don't have anything even close to
>> the resources needed to define a supported API, maintain it with
>> acceptable backward compatibility guarantees, and support users who
>> will inevitably be using it in unexpected and creative ways (we don't
>> even have the resources to support the limited use of pip's internals
>> that we see today). Also, pip was never designed originally as a
>> library, so we *would* have to design that API from scratch. As I
>> alluded to above, the existing internals code makes some strong
>> assumptions about how it's called - assumptions that would be
>> unacceptable in library code, but are fine in an application's
>> internal code.
> (Note: this is entirely speculative, and I have no idea how hard it would
> be, so please read it as the question it's intended to be)
> Do you know if there any key APIs (like installation) that could be turned
> into wrappers around pip CLI calls in order to mitigate some of the impact?
> The reason I ask is because it's unlikely anyone else is going to
> understand how to emulate the previous functionality better than the pip
> devs would, and if there's an API for those particular invocations, than
> they can be covered directly by pip's test suite.
> Plus if there are previous API capabilities that *can't* currently be
> emulated via the CLI, then the pip devs are the folks in the best position
> to add the necessary CLI enhancements (such as the ones Noah asked about
> for doing a more selective `pip list`).
> If that's an approach you might be amenable to, then a 10.0 pre-release
> could be a good time to solicit PRs from folks that were using particular
> APIs and would be prepared to invest time in defining comparable CLI
> wrappers for them.
> Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
> Distutils-SIG maillist - Distutils-SIG at python.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Distutils-SIG