[Distutils] Removing dependency_links

[Donald Stufft]

On Oct 27, 2013, at 1:07 AM, holger krekel <holger at merlinux.eu> wrote:

> On Sun, Oct 27, 2013 at 14:30 +1000, Nick Coghlan wrote:
>> On 27 October 2013 14:13, Donald Stufft <donald at stufft.io> wrote:
>>> 
>>> On Oct 26, 2013, at 11:59 PM, Donald Stufft <donald at stufft.io> wrote:
>>> 
>>>> Ok here’s the real list: https://gist.github.com/dstufft/7177500
>>> 
>>> Quick note that this list is a list of projects that have *ever* used
>>> dependency links on PyPI. Some of these projects are no longer
>>> using them.
>> 
>> Am I correct in thinking that providing a flag to disable them
>> completely will be enough to get ensurepip to behave itself?
>> 
>> If so, then the bare minimum is to provide such a flag in the bundled
>> versions of pip and setuptools and have ensurepip use it.
>> 
>> I also think it is reasonable to continue offering a feature like
>> dependency_links on an opt-in basis for controlled environments (I see
>> it as analagous to the direct references feature in PEP 440).
>> 
>> That would make the migration look something like:
>> 
>> pip 1.5 (and associated minimum required version of setuptools):
>>  - add a disable switch for dependency link handling
>>  - add at least a per-project opt-in for dependency link handling
>> (and perhaps a global opt-in)
>>  - deprecate implicit handling of dependency links
>> 
>> pip 1.6:
>>  - dependency links are disabled by default, must opt-in to process them
> 
> So 400 projects out of 35000 ever used dependency links.
> I checked three random ones:
> 
> - flask-mongorest: does not use it anymore
> - Pylons: deplink goes to 502 page, and has the latest release on pypi.
> - OpenCoreRedirect: one of out three deplinks work but goes to a page 
>  that doesn't appear to be one.  Latest release is 0.5.1, available
>  on pypi Project, four years old.

Heh, Webtest and Flask-Security were two I checked who no longer use them.

> 
> Judging from this little sample: if a questionable feature is used by
> <1% of projects and even they likely to not work/don't rely on it
> anymore, i don't think we should spend or make Donald spend much efforts
> on it.  Rather do the supposed 1.6 change for 1.5 already.

I’m definitely +1 on doing the change in 1.5 instead. I really don’t think it’s
going to affect hardly anyone.

> 
> Note that I was the guy publically pressing for backward-compat but 
> that was for the introduction of "--pre" which broke many usages.  This
> does not start to compare to this change here.  Also pip-1.5 would
> cleanly bail out and tell what to do whereas the need for "--pre" was
> more implicit as people could get the wrong version suddenly without
> noticing/understanding.
> 
> best,
> holger


-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20131027/f9426902/attachment-0001.sig>