python setup.py install fails

[tibor95]

HI,

when trying to install it on Debian Jesie, it failed with [truncated]:

Warning: distutils distribution has been initialized, it may be too late to add an extension lapack_liteWarning: distutils distribution has been initialized, it may be too late to add an extension _umath_linalgWarning: distutils distribution has been initialized, it may be too late to add a subpackage linalgWarning: distutils distribution has been initialized, it may be too late to add an extension mtrandWarning: distutils distribution has been initialized, it may be too late to add a subpackage randomWarning: distutils distribution has been initialized, it may be too late to add a subpackage maWarning: distutils distribution has been initialized, it may be too late to add a subpackage matrixlibWarning: distutils distribution has been initialized, it may be too late to add a subpackage compatWarning: distutils distribution has been initialized, it may be too late to add a subpackage polynomialWarning: distutils distribution has been initialized, it may be too late to add a subpackage docWarning: distutils distribution has been initialized, it may be too late to add a subpackage numpyCould not locate executable gfortran
Could not locate executable f95
Could not locate executable ifort
Could not locate executable ifc
Could not locate executable lf95
Could not locate executable pgfortran
Could not locate executable f90
Could not locate executable f77
Could not locate executable fort
Could not locate executable efort
Could not locate executable efc
Could not locate executable g77
Could not locate executable g95
Could not locate executable pathf95
don't know how to compile Fortran code on platform 'posix'
_configtest.c:1:5: warning: conflicting types for built-in function 'exp'
 int exp (void);
     ^
_configtest.o: In function `main':
/tmp/easy_install-c6PsRC/numpy-1.9.2/_configtest.c:6: undefined reference to `exp'
collect2: error: ld returned 1 exit status
_configtest.o: In function `main':
/tmp/easy_install-c6PsRC/numpy-1.9.2/_configtest.c:6: undefined reference to `exp'
collect2: error: ld returned 1 exit status
_configtest.c:1:5: warning: conflicting types for built-in function 'exp'
 int exp (void);
     ^
_configtest.c:1:20: fatal error: Python.h: No such file or directory
 #include Python.h
                    ^
compilation terminated.
_configtest.c:1:20: fatal error: Python.h: No such file or directory
 #include Python.h
                    ^

packages python3-dev and python-dev are installed.

Any idea?

[ftomassetti]

What is happening is that it is trying to compile several C-extensions dependencies. WorldEngine uses several libraries including the famous numpy. You may want to look for debian packages of numpy instead of compiling it from scratch. I think you should run something like:

sudo apt-get install python-numpy

and possibly installing other libraries dependending on the next errors. In general you need to install additional packages to compile C extensions to python. I would try running:

sudo apt-get install python-dev

this should install Python.h and the corresponding libraries.

Let me know if you have other issues: we are here to help

[tibor95]

I had numpy installed, but the problem is that specific version was required (I think 1.9.2), of course this was different version than installed one. Is such strict dependency (exact version) really needed or is it just small mistake on your side?

I had python-dev installed as well, maybe this was not the problem, but just some consequence of previous failure.

I will try to install it on arch linux now, perhaps I will have more luck here:)

[tibor95]

Oh, I made it, but I would suggest following change to Readme:

# before using worldengine: if you want just to install worldengine
# on unix-ish system
# to install system-wide as root (sudo might be needed for root credentials)
python setup.py install
# or to install under current user (safer) run
python setup.py install --user
# in this case the binary will be generated as
~/.local/bin/worldengine

Linux users, tend to be quite sensitive about security, I think.

I am going to play with it now

[psi29a]

We shouldn't be playing around with system libraries anyway.

If installing worldengine through pypi or gitlab, it is preferred to set up your libs in virtualenv. This will prevent version conflicts as your system will likely have outdated python libs.

example: virtualenv venv source venv/bin/activate pip install -r requirements_base.txt python setup.py install

^-- This will setup everything within your new venv without root access and keeps everything in one tidy place.

[ftomassetti]

