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 <[email protected]> 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 - [email protected] > 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) [email protected]
_______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
