On Mon, 20 Aug 2018 at 12:25, Wes Turner <wes.tur...@gmail.com> wrote: > > On Monday, August 20, 2018, Paul Moore <p.f.mo...@gmail.com> 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 -- Distutils-SIG mailing list -- distutils-sig@python.org To unsubscribe send an email to distutils-sig-le...@python.org https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/ Message archived at https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/7CCBE53AM72JYQVEW3PH7ODVRFZV4WXA/
