On Mon, 20 Aug 2018 at 12:25, Wes Turner
On Monday, August 20, 2018, Paul Moore
wrote:
I know "security by obscurity" doesn't work, but I'm happier if details of this library *aren't* widely known - it's not something I'd want to encourage people using, nor is it supported by pip, as it's basically a direct interface into pip's internal functions, papering over the name changes that we did in pip 10 specifically to dissuade people from doing this.
If someone was committing to identifying useful API methods, parameters, and return values; writing a ~PEP; implementing said API; and maintaining backwards compatible shims for some reason; would something like `pip.api` be an appropriate namespace? (now that we're on version 18 with a faster release cycle)?
I'm not quite sure I know what you mean here. The key point is that pip 18.0 might have an internal function pip._internal.xxx, and in pip 18.1 there's no such function, and the functionality doesn't even exist any more. How would a 3rd party project maintain backwards compatible shims in the face of that? Agreed it's not likely in practice - but we're not going to guarantee it. To be honest I don't see the point of discussing pip's internal API. It's just that - internal. I'd rather discuss useful (general) packaging libraries, that tools can build on - pip can vendor those and act as (just) another consumer, rather than getting into debates about support and internal APIs. Paul