On Thu, Aug 16, 2012 at 1:30 PM, Olemis Lang
<olemis-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> https://bitbucket.org/hasienda/t-h.o_shadow
>
... so I'm wondering , is it possible to change requirements rules so that pip will download plugins from t-h.o_shadow hg repository ?
It's not clear what you're asking. Of course you can edit your own requirements.txt file to refer to different URLs. But this t-h.o_shadow repository is a single repository, and pip does not support installing from a subdirectory of a (non-SVN) repository: pip insists that the package you are installing (specifically the setup.py file) is located at the repository root. This feature has been requested[1] but no one has implemented it in pip.
You should probably clone the t-h.o_shadow repository, copy the subdirectories with the plugins you need, create tar.gz files for those plugins yourself by running `python setup.py sdist` and host those tar.gz files on a server you control. This has two advantages; in addition to making sure that your release doesn't depend on external circumstances, you will also be pinning your release to specific known versions of its dependencies. Your release's requirements.txt file would then just point to the proper self-hosted tar.gz files for all of its dependencies, and your trunk's requirements-dev.txt file would point to the unpinned original codebases. I've done this "cheaply" by [ab]using Github Pages to host my dependencies[2,3,4] -- but the tar.gz files could even be checked in to your repository tree under the release; pip supports installing from relative file paths. I've taken this approach before[5]; it's by far the simplest way to ensure that your code ships with all its dependencies available.
If you're asking whether a pip requirements file supports "fallbacks" -- so that it tries a backup URL if the default one is not available -- the answer is "yes and no." This is exactly what a Python Package Index is for: your requirements file would just specify the required name and version number for each dependency, and the installer (pip) would be responsible for finding an available package matching that spec, by searching on the package index(es) for an available download. The Trac community doesn't always follow Python conventions here -- plugins are not always released on PyPI, and plugin version numbers often mirror their supported Trac version instead of being "independent" version numbers -- but this is not really an issue. You can create your own Package Index easily, upload the necessary plugin releases there, and use pip's `find-links` option to point to it instead of (or in addition to) the canonical PyPI. Then your requirements file could just specify "AccountManager==someversion" and pip would find an available copy satisfying the spec by searching through the package indexes you specify -- also in the requirements file[6].
Ultimately though this doesn't really add value beyond pointing directly to self-hosted copies of the releases; in either case the bulk of the work is the same (creating the copies of the releases, hosting them somewhere yourself, and making sure your release points to those copies of the code)
-Ethan
[4]
http://dist.socialplanning.org/ whose /eggs/ subpath can be used by ``find-links``, or individual code packages can be referred to directly by a requirements file
RSS Feed