<p dir="ltr">On Jan 29, 2016 7:48 AM, "Chris Barker - NOAA Federal" <<a href="mailto:chris.barker@noaa.gov">chris.barker@noaa.gov</a>> wrote:<br>
><br>
> >>  Requirement already satisfied (use --upgrade to upgrade): gsw==3.0.3 from<br>
> >> file:///Users/chris.barker/miniconda2/conda-bld/work/gsw-3.0.3 in<br>
> >> /Users/chris.barker/miniconda2/conda-bld/work/gsw-3.0.3<br>
> ><br>
> > I think this is saying that pip thinks it has found an<br>
> > already-installed version of gsw 3.0.3 in sys.path, and that the<br>
> > directory in your sys.path where it's already installed is<br>
> ><br>
> > /Users/chris.barker/miniconda2/conda-bld/work/gsw-3.0.3<br>
><br>
> That is the temp dir conda sets up to unpack downloaded files, and do<br>
> its work in -- hence the name. I'll look and see what's there. I'm<br>
> pretty sure conda build starts out with an empty dir, however. And<br>
> that dir should not be on sys.path.</p>
<p dir="ltr">This is the point where I'd probably start adding print statements to my local copy of pip. E.g. grep for that "requirement already satisfied" message and then have it print out sys.path as well. To me this still smells like some simple bug in one of conda, your environment, or pip, so it's worth figuring out...</p>
<p dir="ltr">> > I think this means that that directory is (a) in sys.path, and (b)<br>
> > contains a .egg-info/.dist-info directory for gsw 3.0.3. Part (a)<br>
> > seems weird and broken.<br>
><br>
> Indeed. And I get the same symptoms with a clean environment that I've<br>
> set up outside conda build. Though with the same source dir. But with<br>
> conda build, it's a fresh unpack of the tarball.<br>
><br>
> > Do you have "." in your PYTHONPATH or anything like that?<br>
><br>
> God no!</p>
<p dir="ltr">Too bad, it would have been an easy explanation ;-)</p>
<p dir="ltr">> > Don't know why it seems to be building a wheel for it, if it already<br>
> > thinks that it's installed... this is also odd.<br>
><br>
> Yes it is. But it doesn't install it :-(<br>
><br>
> ><br>
> > $PYTHON -m pip install --no-cache-dir --upgrade --force-reinstall ./<br>
> ><br>
> > ? Though I'd think that -I would have the same affect as --force-reinstall...<br>
> ><br>
> So did I, and I think I tried --force-reinstall already, but I will again.<br>
><br>
> > (It doesn't look like the cache dir is your problem here, but you do<br>
> > probably want to use --no-cache-dir anyway just as good practice, just<br>
> > because you don't want to accidentally package up a stale version of<br>
> > the software that got pulled out of your cache instead of the version<br>
> > you thought you were packaging in the tree in front of you.<br>
><br>
> Exactly. Doesn't seem to make a difference, though.<br>
><br>
> > Also, I think it's a bug in pip that it caches builds of source trees<br>
> > -- PyPI can enforce the rule that each (package name, version number)<br>
> > sdist is unique, but for a work-in-progress VCS checkout it's just not<br>
> > true that (package name, version number) uniquely identifies a<br>
> > snapshot of the whole tree. So in something like 'pip install .', then<br>
> > requirement resolution code should treat this as a special requirement<br>
> > that it wants *this exact tree*, not just any package that has the<br>
> > same (package name, version number) as this tree; and the resulting<br>
> > wheel should not be cached.<br>
><br>
> Absolutely! In fact, I'll bet that approach is the source of the<br>
> problem here. If not automagically, there should be a flag, at least.</p>
<p dir="ltr">Maybe... it looks like at least @dstufft agrees that the current behavior is a bug:</p>
<p dir="ltr">  <a href="https://github.com/pypa/pip/issues/536">https://github.com/pypa/pip/issues/536</a></p>
<p dir="ltr">and if this were fixed then it would at least hide your problem. But the underlying bug here is that pip seems to think that a package is installed when it wasn't. Hacking it to ignore whether a package is installed would just be papering over this.</p>
<p dir="ltr">-n</p>