[Distutils] How to get pip to really, really, I mean it -- rebuild this damn package!

[Chris Barker - NOAA Federal]

>>  Requirement already satisfied (use --upgrade to upgrade): gsw==3.0.3 from
>> file:///Users/chris.barker/miniconda2/conda-bld/work/gsw-3.0.3 in
>> /Users/chris.barker/miniconda2/conda-bld/work/gsw-3.0.3
>
> I think this is saying that pip thinks it has found an
> already-installed version of gsw 3.0.3 in sys.path, and that the
> directory in your sys.path where it's already installed is
>
> /Users/chris.barker/miniconda2/conda-bld/work/gsw-3.0.3

That is the temp dir conda sets up to unpack downloaded files, and do
its work in -- hence the name. I'll look and see what's there. I'm
pretty sure conda build starts out with an empty dir, however. And
that dir should not be on sys.path.

> I think this means that that directory is (a) in sys.path, and (b)
> contains a .egg-info/.dist-info directory for gsw 3.0.3. Part (a)
> seems weird and broken.

Indeed. And I get the same symptoms with a clean environment that I've
set up outside conda build. Though with the same source dir. But with
conda build, it's a fresh unpack of the tarball.

> Do you have "." in your PYTHONPATH or anything like that?

God no!

> Don't know why it seems to be building a wheel for it, if it already
> thinks that it's installed... this is also odd.

Yes it is. But it doesn't install it :-(

>
> $PYTHON -m pip install --no-cache-dir --upgrade --force-reinstall ./
>
> ? Though I'd think that -I would have the same affect as --force-reinstall...
>
So did I, and I think I tried --force-reinstall already, but I will again.

> (It doesn't look like the cache dir is your problem here, but you do
> probably want to use --no-cache-dir anyway just as good practice, just
> because you don't want to accidentally package up a stale version of
> the software that got pulled out of your cache instead of the version
> you thought you were packaging in the tree in front of you.

Exactly. Doesn't seem to make a difference, though.

> Also, I think it's a bug in pip that it caches builds of source trees
> -- PyPI can enforce the rule that each (package name, version number)
> sdist is unique, but for a work-in-progress VCS checkout it's just not
> true that (package name, version number) uniquely identifies a
> snapshot of the whole tree. So in something like 'pip install .', then
> requirement resolution code should treat this as a special requirement
> that it wants *this exact tree*, not just any package that has the
> same (package name, version number) as this tree; and the resulting
> wheel should not be cached.

Absolutely! In fact, I'll bet that approach is the source of the
problem here. If not automagically, there should be a flag, at least.

However, what seems to be happening is that pip is looking outside the
current Python environment somewhere to see if this package needs to
be installed. It may be something that works with virtualenv, but
doesn't with conda environments for some reason.

I guess on some level pip simply isn't designed to build and install
from local source :-(

In the end, I'm still confused: does pip install give me anything that:

setup.py install single-version-externally-managed

Doesn't? Other that support for non-setuptools installs, anyway.

CHB


> I don't know if there are any bugs filed
> in pip on this...)
>
> -n
>
> --
> Nathaniel J. Smith -- https://vorpus.org