Re: pipenv and pip

On Mon, 20 Aug 2018 at 12:25, Wes Turner <[email protected]> wrote:
>
> On Monday, August 20, 2018, Paul Moore <[email protected]> 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 -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/
Message archived at https://mail.python.org/mm3/archives/list/[email protected]/message/7CCBE53AM72JYQVEW3PH7ODVRFZV4WXA/