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

Chris Barker chris.barker at noaa.gov
Fri Jan 29 16:01:37 EST 2016


On Fri, Jan 29, 2016 at 12:25 PM, Robert Collins <robertc at robertcollins.net>
wrote
>
>
> Please try pip 7.1? Latest before 8; we're not meant to be caching
> wheels of by-location things from my memory, but it may have
> regressed/changed with the cache changes made during the 8 development
>

will do -- in fact, I was pretty sure this was working earlier....

stay tuned.

-CHB



> cycle.
>
> -Rob
>
> On 30 January 2016 at 04:48, Chris Barker - NOAA Federal
> <chris.barker at noaa.gov> wrote:
> >>>  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
> > _______________________________________________
> > Distutils-SIG maillist  -  Distutils-SIG at python.org
> > https://mail.python.org/mailman/listinfo/distutils-sig
>
>
>
> --
> Robert Collins <rbtcollins at hpe.com>
> Distinguished Technologist
> HP Converged Cloud
>
>
> --
> Robert Collins <rbtcollins at hpe.com>
> Distinguished Technologist
> HP Converged Cloud
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20160129/745d0978/attachment.html>


More information about the Distutils-SIG mailing list