Nick: 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@gmail.com>:
On 21 October 2017 at 20:03, Paul Moore <p.f.moore@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.
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig