[Distutils] Removing dependency_links

[Nick Coghlan]

On 28 Oct 2013 09:11, "Marcus Smith" <qwcode at gmail.com> wrote:
>
> Chris:
> to be clear, after talking to Donald, we interpreted your question
differently.
>
> - If you're distributing library Y, and it depends on X, but it now needs
a custom/fixed fork of X, then what Donald said,  rename and re-publish (or
vendor it).
> - If you just need to override a buggy pypi package locally in your app Y
install, then what I said (you can also use a vcs requirement form, and not
have to package you fork)

And to clarify the rationale for these as the official solutions:
installing modified software under the *same* name as the original is not
something we wish to support through PyPI, as it makes even cursory
security audits far more difficult than they should be, and can cause
additional confusion when debugging problems.

If a package maintainer for a dependency doesn't release regular updates or
is otherwise not responsive to bug reports, then the appropriate solutions
are:
- offering a function for runtime monkey patching of the dependency
- bundling a patched copy directly
- forking the dependency
- using application level dependencies to force installation of the patched
version

Implicit monkey patching and silently replacing the upstream dependency
with a patched version is quite user hostile when publishing software for
use by others in a Python installation that may be used to run multiple
independent applications.

Thinking about this further, perhaps we should institute a PyPI side
lockout for usage of dependency links in *new* projects? (similar to what
happened for the external hosting support and is proposed for direct
references in PEP 426)

(Which would put this in YAPP territory - *sigh*)

Cheers,
Nick.

P.S. Yet Another Packaging PEP. Feel free to infer the implied presence of
additional adjectives ;)

>
>
> On Sun, Oct 27, 2013 at 3:52 PM, Marcus Smith <qwcode at gmail.com> wrote:
>>
>>
>>
>>>
>>> So I asked the person I know, and this is what he said, "Yes, we have
>>> to use it!  It's the only way to allow a package to install other
>>> packages that aren't on PyPI-- for instance, a custom fork of a
>>> library."
>>>
>>> Is there another approach or work-around he can be using?  What is the
>>> "right" way for him to do it?
>>
>>
>> e.g. you find a bug in SomeProject-1.4 on pypi (which is a dependency in
your app install)
>> fork it, fix it, and re-version it to SomeProject-1.4-myfork1, then
package it, and place it in "/my/forks"
>> and then "pip install --find-links=/my/forks/  my_app"
>>
>> as for fork versioning in the long run, that is intended to be covered
in PEP440, with a conversation happening here:
>>
https://bitbucket.org/pypa/pypi-metadata-formats/issue/1/add-local-numbering-to-pep-440
>>
>>
>>
>>>
>>>
>>> --Chris
>>> _______________________________________________
>>> Distutils-SIG maillist  -  Distutils-SIG at python.org
>>> https://mail.python.org/mailman/listinfo/distutils-sig
>>
>>
>
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20131028/2fe51caf/attachment-0001.html>