flowgrad / scoop

Automatically exported from code.google.com/p/scoop
GNU Lesser General Public License v3.0
0 stars 0 forks source link

Scoop does not find zmq #9

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
What version of the product are you using? On what operating system?

$ python -V
Python 2.7.7

$ lsb_release -a
LSB Version:    
:base-4.0-amd64:base-4.0-noarch:core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd6
4:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch
Distributor ID: RedHatEnterpriseServer
Description:    Red Hat Enterprise Linux Server release 6.4 (Santiago)
Release:        6.4
Codename:       Santiago

What steps will reproduce the problem?
1. Download 0.7.1 tarball, open it and cd into the directory 

2. Verify that pyzmq is available:

python -c "import zmq; print 'It is there'"

3. Try to install scoop with:

python setup.py install --prefix=$MY_INSTALL_DIR

What is the expected output? What do you see instead?

(....a bunch of irrelevant output....)

error: command 'gcc' failed with exit status 1

Failed with default libzmq, trying again with /usr/local
************************************************
Configure: Autodetecting ZMQ settings...
    Custom ZMQ dir:       /usr/local
Assembler messages:
Fatal error: can't create 
build/temp.linux-x86_64-2.7/scratch/tmp/easy_install-L0czGy/pyzmq-14.3.1/temp/ti
mer_create9prql0.o: No such file or directory
build/temp.linux-x86_64-2.7/scratch/vers.c:4:17: fatal error: zmq.h: No such 
file or directory
 #include "zmq.h"
                 ^
compilation terminated.

The problem is that zmq.h is in a non-standard location, available to python 
but not to scoop. 

What is the recommended way of telling scoop where zmq is located?

PS: this is related to issue 8, but that has been closed without anybody being 
assigned to it and just dismissing as a pyzmq installation problem (which is 
not: both pyzmq and zmq are correctly installed and used by other software on 
this system)

Original issue reported on code.google.com by ddve...@ucar.edu on 15 Jul 2014 at 5:04

GoogleCodeExporter commented 8 years ago
Sorry for the dismissal of your ticket. I thought you could reopen it if you 
had more information to add.

Your problem lies in the fact that the SCOOP installer doesn't find pyzmq. I 
suspect that it may be linked to the fact that you specify a --prefix 
parameter. I suggest you try using a virtual environment, which does in 
practice what the --prefix parameter does but gives you a more coherent Python 
installation without the need to modify PYTHONPATH or similar environment 
variables.
If you really need the --prefix, I guess you should set your PYTHONPATH and/or 
PYTHONHOME environment variables to where your Python librairies (containing 
pyzmq) are.

The setuptools installer of SCOOP only checks if pyzmq >= [required version] is 
available on the system. If it is, it doesn't try to install it. I find it 
strange that you are experiencing an issue.

Original comment by yannickh...@gmail.com on 15 Jul 2014 at 5:24

GoogleCodeExporter commented 8 years ago
No, google does not allow me to reopen a closed ticket. And no, I
cannot use a virtual environment.

The problem is not about pyzmq. That is in PYTHONPATH already and it
is found as demonstrated by the python -c 'import zmq' line.
The problem is that scoop uses also zmq (the C library, not the python
binding) directly. And it can not find that (because that's installed
on a non-standard location: fyi, that is the policy for our machine,
each library is installed in its own non-standard location, so that it
can easily ignored when needed, and there can easily be different
versions of the same library installed).

In fact the error is in the gcc call, not in python, so PYTHONPATH can
not help. I could solve the problem by creating a gcc wrapper that
calls gcc with additional -L and -I with the actual path where zmq is
installed, but I was wondering if scoop provides a way to specify that
directory directly

Thanks!

Original comment by ddve...@ucar.edu on 15 Jul 2014 at 5:37

GoogleCodeExporter commented 8 years ago
Little annoying stuff like incapacity for users to handle their tickets starts 
to make me believe that I should move to Github...

I know understand your workflow, thanks for explaining it. That clarifies 
things up.

What I was talking about was that maybe --prefix modifies the way Python 
handles its paths.

SCOOP doesn't use directly the C zmq library nor does it need any compilation; 
its sources are pure Python. "import zmq" actually imports pyzmq which uses 
either Cython or CFFI to talk to the libzmq C library.

The error you see comes from the compilation de pyzmq and not SCOOP (since it 
does not invoke any C compiler to install itself). I just tried it using Python 
3.4 and SCOOP doesn't try to install pyzmq if it's already found on the system, 
without providing a --prefix parameter. When providing the --prefix parameter, 
Python complained about "error: bad install directory or PYTHONPATH". After 
configuring my PYTHONPATH accordingly, everything worked.

There seems like something is wrong. Your invocation of python returns that 
pyzmq is correctly installed, but setuptools tries to install it anyway... Have 
you got a recent version of setuptools? Is the problem still present if you 
remove the pyzmq entry in the requirements in the setup.py file?

Original comment by yannickh...@gmail.com on 15 Jul 2014 at 7:14

GoogleCodeExporter commented 8 years ago
Ok, thanks for clarifying that zmq is not needed (directly). You may
want to clarify that on the requirement section at:
http://scoop.readthedocs.org/en/0.7/install.html

As a test, I will try not to specify the --prefix, but I do need it,
so that's not the solution. I do not believe it's an issue with
setuptools because I installed dozens of other python package using
--prefix (and many of them having dependencies) and none of them
failed in this way. By the way, I am using setuptools 4.0.1

One other strange thing that scoop does is installing
argparse-1.2.1-py2.7.egg even if I'm running it against python 2.7.7
which has argparse builtin.

Original comment by ddve...@ucar.edu on 15 Jul 2014 at 7:48