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) 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