Yes, I would also use virtualenv. About having a more relaxed dependency constraint it is something we should consider. On one hand having a specific version permit us to guarantee that everything works, on the other end if your distro install a different version of numpy it is probably better to use it instead of forcing users to download and compile numpy (even if it happens automatically through pip). What do you think @psi29a ?

[tibor95]

I will try the virtualenv aproach next time - it looks good to me, only it should be placed closer to "Install" section of homepage...

and if virtualenv is able to get proper dependencies, no need to relax the rules.....

I am closing this issue :)

[tibor95]

Oh, why nothing goes easy? I am going virtualenv way:

$ pip install -r requirements_base.txt
Requirement already satisfied (use --upgrade to upgrade): Pillow==2.6.1 in ./venv/lib/python2.7/site-packages (from -r requirements_base.txt (line 1))
Requirement already satisfied (use --upgrade to upgrade): PyPlatec==1.3.1.post1 in ./venv/lib/python2.7/site-packages (from -r requirements_base.txt (line 2))
Requirement already satisfied (use --upgrade to upgrade): langgen==0.1.2 in ./venv/lib/python2.7/site-packages (from -r requirements_base.txt (line 3))
Requirement already satisfied (use --upgrade to upgrade): argparse==1.2.1 in /usr/lib/python2.7 (from -r requirements_base.txt (line 4))
Requirement already satisfied (use --upgrade to upgrade): noise==1.2.2 in ./venv/lib/python2.7/site-packages (from -r requirements_base.txt (line 5))
Requirement already satisfied (use --upgrade to upgrade): nose==1.3.1 in ./venv/lib/python2.7/site-packages (from -r requirements_base.txt (line 6))
Requirement already satisfied (use --upgrade to upgrade): numpy==1.9.2 in ./venv/lib/python2.7/site-packages (from -r requirements_base.txt (line 7)
Cleaning up...)

$ python setup.py install
......
Installed /home/tibor/devel/worldengine/worldengine-master/venv/lib/python2.7/site-packages/worldengine-0.18.0-py2.7.egg
Processing dependencies for worldengine==0.18.0
Searching for numpy==1.9.2
Best match: numpy 1.9.2
Adding numpy 1.9.2 to easy-install.pth file
......
Using /home/tibor/devel/worldengine/worldengine-master/venv/lib/python2.7/site-packages
Finished processing dependencies for worldengine==0.18.0

$  worldengine
Traceback (most recent call last):
  File "/usr/local/bin/worldengine", line 5, in 
    from pkg_resources import load_entry_point
  File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 2876, in 
    working_set = WorkingSet._build_master()
  File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 451, in _build_master
    return cls._build_from_requirements(__requires__)
  File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 464, in _build_from_requirements
    dists = ws.resolve(reqs, Environment())
  File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 639, in resolve
    raise DistributionNotFound(req)
pkg_resources.DistributionNotFound: numpy==1.9.2

This is Debian Jessie again

[tibor95]

Oh yes, /usr/local/bin/worldengine is some residual from previous attempts (I know that installing something out of package manager is bad idea, but how to get rid of it now?)

proper way is to call venv/bin/worldengine from within worldengine-master folder. It works now finally! :)

[ftomassetti]

Happy that it works :D

Sometimes it is a bit complicated to distribute Python packages.... and we should definitely improve the way we package WorldEngine, so feedback is precious for us.

Cheers, Federico

On Mon, Jun 15, 2015 at 9:34 AM, tibor95 notifications@github.com wrote:

Oh yes, /usr/local/bin/worldengine is some residual from previous attempts (I know that installing something out of package manager is bad idea, but how to get rid of it now?)

proper way is to call venv/bin/worldengine from within worldengine-master folder. It works now finally! :)

— Reply to this email directly or view it on GitHub https://github.com/Mindwerks/worldengine/issues/73#issuecomment-111978359 .

Website at http://tomassetti.me http://www.federico-tomassetti.it GitHub https://github.com/ftomassetti

[psi29a]

Yeah, when dealing with Python... some batteries are not included.

I'm honestly of the opinion that if we ship our own applications, then it is just i386 and x86_64 packages with venvs and a wrapper script that ties everything together. This should work for Linux, Mac and Windows.

We can automate this I think with appveyor and travisci.