I am trying to install the pycairo (Python bindings for the cairo graphics library) under OSX.
I started with
easy_install pycairo
and got:
Requested 'cairo >= 1.8.8' but version of cairo is 1.0.4
error: Setup script exited with Error: cairo >= 1.8.8 not found
So I went to cairo's site and downloaded the latest package (1.8.8) of cairo, and also the latest package of something called pixman (both source packages -- couldn't find osx binaries)
unzipped both, each in own directory.
for pixman, the regular ./configure ; make ; sudo make install worked just find
for cairo, ./configure seemed to work, but make failed with:
In file included from cairo-analysis-surface.c:37:
cairoint.h:71:20: error: pixman.h: No such file or directory
What am I doing wrong?
And why do I have to struggle so much to get a software library to work on an os that "just works"? Why isn't darwin more like linux?
If you already have homebrew, these two commands should be helpful:
$ brew install cairo --use-clang
$ brew install py2cairo
For a non-Homebrew installed Python, set the PYTHONPATH to find pycairo. You can set your PYTHONPATH in your .bashrc/.profile/.whatever to the following:
PYTHONPATH=/usr/local/lib/python2.7/site-packages:$PYTHONPATH.
I personally didn't need to use this last part but it might help you.
It appears you are mixing various install options here. The MacPorts package system port install command should automatically pull in all the dependencies needed for a particular package so the trick is to start with the right top-level project. For python packages, MacPorts has a general convention currently: packages that start with py- are for python 2.4, those with py25- are for 2.5, and py26- for 2.6. There are currently py-cairo, py25-cairo, and py26-cairo packages available in MacPorts.
By choosing py-cairo you picked the python2.4 version and you'll probably find that MacPorts built and installed a python2.4 for you (linked at /opt/local/bin/python2.4) and, if you launch it, you'll probably find that you can import cairo there. Now that may be OK for your needs but Python 2.4 is quite old and no longer supported so, if you're just starting, it might be better to start with Python 2.6, one of the two current versions of Python. To do so, all you should need to do is:
sudo port install py26-cairo
That should bring in any missing dependencies, mainly the MacPorts python2.6, which you can run from /opt/local/bin/python2.6. You may want to change your $PATH in your shell startup script, probably .bash_profile, to put /opt/local/bin early on the search path.
Because installing Cairo and its python bindings seems to be fairly complex, it should be easier and better to stick to using a complete MacPorts solution for this. That does mean you've needlessly (and harmlessly) installed a couple of Python instances that you won't need. But if you do want to clean things up a bit, you can easily remove the MacPorts python24 with:
sudo port uninstall py-cairo python24
Completely removing the python.org installed python is more complicated. I've explained the process here. But there's no pressing need to remove either as long as you keep your paths straight.
Ok. I solved it. Putting solution here for future reference, it might help someone.
Basically, the whole ports/fink system is a bit messed up, and osx doesn't really play nice with the linux-y world.
So, the steps I needed to install pycairo on OSX were:
download the latest source versions of pixman, cairo, pycairo
extract everything. Then:
cd PIXMAN_DIR ; ./configure ; make ; sudo make install
cd CAIRO_DIR ; cp PIXMAN_DIR/pixman/*.h . ; ./configure ; make ; sudo make install
cd PYCAYRO_DIR; locate cairo.pc
hopefully, several locations are returned. choose the most likely one (one with newest cairo). For me it was "/opt/local/lib/pkgconfig/cairo.pc" and do:
export PKG_CONFIG_PATH=/opt/local/lib/pkgconfig/
after this, still in PYCAIRO_DIR, do:
python setup.py install
This should do it...
The port command installs the library for the darwinports python installation, which is different to the framework build (so steps 2 and 3 shouldn't work). Try sudo easy_install pycairo instead (although your step 4 should be equivalent to this).
Look at which python too, to check that you are in fact running the python you think you are.
On Mac OS you can have multiple Python versions installed. You can have even more if you decide to install Python via Fink or MacPorts. When you compile libraries from the source, you should make sure they point to the correct installation.
I currently have Python 2.5.1 and Python 2.6.4 installed on my machine, which I can call via python2.5 and python respectively. They live in two different folders:
/System/Library/Frameworks/Python.framework/Versions/2.5and /Library/Frameworks/Python.framework/Versions/2.6
I was running into a similar problem when compiling pycairo 1.8.8 from the tarball. The INSTALL file in this case is your friend, as it contains the correct instructions to avoid potential version conflicts. You basically need to specify the correct prefix so that the package will be installed in the correct folder.
$ python -c "import sys; print sys.prefix"
# make a note of the python prefix
$ ./configure --prefix=[python_prefix]
$ make
$ make install # may require superuser access
Running these instructions with python2.5 and python you will be able to correctly install pycairo for both versions (or for any version installed via MacPorts / Fink).
Step 1: Run this from terminal ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)" < /dev/null 2> /dev/null
Step 2: brew install cairo
Step 3: pip install pycairo
Related
I need to work with Both Python 2.7.12 and python 3.5.2 simultaneously on my Ubuntu 16.04.1 LTS. Python 3 came pre-installed so I've no idea where it sits, in terms of path to the directory, while python 2 sits in /usr/local/lib/python2.7/.
I found lots of questions on SO and on askubuntu about how to install but nothing about how to use them separately, installing different libraries, and what should I avoid or be careful of, if I maintain this dual python thing for the long term? For example, I usually run pip install to install a library and I can check that its installed in my python2 directory but how do I install the same package for my python3 without conflicts? Something like: python3 pip install <package> ?? Where is the default python3 installed? And how do I call python3 for paths where python is not part of the command for example: pip freeze, sudo-apt get, etc.?
PS: I've not officially worked with Virtualenv but I've been informed that is usually good for isolating projects within a python language version, rather than isolating two different language versions from each other.
Please let me know.
Thanks
This is absolutely no problem, as Python does that for you. You don't need a virtualenv at all.
If you use Ubuntu packages, make sure you use the python3- versions for Python 3, and the normal python- versions for Python 2.
For example, python3-numpy and python-numpy.
If you use pip to install extra packages, you an either use the pip script with the version number appended: pip2.7 or pip3.5, or, my preferred method, call pip as a module for the respective Python executable:
python2.7 -m pip install <whatever>
and
python3.5 -m pip install <whatever>
Other than that, there should not be any issue: Python stores the packages in completely separate directories, and each Python executable only uses its respective directive.
Do not fiddle around with PYTHONPATH, unless you really know what you're doing. This has the danger of setting your PYTHONPATH to a directory with Python 2.7 modules and then using Python 3.5 to run things.
If you start from scratch, you may need to install pip first.
For the system Python(s), use the relevant package:
sudo apt install python-pip
sudo apt install python3-pip
For your locally installed Python(s), use the built-in bootstrapper module:
pythonx.y -m ensurepip
Note on the OS-installed Python executables:
Python 3.5 lives at /usr/bin/python3.5, Python 2.7 (the OS one) at /usr/bin/python2.7.
You could even use the OS 2.7 one next to your locally installed /usr/local/bin/python2.7 (and confuse yourself when a package can't be found because you used the wrong one).
Or install Python 3.6 next to Python 3.5 (provided you've used make altinstall, so python3 doesn't get overwritten).
This is also why you don't really want to run pip (or even pip2.7) as is: pip2.7 may get you the system one, instead of the one in /usr/local/bin/pip2.7, depending on your PATH.
(The same goes for the python2.7 executable, so if you need to specify the full path /usr/local/bin/python2.7 to run that one (or have an alias), the same holds for pip2.7. If, on the other hand, /usr/local/bin is first on your PATH, you should in principle never run into the same pip and python executables.)
I'm having trouble installing scipy via the binaries provided at http://sourceforge.net/projects/scipy/files/scipy/
Double clicking on the mpkg file after mounting the dmg installer gives the following error:
"scipy 0.13.0 can't be installed on this disk. scipy requires System Python 2.7 to install"
However, I already have python 2.7 and numpy installed. The python 2.7 came default with OSX Lion, so I assume it is System Python. With other python modules, one normally can download the binary then run
python setup.py install
Is there a way to cd through the mpkg file and locate a setup.py? Any advice install via this dmg installer?
I know there are other ways to manage python modules, like port and brew. However, I already installed a bunch of packages through setup.py, and I couldn't figure out how to get port to recognize those packages (for example, it will try to reinstall python and numpy via port)
Thanks!
If you have Mavericks and XCode 5, then you'll have to install Command Line Tools manually from the Apple Developer Site. I found this helpful post
You've got a few misconceptions here.
With other python modules, one normally can download the binary then run python setup.py install
No, that's what you do with source packages.
Is there a way to cd through the mpkg file and locate a setup.py?
No. What's inside an mpkg are pkg files. Which are filled with xar archives filled with cpio archives. Inside there is the built version of SciPy—that is, the files that setup.py would have copied to your site-packages if you'd run it—not the source package.
But you can download the source package yourself.
Or, better, let pip (or easy_install, but pip is better) download and run the setup.py for you.
Any advice install via this dmg installer?
If it won't work, my advice would be to not use it, and instead install with pip.
This blog post explains it, but I'll give you the details relevant to you below.
I know there are other ways to manage python modules, like port and brew. However, I already installed a bunch of packages through setup.py, and I couldn't figure out how to get port to recognize those packages.
You can't. MacPorts will not touch your system Python; it builds its own separate Python 2.7, with a completely independent site-packages directory and everything else. You would have to reinstall everything for this second Python 2.7. And deal with the confusion of having two Python 2.7 installations on the same machine.
Don't do that unless you absolutely have to.
In fact, if you want to use Homebrew for anything (and you do, see below), uninstall MacPorts, unless you really need it for something.
So, here are the steps:
Uninstall MacPorts.
I assume you already have Xcode and its Command Line Tools.
I assume you already have Homebrew.
Install a Fortran compiler with brew install gfortran.
Lion's Python 2.7 comes with easy_install, but not pip. So sudo easy_install pip to fix that. While you're at it, I'd suggest sudo easy_install readline, because you'll want that for ipython, and it won't work right with pip.
Apple's pre-installed NumPy has to be upgraded, and rebuilt with Fortran support, to make SciPy work. Fix that with sudo pip install --upgrade --force-reinstall numpy.
If you want ipython, pandas, etc. sudo pip install each of them as well.
In case you're considering upgrading soon, the exact same steps worked for me with OS X 10.9.0, except for some extra work to get the Xcode 5 command line tools set up.
I have a problem that comes from me following tutorials without really understanding what I'm doing. The root of the problem I think is the fact that I don't understand how the OS X filesystem works.
The problem is bigger than Python but it was when I started learning about Python that I realized how little I really understand. So in the beginning I started following tutorials which led me to use the easy_install command a lot and when a lot of tutorials recommended PIP I never got it running. So I have run a lot of commands and installed a lot of different packages.
As I have understood Lion comes with a python install. I have been using this a lot and from this I have installed various packages with easy_install. Is there any way to go back to default installation and begin from the very beginning? Is this something I want to do? If so why?
Is there any advantage of using a Python version I have installed with Homebrew? How can I see from where Python is run when I run the Python command?
When I do install something with either easy_install, homebrew, macports etc where do things actually end up?
Homebrew installs its software inside the /usr/local subdirectory on your Mac. OS X doesn't install anything there on its own; in fact, /usr/local is reserved for user-installed stuff. Since Homebrew never installs files outside /usr/local (and doesn't even have the ability to, unless you run brew using sudo - which is not recommended_) and OS X never installs files inside there, never the two shall mix.
easy_install and pip install files into system directories by default. That's why you have to run those commands with sudo to install packages with them.
I can't recommend virtualenv enough, regardless of which OS you're using. It installs a copy of Python, along with any packages or modules you want, inside a directory of your choosing. For example:
$ cd /tmp
$ virtualenv foo
New python executable in foo/bin/python
Installing setuptools............done.
Installing pip...............done.
$ cd foo
$ bin/pip install sqlalchemy
Downloading/unpacking sqlalchemy
Downloading SQLAlchemy-0.7.7.tar.gz (2.6Mb): 2.6Mb downloaded
Running setup.py egg_info for package sqlalchemy
[...]
Successfully installed sqlalchemy
Cleaning up...
[work, work, work]
[decide this was a bad idea]
$ cd /tmp; rm -rf foo
...and all traces of the project are now completely gone.
Use easy_install to install virtualenv into OS X itself - like you've done for those other packages - but then do all new development inside isolated directories that you can wipe clean at a moment's notice. This is pretty much the standard way of developing and deploying Python applications these days.
The advantage of using a Python installed via a package manager like Homebrew or MacPorts would be that this provides a simple way of removing the Python installation and reinstalling it. Also, you can install a more recent version than the one Mac OS X provides.
I want to create a native Mac OS X package installer, the creation of the package is not really the problem, the real deal is the dependencies that have to get installed; I need to install Python, NumPy and Matplotlib (only if the required versions are not already installed).
I have heard really bad things about the Package Maker app, I've been reading a little and have already even found a nice tutorial although it is quite outdated. As a reference, here's Apple's reference guide.
I imagine I would have to use the uncompiled source provided from each of these three projects.
It would really help me to see the PackageMaker file that is used to create the official Python installer, if such file is available somewhere, please point me to it.
Anyway:
What would be the best way to do this? Is using a PackageMaker silly for this purpose? Any other literature that would help me?
Extra:
What would be the easiest way to test my installers?
I'm assuming that you want to install the packages that you mentioned because you are developing a Python application. Have you looked at PyInstaller? It "converts (packages) Python programs into stand-alone executables, under Windows, Linux, Mac OS X, Solaris and AIX", so you don't have to worry about what's installed on the target system.
And if you use PyInstaller, the "extra" would be easy. Simply copy the resulting executable to any other machine and test it out by executing it.
Something like /tmp/install.sh:
cd ~
curl -C - -O http://pypi.python.org/packages/source/v/virtualenv/virtualenv-1.7.tar.gz
tar -xzf virtualenv-1.7.tar.gz
cd ./virtualenv-1.7
python setup.py install
cd ~
rm virtualenv-1.7.tar.gz
rm -rd ./virtualenv-1.7
virtualenv myenvfolder
source myenvfolder/bin/activate
easy_install pip
pip install NumPy
pip install Matplotlib
And then:
chmod +x /tmp/install.sh;
/tmp/install.sh
Maybe you can use macports binary-packages or binary-archives?
and maybe fabric or puppet.
Puppet on OSX.
Macports is as simple as apt-get to use and takes care of all dependencies. By default macports installs to /opt/local so installs don't interfere with apple installs. Default is to compile from source. Some packages are big and have a lot of dependencies so compiling takes a lot of time and all the recourse on the machine. If you make a binary-archive you only have to compile ones pr machine arcithecture/osx-version. Then you only need to install macports and sett up a share with binary-archives. With fabric or puppet you can automate builds and distribution.
Then if you in the near future find out that you need pytable or numexpr it is as simple as: sudo port install py26-tables
and if other people need it to you can make binary-archive of it and put it on the share.
To install Python's latest version you can go here, and you can install NumPy and matplotlib directly in your terminal with these commands:
pip3 install matplotlib
pip3 install numpy
In ubuntu 9.10, in usr/lib/ there are the directories python2.4, python2.5, python2.6 and python3.0
Only python 2.6 is actually working.
python2.4 has only a lib-dynload directory,
python2.5 has only lib-dynload and site-packages,
python3.0 has only a dist-packages directory.
Now i'm wondering what is the idea behind this?
Because when i install python2.5 with ./configure, make, make install | altinstall
this goes into usr/local/lib and not usr/lib/ so why were these directories added tu ubuntu, how am i supposed to install python to use them?
j3ll3, in Ubuntu (or any DPKG-based Linux OS) you can ask the question "What package provides XYZ" by typing
dpkg -S /path/to/XYZ
So, for example, in Ubuntu 9.10,
dpkg -S /usr/lib/python2.5/lib-dynload/gdbm.so
returns
python-gdbm: /usr/lib/python2.5/lib-dynload/gdbm.so
You can find out more about the python-gdbm package by typing
apt-cache show python-gdbm
which says that python-gdbm provides "GNU dbm database support for Python".
Perhaps more interestingly, if you type
dpkg --listfiles python-gdbm
you get to see a listing of all the files that python-gdbm installs:
...
/usr/lib/python2.4
/usr/lib/python2.4/lib-dynload
/usr/lib/python2.4/lib-dynload/gdbm.so
/usr/lib/python2.5
/usr/lib/python2.5/lib-dynload
/usr/lib/python2.5/lib-dynload/gdbm.so
/usr/lib/python2.6
/usr/lib/python2.6/lib-dynload
/usr/lib/python2.6/lib-dynload/gdbm.so
...
So it looks like this single package installs 3 .so libraries, one for each version of python.
Python2.6 is the default version of python in Ubuntu 9.10, but it is also possible to install
python2.4, 2.5 and/or 3.0. Unless you do so, only /usr/lib/python2.6/lib-dynload/gdbm.so is used, the others are just wasting space.
Since the unneeded files in python2.4, 2.5, 3.0 are not very large, the package maintainer probably felt it was easier to ship one package rather than one for each version of python.
However, unless you know how to fix future apt-get errors, I'd recommend not manually deleting any files that were installed by packages in Ubuntu.
Sounds like they're an accident from some package(s) you have installed.
The Python version in use determines the locations searched to find installed Python packages/modules, and the "system version" of Python in Ubuntu 9.10 is 2.6, so that's what practically everything should be using. If you were to install the python2.5 package (or it gets installed as a dependency of something else), then it would use /usr/lib/python2.5/*. Try running which python and python --version; also which python2.6 and which python2.5.
From what I understand, though I'm not sure exactly why at all, Debian (from which Ubuntu is derived) uses a dist-packages naming scheme instead of site-packages.
Terminology: Python has packages and Debian (and so Ubuntu) has packages. They aren't the same kind of package, though individual Debian packages will install specific Python packages.
The short answer to your question: when you install packages from source, you should use the packages' setup.py installer to install them automatically and correctly. This installer already knows where to properly install the modules so Python can find them. To use, simply call with the exact Python interpreter you want to use the package with.
A crash course in setup.py. First, run it with the exact Python executable that you want the package to be available to. If you want to use the package with /usr/bin/python2.5, you should use /usr/bin/python2.5 to run setup.py. Second, go to the directory where that package's setup.py is installed. Third, you must install as root, so it's easiest to do the whole tihng as root. Fourth, if you want to install to multiple Python interpreters, you should run setup.py with each, but you should clean it in between. So here's what I would do:
% cd /root/directory/of/untarred/source/package
% sudo su
# /path/to/first/python setup.py build install
# rm -rf build
# /path/to/second/python setup.py build install
# rm -rf build
# exit
%
If you're installing modules by hand... you shouldn't, you should use its setup.py. (If you wrote a new module, you should write a setup.py for it.) If you must install by hand, you'll need to figure out which is the proper directory to install into for each Python, either by exploration and experimentation, or by calling into the same libraries that the installer calls to determine the proper directory. Installers using distutils call distutils.sysconfig.get_python_lib(); installers using setup_tools look in setup_tools.command.easy_install.easy_install.INSTALL_SCHEMES[os.name]["install_dir"].
Regarding dist-packages: I had a conversation with the maintainer of the Python package for Debian earlier this year. He'd implemented this dist-packages in the beta packages picked up by Ubuntu 9.04, but the code had a bug wrt PYTHONUSERBASE which I tripped over. We wound up talking a little. IIRC the reason for dist-packages had something to do with forcing the user to install packages in a different directory from apt-get. I clearly don't really understand the motivation, though, because in practice both the user and apt-get still install into the same directory.
lib-dynload isn't a Debian thing; that's a directory Python itself installs. I believe it was a directory just for shared libraries implementing modules. I'm not sure Python still uses it.
Finally, I don't know what you mean by "only python2.6 is actually working". What about these differently-named directories is "not working"?
I'm not sure what you mean by "Only python 2.6 is actually working." Suppose you run the "terminal emulator" and get a command-line prompt. Is this what you mean:
% python -V
Python 2.6
In other words, when you run Python, you get version 2.6? Well, have you tried this:
% python2.4
If Python 2.4 is correctly installed on your system, it will run. Likewise python2.5 will run Python 2.5.
If these don't run, and that is what you meant by "Only python 2.6 is actually working.", then one thing to try is to make sure that you actually have Ubuntu packages installed for Python 2.4 and Python 2.5.
% sudo apt-get install python2.4 python2.5
If you didn't have them installed before, this should add them. My thought is that you might have various libraries to support the older versions of Python, but you just don't have the actual Ubuntu packages for those older versions.