<br><br><div class="gmail_quote">On Sun, Sep 23, 2012 at 10:20 PM, Nathaniel Smith <span dir="ltr"><<a href="mailto:njs@pobox.com" target="_blank">njs@pobox.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Sat, Sep 22, 2012 at 1:18 PM, Ralf Gommers <<a href="mailto:ralf.gommers@gmail.com">ralf.gommers@gmail.com</a>> wrote:<br>
> On Fri, Sep 21, 2012 at 11:39 PM, Nathaniel Smith <<a href="mailto:njs@pobox.com">njs@pobox.com</a>> wrote:<br>
</div><div class="im">>> So the question is, how do we get a .egg-info? For the specific case<br>
>> Ralf ran into, I'm pretty sure the solution is just that if you're<br>
>> clever enough to do an in-place build and add it to your PYTHONPATH,<br>
>> you should be clever enough to also run 'python setupegg.py egg_info'<br>
>> which will create a .egg-info to go with your in-place build and<br>
>> everything will be fine.<br>
><br>
> That command first starts rebuilding numpy.<br>
<br>
</div>No, it just seems to run the config and source-generation bits, not<br>
build anything. It also leaves the .egg-info in the source directory,<br>
which is what you want.<br></blockquote><div><br>You're right, sorry. I saw output like "building extension "numpy.core._dotblas" sources" scrolling by and hit Ctrl-C. <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<div class="im"><br>
>> P.S.: yeah the thing where pip decides to upgrade the world is REALLY<br>
>> OBNOXIOUS. It also appears to be on the list to be fixed in the next<br>
>> release or the next release+1, so I guess there's hope?:<br>
>> <a href="https://github.com/pypa/pip/pull/571" target="_blank">https://github.com/pypa/pip/pull/571</a><br>
><br>
> Good to know. Let's hope that does make it in. Given it's development model,<br>
> I'm less optimistic that easy_install will receive the same fix though ....<br>
<br>
</div>Yeah, easy_install is abandoned and bit-rotting, which is why people<br>
usually recommend pip :-). But in this case, I thought that<br>
easy_install already doesn't upgrade the world when it runs? Is there<br>
something to fix here?<br></blockquote><div><br>It does, as Josef said above. It has the same -U and --no-deps flags.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im"><br>
> Until both pip and easy_install are fixed, this alone should be enough for<br>
> the advice to be "don't use install_requires". It's not like my alternative<br>
> suggestion takes away any information or valuable functionality.<br>
<br>
</div>pandas, for example, requires several other packages, and I found it<br>
quite convenient the other day when I wanted to try out a new version<br>
and pip automatically took care of setting all that up for me. It even<br>
correctly upgraded numpy, since the virtualenv I was using for testing<br>
had inherited my system-installed 1.5.2, but this was the first<br>
version of pandas that needed 1.6.<br></blockquote><div><br>So this saved you from reading "pandas requires numpy >= 1.6.1" and typing "pip install -U numpy". Not my definition of valuable functionality, and certainly not worth the risk of upgrading numpy silently for users.<br>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Python packaging tools make me feel grumpy and traumatized too but I<br>
don't see how the solution is to just give up on computer-readable<br>
dependency-tracking altogether.<span class="HOEnZb"></span><br></blockquote><div><br>Proper dependency tracking would be preferable, but none at all is better than the current situation imho.<br><br>Ralf<br><br></div></div>