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

[Nathaniel Smith]

On Thu, Jan 28, 2016 at 4:28 PM, Chris Barker <chris.barker at noaa.gov> wrote:
[...]
>   Source in /tmp/pip-umxsOD-build has version 3.0.3, which satisfies
> requirement gsw==3.0.3 from
> file:///Users/chris.barker/miniconda2/conda-bld/work/gsw-3.0.3
>
>   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

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.

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

> Requirement already satisfied (use --upgrade to upgrade): numpy in
> /Users/chris.barker/miniconda2/envs/_build/lib/python2.7/site-packages (from
> gsw==3.0.3)
>
> Requirement already satisfied (use --upgrade to upgrade): nose in
> /Users/chris.barker/miniconda2/envs/_build/lib/python2.7/site-packages (from
> gsw==3.0.3)
>
> Building wheels for collected packages: gsw
>
>   Running setup.py bdist_wheel for gsw ...   Destination directory:
> /tmp/tmprPhOYkpip-wheel-
>
>   Running command /Users/chris.barker/miniconda2/envs/_build/bin/python -u
> -c "import setuptools,
> tokenize;__file__='/tmp/pip-umxsOD-build/setup.py';exec(compile(getattr(tokenize,
> 'open', open)(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))"
> bdist_wheel -d /tmp/tmprPhOYkpip-wheel- --python-tag cp27

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.

> (BTW, I can replicate this behavior outside of conda build by creating a new
> conda environment by hand, and trying to ues pip to build a package locally)
>
> So I tried various command-line options:
>
> $PYTHON -m pip install -I -v --upgrade --no-deps ./
>
> but no dice.
>
> I also tried --no-cache-dir -- no change.

Maybe

$PYTHON -m pip install --no-cache-dir --upgrade --force-reinstall ./

? Though I'd think that -I would have the same affect as --force-reinstall...

(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.

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. I don't know if there are any bugs filed
in pip on this...)

-n

-- 
Nathaniel J. Smith -- https://vorpus.org