https://github.com/pypa/pip/pull/1264
On Oct 27, 2013, at 7:45 PM, Nick Coghlan <ncogh...@gmail.com> wrote: > > On 28 Oct 2013 09:11, "Marcus Smith" <qwc...@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 <qwc...@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@python.org > >>> https://mail.python.org/mailman/listinfo/distutils-sig > >> > >> > > > > > > _______________________________________________ > > Distutils-SIG maillist - Distutils-SIG@python.org > > https://mail.python.org/mailman/listinfo/distutils-sig > > > > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > https://mail.python.org/mailman/listinfo/distutils-sig ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
