Closed tibor95 closed 9 years ago
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
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:)
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
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.
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 ?
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 :)
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
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! :)
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
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.
HI,
when trying to install it on Debian Jesie, it failed with [truncated]:
packages python3-dev and python-dev are installed.
Any idea?