On Sat, 21 Oct 2017 at 11:03 xoviat <xov...@gmail.com> wrote: > 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. >
Nick does know how the import system works, but to specifically address this point, as long as the module isn't already imported it's fine. If it has, though, then you will need to do a reload instead of an import, and even then that doesn't necessarily work the way some people want it to. -Brett > > 2017-10-21 6:15 GMT-05:00 Nick Coghlan <ncogh...@gmail.com>: > >> On 21 October 2017 at 20:03, Paul Moore <p.f.mo...@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 | ncogh...@gmail.com | Brisbane, Australia >> >> _______________________________________________ >> Distutils-SIG maillist - Distutils-SIG@python.org >> https://mail.python.org/mailman/listinfo/distutils-sig >> >> > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > https://mail.python.org/mailman/listinfo/distutils-sig >
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
