I'm used to working with unstable versions for most of my numpy/scipy/etc stack (usually from git head). So I have installed numpy 1.11.0.dev0-3397fce, scipy 0.17.0.dev0-279ef0c, etc. I have extracted matplotlib from git, but when I build this ("python setup.py build", or even with "python setup.py develop --no-deps"), it keeps building it's own numpy 1.9.2 egg, look at this snippet of the output:
...
Installed /usr/local/src/matplotlib/.eggs/numpy-1.9.2-py2.7-linux-x86_64.egg
/usr/lib/python2.7/site-packages/setuptools/dist.py:316: UserWarning: Module numpy was already imported from /usr/lib/python2.7/site-packages/numpy/__init__.pyc, but /usr/local/src/matplotlib/.eggs/numpy-1.9.2-py2.7-linux-x86_64.egg is being added to sys.path
...
Strange thing is, in the beginning matplotlib seems to happily recognize my numpy:
REQUIRED DEPENDENCIES AND EXTENSIONS
numpy: yes [version 1.11.0.dev0+3397fce]
dateutil: yes [using dateutil version 2.4.2]
pytz: yes [using pytz version 2015.4]
cycler: yes [using cycler version 0.9.0]
tornado: yes [using tornado version 4.2.1]
pyparsing: yes [using pyparsing version 2.0.3]
libagg: yes [Requires patches that have not been merged
upstream. Using local copy.]
freetype: yes [version 2.6.0]
png: yes [version 1.6.18]
qhull: yes [pkg-config information for 'qhull' could not be
found. Using local copy.]
However, it immediately starts building numpy 1.9.2 after that.
Having more than one version of numpy (or whatever python package) just messes up my system, I don't want several different versions of numpy to co-exist. Anything I can do to make matplotlib recognize and use my numpy from git?
Did you use pip to install those in-development versions of numpy etc., or
just 'setup.py install'? The latter is unfortunately broken in several ways
-- what might be biting you here is that it does not install the package
metadata (.egg-info or .dist-info) that setuptools and pip need to know
whether numpy is installed or not, what version it is, etc. -- this is
separate from just having a numpy directory on your pythonpath. (Another
thing that will bite you in the future is that when you use
distutils/setup.py to install a package, then it's impossible to correctly
uninstall or upgrade that package later, because it doesn't make a record
of what files were installed.)
The best / only correct way to install a package from source or a git
checkout is 'pip install <source dir>'; never run setup.py directly.
(Yes, this is absurd, but I don't make the rules...)
-n
···
On Sep 11, 2015 03:30, "Vincent Schut" <schut at sarvision.nl> wrote:
Hi,
I'm used to working with unstable versions for most of my numpy/scipy/etc
stack (usually from git head). So I have installed numpy
1.11.0.dev0-3397fce, scipy 0.17.0.dev0-279ef0c, etc. I have extracted
matplotlib from git, but when I build this ("python setup.py build", or
even with "python setup.py develop --no-deps"), it keeps building it's own
numpy 1.9.2 egg, look at this snippet of the output:
...
Installed
/usr/local/src/matplotlib/.eggs/numpy-1.9.2-py2.7-linux-x86_64.egg
/usr/lib/python2.7/site-packages/setuptools/dist.py:316: UserWarning:
Module numpy was already imported from
/usr/lib/python2.7/site-packages/numpy/__init__.pyc, but
/usr/local/src/matplotlib/.eggs/numpy-1.9.2-py2.7-linux-x86_64.egg is being
added to sys.path
...
Strange thing is, in the beginning matplotlib seems to happily recognize
my numpy:
REQUIRED DEPENDENCIES AND EXTENSIONS
numpy: yes [version 1.11.0.dev0+3397fce]
dateutil: yes [using dateutil version 2.4.2]
pytz: yes [using pytz version 2015.4]
cycler: yes [using cycler version 0.9.0]
tornado: yes [using tornado version 4.2.1]
pyparsing: yes [using pyparsing version 2.0.3]
libagg: yes [Requires patches that have not been merged
upstream. Using local copy.]
freetype: yes [version 2.6.0]
png: yes [version 1.6.18]
qhull: yes [pkg-config information for 'qhull' could not
be
found. Using local copy.]
However, it immediately starts building numpy 1.9.2 after that.
Having more than one version of numpy (or whatever python package) just
messes up my system, I don't want several different versions of numpy to
co-exist. Anything I can do to make matplotlib recognize and use my numpy
from git?
Best,
Vincent.
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org Matplotlib-devel Info Page
Did you use pip to install those in-development versions of numpy etc., or just 'setup.py install'? The latter is unfortunately broken in several ways -- what might be biting you here is that it does not install the package metadata (.egg-info or .dist-info) that setuptools and pip need to know whether numpy is installed or not, what version it is, etc. -- this is separate from just having a numpy directory on your pythonpath. (Another thing that will bite you in the future is that when you use distutils/setup.py to install a package, then it's impossible to correctly uninstall or upgrade that package later, because it doesn't make a record of what files were installed.)
The best / only correct way to install a package from source or a git checkout is 'pip install <source dir>'; never run setup.py directly.
(Yes, this is absurd, but I don't make the rules...)
Ha, I somtimes have the feeling that absurdity is part of my job description I think my habits are still from the pre-pip era (or at least my pre-pip era). So if I run 'pip install .' from the numpy git checkout folder, it should work? Going to try immediately!
Thanks!
Vincent.
···
On 09/11/15 12:40, Nathaniel Smith wrote:
-n
On Sep 11, 2015 03:30, "Vincent Schut" <schut at sarvision.nl <mailto:schut at sarvision.nl>> wrote:
Hi,
I'm used to working with unstable versions for most of my numpy/scipy/etc stack (usually from git head). So I have installed numpy 1.11.0.dev0-3397fce, scipy 0.17.0.dev0-279ef0c, etc. I have extracted matplotlib from git, but when I build this ("python setup.py build", or even with "python setup.py develop --no-deps"), it keeps building it's own numpy 1.9.2 egg, look at this snippet of the output:
...
Installed /usr/local/src/matplotlib/.eggs/numpy-1.9.2-py2.7-linux-x86_64.egg
/usr/lib/python2.7/site-packages/setuptools/dist.py:316: UserWarning: Module numpy was already imported from /usr/lib/python2.7/site-packages/numpy/__init__.pyc, but /usr/local/src/matplotlib/.eggs/numpy-1.9.2-py2.7-linux-x86_64.egg is being added to sys.path
...
Strange thing is, in the beginning matplotlib seems to happily recognize my numpy:
REQUIRED DEPENDENCIES AND EXTENSIONS
numpy: yes [version 1.11.0.dev0+3397fce]
dateutil: yes [using dateutil version 2.4.2]
pytz: yes [using pytz version 2015.4]
cycler: yes [using cycler version 0.9.0]
tornado: yes [using tornado version 4.2.1]
pyparsing: yes [using pyparsing version 2.0.3]
libagg: yes [Requires patches that have not been merged
upstream. Using local copy.]
freetype: yes [version 2.6.0]
png: yes [version 1.6.18]
qhull: yes [pkg-config information for 'qhull' could not be
found. Using local copy.]
However, it immediately starts building numpy 1.9.2 after that.
Having more than one version of numpy (or whatever python package) just messes up my system, I don't want several different versions of numpy to co-exist. Anything I can do to make matplotlib recognize and use my numpy from git?
Best,
Vincent.
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org <mailto:Matplotlib-devel at python.org> Matplotlib-devel Info Page
Did you use pip to install those in-development versions of numpy etc., or
just 'setup.py install'? The latter is unfortunately broken in several ways
-- what might be biting you here is that it does not install the package
metadata (.egg-info or .dist-info) that setuptools and pip need to know
whether numpy is installed or not, what version it is, etc. -- this is
separate from just having a numpy directory on your pythonpath.
weird that
setup.py develop --nodeps doesn't work, though.
The best / only correct way to install a package from source or a git
checkout is 'pip install <source dir>'; never run setup.py directly.
(Yes, this is absurd, but I don't make the rules...)
Yeah, the separation of concerns of distutils, setuptools, pipi, etc is a
big hairy mess.
But we *could* force, or at least encourage, the use of setuptools in the
numpy build. The reason pip works is because it Monkey-patches setuptools
into the install process.
Or maybe I'm am mis-informed - this is very tangled up!
-CHB
···
On Fri, Sep 11, 2015 at 3:40 AM, Nathaniel Smith <njs at pobox.com> wrote:
-n
On Sep 11, 2015 03:30, "Vincent Schut" <schut at sarvision.nl> wrote:
Hi,
I'm used to working with unstable versions for most of my numpy/scipy/etc
stack (usually from git head). So I have installed numpy
1.11.0.dev0-3397fce, scipy 0.17.0.dev0-279ef0c, etc. I have extracted
matplotlib from git, but when I build this ("python setup.py build", or
even with "python setup.py develop --no-deps"), it keeps building it's own
numpy 1.9.2 egg, look at this snippet of the output:
...
Installed
/usr/local/src/matplotlib/.eggs/numpy-1.9.2-py2.7-linux-x86_64.egg
/usr/lib/python2.7/site-packages/setuptools/dist.py:316: UserWarning:
Module numpy was already imported from
/usr/lib/python2.7/site-packages/numpy/__init__.pyc, but
/usr/local/src/matplotlib/.eggs/numpy-1.9.2-py2.7-linux-x86_64.egg is being
added to sys.path
...
Strange thing is, in the beginning matplotlib seems to happily recognize
my numpy:
REQUIRED DEPENDENCIES AND EXTENSIONS
numpy: yes [version 1.11.0.dev0+3397fce]
dateutil: yes [using dateutil version 2.4.2]
pytz: yes [using pytz version 2015.4]
cycler: yes [using cycler version 0.9.0]
tornado: yes [using tornado version 4.2.1]
pyparsing: yes [using pyparsing version 2.0.3]
libagg: yes [Requires patches that have not been merged
upstream. Using local copy.]
freetype: yes [version 2.6.0]
png: yes [version 1.6.18]
qhull: yes [pkg-config information for 'qhull' could not
be
found. Using local copy.]
However, it immediately starts building numpy 1.9.2 after that.
Having more than one version of numpy (or whatever python package) just
messes up my system, I don't want several different versions of numpy to
co-exist. Anything I can do to make matplotlib recognize and use my numpy
from git?
Best,
Vincent.
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org Matplotlib-devel Info Page
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org Matplotlib-devel Info Page
--
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
The best / only correct way to install a package from source or a git
checkout is 'pip install <source dir>'; never run setup.py directly.
(Yes, this is absurd, but I don't make the rules...)
Yeah, the separation of concerns of distutils, setuptools, pipi, etc is a
big hairy mess.
But we *could* force, or at least encourage, the use of setuptools in the
numpy build. The reason pip works is because it Monkey-patches setuptools
into the install process.
Or maybe I'm am mis-informed - this is very tangled up!
pip monkeypatches setuptools into the install process... but first it
monkeypatches setuptools to fix various weird behaviors. If you just use
setuptools directly then you don't get the same thing as pip install.
Off the top of my head: setuptools will try to easy_install any
dependencies, and setuptools will default to installing into a weird
directory with a .pth file. I'm not sure that it records what files were
installed either. OTOH does at least install .egg-info so that other tools
can tell that your package is installed later.
While we're piling on, I think (it's hard to know) that I ran into an issue
where pip was (thankfully) installing a local package with zip_safe=False,
but setup.py was only install the egg, making accessing the package's
bundled data very difficult.
On Fri, Sep 11, 2015 at 10:09 AM, Nathaniel Smith <njs at pobox.com> wrote:
On Sep 11, 2015 9:13 AM, "Chris Barker" <chris.barker at noaa.gov> wrote:
>
> On Fri, Sep 11, 2015 at 3:40 AM, Nathaniel Smith <njs at pobox.com> wrote:
[...]
>>
>> The best / only correct way to install a package from source or a git
checkout is 'pip install <source dir>'; never run setup.py directly.
>>
>> (Yes, this is absurd, but I don't make the rules...)
>
> Yeah, the separation of concerns of distutils, setuptools, pipi, etc is
a big hairy mess.
>
> But we *could* force, or at least encourage, the use of setuptools in
the numpy build. The reason pip works is because it Monkey-patches
setuptools into the install process.
>
> Or maybe I'm am mis-informed - this is very tangled up!
pip monkeypatches setuptools into the install process... but first it
monkeypatches setuptools to fix various weird behaviors. If you just use
setuptools directly then you don't get the same thing as pip install.
Off the top of my head: setuptools will try to easy_install any
dependencies, and setuptools will default to installing into a weird
directory with a .pth file. I'm not sure that it records what files were
installed either. OTOH does at least install .egg-info so that other tools
can tell that your package is installed later.
>
[...]
>>
>> The best / only correct way to install a package from source or a git checkout is 'pip install <source dir>'; never run setup.py directly.
>>
>> (Yes, this is absurd, but I don't make the rules...)
>
> Yeah, the separation of concerns of distutils, setuptools, pipi, etc is a big hairy mess.
>
> But we *could* force, or at least encourage, the use of setuptools in the numpy build. The reason pip works is because it Monkey-patches setuptools into the install process.
>
> Or maybe I'm am mis-informed - this is very tangled up!
pip monkeypatches setuptools into the install process... but first it monkeypatches setuptools to fix various weird behaviors. If you just use setuptools directly then you don't get the same thing as pip install.
Off the top of my head: setuptools will try to easy_install any dependencies, and setuptools will default to installing into a weird directory with a .pth file. I'm not sure that it records what files were installed either. OTOH does at least install .egg-info so that other tools can tell that your package is installed later.
It is a mess.
-n
While we're piling on, I think (it's hard to know) that I ran into an issue where pip was (thankfully) installing a local package with zip_safe=False, but setup.py was only install the egg, making accessing the package's bundled data very difficult.
So yeah, +1 for "pip install <package_dir>"
A mess it is. Pip install <dir> seems to work, though, so that's propably a keeper (for as long as it takes). Gonna change the auto update script for my scientific python stack.
Thanks for all the interesting comments.
Vincent.
···
On 09/11/15 19:44, Paul Hobson wrote:
On Fri, Sep 11, 2015 at 10:09 AM, Nathaniel Smith <njs at pobox.com <mailto:njs at pobox.com>> wrote:
On Sep 11, 2015 9:13 AM, "Chris Barker" <chris.barker at noaa.gov <mailto:chris.barker at noaa.gov>> wrote:
> On Fri, Sep 11, 2015 at 3:40 AM, Nathaniel Smith <njs at pobox.com <mailto:njs at pobox.com>> wrote:
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org Matplotlib-devel Info Page
I think my habits are still from the pre-pip era (or at least my pre-pip era). So if I run 'pip install .' from the numpy git checkout folder, it should work? Going to try immediately!