How would I (said library) maintain compatibility? I’m pretty clever. The shim library doesn’t actually do anything besides provide import paths. If I shim something that didn’t exist, it shims None for any pip versions where it doesn’t exist. So for example if you are running pip 9 and you import RequirementTracker from the shims library you just import None
Dan Ryan // pipenv maintainer gh: @techalchemy > On Aug 20, 2018, at 8:15 AM, Paul Moore <p.f.mo...@gmail.com> wrote: > >> 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/ -- 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/HUR6KLVCSFY3Z7SIQ6J2CXDURFO3YCEK/
