[Distutils] Please do not remove dependency_links

[Hannes Schmidt]

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 at 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 at 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 at ucsc.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20140117/d30671ae/attachment.html>