<div dir="ltr">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.<div>
<br></div><div>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.</div>
<div><br></div><div>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:</div>
<div><br></div><div>map( 'foo<=1.5', <span style="font-size:13px;font-family:arial,sans-serif"> git+<a href="https://myrepo/foo@master#">https://myrepo/foo@master#</a></span><span style="font-size:13px;font-family:arial,sans-serif">egg=1.5 )</span></div>
<div><span style="font-size:13px;font-family:arial,sans-serif"><br></span></div><div><span style="font-size:13px;font-family:arial,sans-serif">or with patterns</span></div><div><span style="font-size:13px;font-family:arial,sans-serif"><br>
</span></div><div><div>map_re( '(bar-.*)<=(.*)', <span style="font-size:13px;font-family:arial,sans-serif"> git+<a href="https://myrepo/$1@master#">https://myrepo/$1@master#</a></span><span style="font-size:13px;font-family:arial,sans-serif">egg=$1-$2 )</span></div>
</div><div><span style="font-size:13px;font-family:arial,sans-serif"><br></span></div><div>This is probably a bit naive, especially with respect to how it translates the version constraint into a concrete version.</div><div>
<br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jan 17, 2014 at 6:46 PM, Marcus Smith <span dir="ltr"><<a href="mailto:qwcode@gmail.com" target="_blank">qwcode@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<br>
<p dir="ltr">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.</p>

</blockquote><div><br></div></div><div>so, instead of  </div><div><br></div><div>    pip install  git+https://myrepo@master#egg=toplevelapp</div><div><br></div><div>it's this:</div><div><br></div><div>    deplinks_scantool  git+https://myrepo@master#egg=toplevelapp  > requirements.txt</div>

<div>    pip install -r requirements.txt</div><div><br></div><div><br></div><div>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</div>

<div><br></div></div></div></div>
<br>_______________________________________________<br>
Distutils-SIG maillist  -  <a href="mailto:Distutils-SIG@python.org">Distutils-SIG@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/distutils-sig" target="_blank">https://mail.python.org/mailman/listinfo/distutils-sig</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Hannes Schmidt<br>Software Application Developer<br>Data Migration Engineer<br>Cancer Genomics Hub<br>University of California, Santa Cruz<br>
<br>(206) 696-2316 (cell)<br><a href="mailto:hannes@ucsc.edu" target="_blank">hannes@ucsc.edu</a></div>
</div>