Drawing from my Maven experience, there is no direct equivalent to dependency_links in Maven. In pom.xml (the equivalent of setup.py) one specifies dependencies and version constraints. This is the "what". In ~/.m2/settings.xml one specifies the repositories to be scanned for those dependencies. That's the "where". You *can* specify repositories in pom.xml, too, but I always considered that an artificial use case, and if I remember correctly, there were controversies about that.

I do actually think that dependency_links meddles the "what" and the "where" concerns which is one reason I sort of agree with its removal. I'm just not convinced it's a good idea to remove it without offering an equally convenient alternative. By convenient I mean that it facilitates installation directly from source repository without the need of going through a separate and mostly redundant (due to Python being an interpreted language) package repository.

I'd be completely happy with specifying the mapping from "what" to "where" in a configuration file, outside of setup.py. That would be even more convenient since it would be more DRY than having dependency_links in every package's setup.py. The mapping could be Python code consisting of lines like:

map( 'foo<=1.5', git+https://myrepo/foo@master#egg=1.5 )

or with patterns

map_re( '(bar-.*)<=(.*)', git+https://myrepo/$1@master#egg=$1-$2 )

This is probably a bit naive, especially with respect to how it translates the version constraint into a concrete version.

On Fri, Jan 17, 2014 at 6:46 PM, Marcus Smith <qwcode@gmail.com> wrote:

Imposing backwards incompatible changes like this one, however well justified, always brings with it a certain responsibility to help users in managing the transition. In this case, I suspect a *separate* link scanning tool (which we can put as many security warnings on as you like) that generates a requirements.txt file may be a more appropriate approach than just telling users to use built packages on a private HTTP or PyPI server, since spinning up and maintaining new server infrastructure is often a much more challenging prospect in user environments than installing and using a new client tool.

so, instead of

pip install git+https://myrepo@master#egg=toplevelapp

it's this:

deplinks_scantool git+https://myrepo@master#egg=toplevelapp > requirements.txt

pip install -r requirements.txt

the scan tool step is pretty hefty in that it's downloading and running egg_info, but yes, I can see that being easier for some users than dealing with packaging

_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Hannes Schmidt
Software Application Developer
Data Migration Engineer
Cancer Genomics Hub
University of California, Santa Cruz

(206) 696-2316 (cell)
hannes@ucsc.edu