<p dir="ltr"><br>
On 28 Oct 2013 09:11, "Marcus Smith" <<a href="mailto:qwcode@gmail.com">qwcode@gmail.com</a>> wrote:<br>
><br>
> Chris:<br>
> to be clear, after talking to Donald, we interpreted your question differently.<br>
><br>
> - 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).  <br>
> - 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)</p>
<p dir="ltr">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.</p>

<p dir="ltr">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:<br>
- offering a function for runtime monkey patching of the dependency<br>
- bundling a patched copy directly<br>
- forking the dependency<br>
- using application level dependencies to force installation of the patched version</p>
<p dir="ltr">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.</p>

<p dir="ltr">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)</p>

<p dir="ltr">(Which would put this in YAPP territory - *sigh*)</p>
<p dir="ltr">Cheers,<br>
Nick.</p>
<p dir="ltr">P.S. Yet Another Packaging PEP. Feel free to infer the implied presence of additional adjectives ;)</p>
<p dir="ltr">><br>
><br>
> On Sun, Oct 27, 2013 at 3:52 PM, Marcus Smith <<a href="mailto:qwcode@gmail.com">qwcode@gmail.com</a>> wrote:<br>
>><br>
>><br>
>><br>
>>><br>
>>> So I asked the person I know, and this is what he said, "Yes, we have<br>
>>> to use it!  It's the only way to allow a package to install other<br>
>>> packages that aren't on PyPI-- for instance, a custom fork of a<br>
>>> library."<br>
>>><br>
>>> Is there another approach or work-around he can be using?  What is the<br>
>>> "right" way for him to do it?<br>
>><br>
>><br>
>> e.g. you find a bug in SomeProject-1.4 on pypi (which is a dependency in your app install)<br>
>> fork it, fix it, and re-version it to SomeProject-1.4-myfork1, then package it, and place it in "/my/forks"<br>
>> and then "pip install --find-links=/my/forks/  my_app"<br>
>><br>
>> as for fork versioning in the long run, that is intended to be covered in PEP440, with a conversation happening here:<br>
>> <a href="https://bitbucket.org/pypa/pypi-metadata-formats/issue/1/add-local-numbering-to-pep-440">https://bitbucket.org/pypa/pypi-metadata-formats/issue/1/add-local-numbering-to-pep-440</a><br>
>><br>
>><br>
>>  <br>
>>><br>
>>><br>
>>> --Chris<br>
>>> _______________________________________________<br>
>>> Distutils-SIG maillist  -  <a href="mailto:Distutils-SIG@python.org">Distutils-SIG@python.org</a><br>
>>> <a href="https://mail.python.org/mailman/listinfo/distutils-sig">https://mail.python.org/mailman/listinfo/distutils-sig</a><br>
>><br>
>><br>
><br>
><br>
> _______________________________________________<br>
> Distutils-SIG maillist  -  <a href="mailto:Distutils-SIG@python.org">Distutils-SIG@python.org</a><br>
> <a href="https://mail.python.org/mailman/listinfo/distutils-sig">https://mail.python.org/mailman/listinfo/distutils-sig</a><br>
><br>
</p>