Note removal of dependency_links option

[stephenfin]

Just provide a breadcrumb for users (like me) who wondered what happened to this feature.

[notatallshaw]

Hi, thanks for submitting a PR to pip.

However, I don't think we should be updating pip's changelog from over five years ago. The way you've updated this implies this is something that changed in 2019.

Further, pip and setuptools are two separate applications, pip does not directly call setup.py any more, it calls setuptools which can call setup.py depending on the configuration. I therefore think any documentation about how setup.py works should be added to setuptools: https://github.com/pypa/setuptools.

[stephenfin]

Hi, thanks for submitting a PR to pip.

However, I don't think we should be updating pip's changelog from over five years ago. The way you've updated this implies this is something that changed in 2019.

That's my intention. pip 19.0 is the version that dropped the functionality that the option required so it makes sense to change the changelog for that version. While the changelog notes the removal of the CLI option, it doesn't note the impact on configuration files.

Further, pip and setuptools are two separate applications, pip does not directly call setup.py any more, it calls setuptools which can call setup.py depending on the configuration. I therefore think any documentation about how setup.py works should be added to setuptools: https://github.com/pypa/setuptools.

Oh, I know. But this is a historical note and that wasn't the case back then. It looks like pipenv also had support for the option (as a passthrough to setuptools) back then, but I don't see any sense in enumerating all package managers since most (all?) of them wrapped setuptools at the time.

Again, I'm just trying to provide a small breadcrumb for users, but I'm okay with closing this if it doesn't suit.

[ichard26]

I'm fine with helping people understand what happened with setup.py (I assume that our changelog ranks well in a Google search), but I'm pretty sure this is subtly wrong. pip removed support for dependency_links first (maybe because setuptools had deprecated it? I'm not sure about the history) and then setuptools dropped it when it removed easy_install. Would it be better if we mentioned the alternative?

- - Remove the deprecated ``--process-dependency-links`` option. (`#6060 <https://github.com/pypa/pip/issues/6060>`_)
+ - Remove the deprecated ``--process-dependency-links`` option. Affected users should consider using Direct URL dependency specifiers instead (`#6060 <https://github.com/pypa/pip/issues/6060>`_

I would link to some documentation explaining what a direct URL is, but alas, I'm not aware of any good user-friendly resources about direct URL requirements. There is the formal specification, but that's overly technical :(

[pfmoore]

Would it be better if we mentioned the alternative?

I'm inclined not to - from what I recall (I never used dependency links myself) they aren't a complete replacement, so you could easily end up with people getting more confused, rather than helping them.

I agree with @notatallshaw here - this happened (in pip) 5 years ago, and I doubt anyone is still using dependency links by now. For people (like OP) interested in the history, the changelog is accurate in terms of what happened in pip. For more general information about the dependency links feature itself, interested researchers should be looking at the change history for the tool (setuptools) that provided it.

since most (all?) of them wrapped setuptools at the time.

I'll add one point of clarification here. Pip (and probably most of the other tools you refer to) didn't "wrap" setuptools, in the sense of exposing setuptools functionality with a different interface. Rather, pip used setuptools to implement some of pip's functionality. The difference is subtle (and I'm almost certainly rewriting history to match how I view things now) but important, as it means that I don't think you should expect pip to document setuptools features (we never did, and since PEP 517 introduced the idea of alternative build backends it no longer even makes sense to do so).

Thanks @stephenfin for your interest in improving pip, but I think this is something best left unaltered.

[ichard26]

In that case, I'll close the PR. Thanks for taking the time to file the PR even if we ultimately did not accept it.

[stephenfin]

No problem. Thanks for the reviews nonetheless 🙏