On Fri, Jan 29, 2016 at 12:25 PM, Robert Collins <robe...@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.bar...@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@python.org > > https://mail.python.org/mailman/listinfo/distutils-sig > > > > -- > Robert Collins <rbtcoll...@hpe.com> > Distinguished Technologist > HP Converged Cloud > > > -- > Robert Collins <rbtcoll...@hpe.com> > Distinguished Technologist > HP Converged Cloud > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@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.bar...@noaa.gov
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
