[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 18:56:01 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
> cycle.
>
indeed this is looking like a regression. I have done:
* create 2 fresh conda environments
* downgrade pip to 7.1.2 in both (conda seems to put the latest pip in a
new environment by default)
$ pip --version
pip 7.1.2 from
/Users/chris.barker/miniconda2/envs/test2/lib/python2.7/site-packages
(python 2.7)
* build and install the package in one of them:
$ pip install ./
Processing /Users/chris.barker/Temp/geojson-1.3.2
Requirement already satisfied (use --upgrade to upgrade): setuptools in
/Users/chris.barker/miniconda2/envs/test1/lib/python2.7/site-packages/setuptools-19.4-py2.7.egg
(from geojson==1.3.2)
Building wheels for collected packages: geojson
Running setup.py bdist_wheel for geojson
Stored in directory:
/Users/chris.barker/Library/Caches/pip/wheels/67/47/d8/01cf2332293b60900ec87ff03bbe9fff92bc85f194e0eb0e74
Successfully built geojson
Installing collected packages: geojson
Successfully installed geojson-1.3.2
You are using pip version 7.1.2, however version 8.0.2 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.
It built and installed fine:
(test1)orrw-m-4179497:geojson-1.3.2 chris.barker$ python -c "import geojson"
(test1)orrw-m-4179497:geojson-1.3.2 chris.barker$
Now I go to install in the other environment:
first, check if geojson is there:
(test2)orrw-m-4179497:Temp chris.barker$ python -c "import geojson"
Traceback (most recent call last):
File "<string>", line 1, in <module>
ImportError: No module named geojson
nope.
so use pip to install from source
(test2)orrw-m-4179497:geojson-1.3.2 chris.barker$ pip install ./
Processing /Users/chris.barker/Temp/geojson-1.3.2
Requirement already satisfied (use --upgrade to upgrade): setuptools in
/Users/chris.barker/miniconda2/envs/test2/lib/python2.7/site-packages/setuptools-19.4-py2.7.egg
(from geojson==1.3.2)
Building wheels for collected packages: geojson
Running setup.py bdist_wheel for geojson
Stored in directory:
/Users/chris.barker/Library/Caches/pip/wheels/67/47/d8/01cf2332293b60900ec87ff03bbe9fff92bc85f194e0eb0e74
Successfully built geojson
Installing collected packages: geojson
Successfully installed geojson-1.3.2
You are using pip version 7.1.2, however version 8.0.2 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.
All good. See if it works:
(test2)orrw-m-4179497:Temp chris.barker$ python -c "import geojson; print
geojson.__version__"
1.3.2
(test2)orrw-m-4179497:Temp chris.barker$
yup -- all good.
However -- AARRGG! I then repeated that same exercise with pip 8.0.1, which
was failing for me before (multiple times) but it jsut worked!
This is really, really frustrating...did the downgrade, then re-upgrade of
pip somehow fix this? really, really weird.
OK -- well, I'm done for now with pip for building conda packages....
-CHB
>
> -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/f8e9e0d3/attachment.html>
More information about the Distutils-SIG
mailing list