I am trying to install py2cairo on a framework build (Mac OSX Lion) of python 2.7.3 using brew. I have been unsuccessful this far.
First, I tried a simple
brew install py2cairo
This seems to work only on a non-framework build of python. When I do this on my framework build python faults as soon as I import cairo with an incompatible binary error.
Second, I have tried to build it myself by grabbing it from github and issuing:
python waf configure
This fails with:
Checking for library python2.7 : not found
Checking for library python2.7 : not found
Checking for library python2.7 : not found
Checking for library python27 : not found
Checking for program python2.7-config : /usr/local/Cellar/python/2.7.3/bin/python2.7- config
Checking for header Python.h : Could not find the python development headers
The configuration failed
(complete log in /Users/tobin/tmp/py2cairo/build_directory/config.log)
I have tried everything at: How to install PyCairo 1.10 on Mac OSX with default python but none of this has helped.
It appears to me that this may be failing to find python2.7 library and header file since it is a framework build. Is that possible? I was looking at the brew formula and it appears that framework builds do not get --enable-share set at build time. I'm not sure if that is relevant here - but maybe one possibility.
Anyone other insights would be great. Thanks in advance.
UPDATE:
I discovered that the inability to build py2cairo had to do with the use of the "-march=native" flag by gcc. gcc (4.2.1) on Mac OSX has issues with this. I then reinstalled gcc as well as python. Afterwards when building py2cairo with waf - it was getting "-march=core2" and everything built.
Unfortunately, not all is good yet. I get the same error when I import cairo from my build that I got from the brew version (as mentioned above). The exact error message is:
>>> import cairo
Fatal Python error: Interpreter not initialized (version mismatch?)
Abort trap: 6
and then python exits.
It would now seem that the issue is related to the framework build of python. I tested it without a framework build and it worked fine.
So as to not leave this question dangling ... I wanted to follow up with my resolution and learning points:
As noted above there was an incompatibility with my version of OSX and a gcc compile flag called -march=native. In a later version it was coming up as -march=core2. This pretty much fixed itself with compiler/version changes after cleaning up my machine.
For years I have had quite a mess with all of my various MAC OSX installs - and accepting the "migration option". Two machines ago - I installed the python binaries for versions 2.4, and 2.5, Then eventually went to macports for various reasons. Then eventually went to homebrew. When I went to homebrew I tried to clean things up by hand (but of course this can be challenging). To make matters worse - everytime I have gotten a new mac (2 times) in the last 6 years I take "the migration install" option and this pushes the mess forward and makes it worse. So as I started looking into things further - I had various installs of python, with different versions - mac-native, python-native, mac ports, homebrew, and probably even others too on my system. So my best guess is that cairo was somehow finding one of these and trying to build against it.
I finally solved this by deleting a bunch of old python installs by hand and then starting over with a fresh virtualenv and homebrew install of python 2.7.
WARNING: I don't think that this is the smartest way to go. I was careful not to delete a version of Python that I thought came native with OSX Lion (I think it is 2.6) - but it is not clear how it may potentially effect some other things that may have depended on older mac installs of python. I ended up deleting a 2.3, a 2.4, and two different 2.5s - along with various links in some places. WHAT A MESS! Unless you are absolutely sure of what it is you are doing (which I was not) I would not suggest this approach. I was basically trying to kill 6 years of python install crud that has collected.
To be safe I probably should have started with a fresh OSX Lion install and then added my homebrew version and went from there. I will likely do this in the near future.
Related
Over the last few days of headaches, I've found 3 possible methods to do this, all of which have issues.
PyGObject's pip install fails due to a lack of Cairo and probably other dependencies. While this would be my preferred method, it would probably be the hardest to fulfill.
Using MSYS2 allows me to use GObject through the mingw64 python, but using pip to get my other modulues such as pylint fails. I'd like to have an MSYS2 or similar install on my system anyways to make some windows binaries, so I'm very open to this as well.
EDIT: Got pip to work in MSYS2. Make sure to sync toolchain with pacman.
PyGObject for Windows seems messy at best and isn't up-to-date. Would require having a second python installation anyways, giving no benefit over MSYS2.
Note I'm a complete newbie to Unix and have little experience with CLI's in general, so any help regarding MSYS2 will need to be explained as if to a child. My only other experience with this stuff involved an endless cycle of hell that was installing Arch to a separate partition, breaking said install, then reinstalling again.
I also tried Cygwin, but I couldn't get that to run Python with GObject at all with my "install all the needed packages then pray" method. Creating a Gtk.Window() caused the terminal to use none of the memory it had and explode.
MSYS2 is currently the only "officially" supported way: https://pygobject.readthedocs.io/en/latest/getting_started.html#windows
pip in MSYS2 should work in general, if something doesn't please file a bug at https://github.com/Alexpux/MINGW-packages/issues .
As you said in the third alternative to install a new Python version, you can create and run multiple Python versions using pyenv. You can go through the installation section of their Github repo for installation and an overview: https://github.com/pyenv/pyenv/
For a comprehensive guide on how to use it, you read this amazing post by Real Python:
https://realpython.com/intro-to-pyenv/
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
How to use/install gcc on Mac OS X 10.8 / Xcode 4.4
I cannot install any Python packages using easy_insall or pip, because of the following error. I've looked everywhere, and seen several variations of this error, but have not found a solution that is easy to understand/follow. Any help is much appreciated!
I'm running on Mac OS 10.8.1
Python version 2.7.3
Xcode version 4.5.2 (with Command Line Tools installed)
...if you need any more information in order to figure out the problem, please ask!
$ easy_install pil
Searching for pil
Reading http://pypi.python.org/simple/pil/
Reading http://www.pythonware.com/products/pil
Reading http://effbot.org/zone/pil-changes-115.htm
Reading http://effbot.org/downloads/#Imaging
Best match: PIL 1.1.7
Downloading http://effbot.org/media/downloads/PIL-1.1.7.tar.gz
Processing PIL-1.1.7.tar.gz
Writing /var/folders/9q/bvqtzkbx1hg1934b36zgk0y40000gn/T/easy_install-wfZs_Y/PIL-1.1.7/setup.cfg
Running PIL-1.1.7/setup.py -q bdist_egg --dist-dir /var/folders/9q/bvqtzkbx1hg1934b36zgk0y40000gn/T/easy_install-wfZs_Y/PIL-1.1.7/egg-dist-tmp-DXWOmC
WARNING: '' not a valid package name; please use only.-separated package names in setup.py
--- using frameworks at /System/Library/Frameworks
unable to execute gcc-4.0: No such file or directory
error: Setup script exited with error: command 'gcc-4.0' failed with exit status 1
Not sure if this helps, but when I run sudo port select --list gcc, I get the following:
Available versions for gcc:
llvm-gcc42
mp-gcc45
none (active)
This is just a guess, based on the fact that you must have MacPorts installed (or sudo port select --list gcc would just give you a port: command not found error), but I suspect you've installed a MacPorts Python 2.7.3, and you're trying to install PIL for that.
If you want to add packages to a MacPorts Python installation, you should always first check to see if there's a port for it, and, if so, use it:
port search pil
In this case, you'll find there is a py27-pil. Install that.
Meanwhile, when this doesn't apply, you should almost always use pip instead of easy_install (there are a few exceptions, notably readline), and you need to make sure your path is set up properly so you're running the one you think you are, or you may end up running scripts set up for MacPorts python with Apple python.
However, I also suspect you have an out-of-date MacPorts installation that you installed for an earlier version of OS X, and didn't follow the upgrade instructions when upgrading to Mountain Lion. If this is true, the only decent fix is to get a list of installed ports, sudo rm -rf /opt/local, run the latest MacPorts installer, then sudo port install all of the previously-installed ports.
On top of that, last time I used MacPorts Python (which is quite a long time ago, so it may not be current information), it didn't install things into /Library (IIRC, it set up /opt/local/Library as an extra library directory instead), which implies that you actually have at least three Python 2.7 installations: Apple's (in /System/Library and /usr), MacPorts (in /opt/local), and some other version (in /Library and probably /usr/local), and you're using the second one's easy_install when you meant to use the third.
If you don't know how to deal with this kind of multiple-copies-of-the-same-thing insanity, and you don't have a very, very good reason to invite it, the right answer is to not install these other Pythons (and uninstall any you already have). Do you actually need MacPorts python at all? Can you just use the built-in Python? If not, why not? And can you at least use the python.org Python?
If you don't want to fix any of the base problems, and you really want to install things into a MacPorts Python that expects you to have gcc-4.0 around, you might be able to install the macports gcc4.0 port, although you may have to trick things into believing that macports-gcc-4.0 is really gcc-4.0. (There might be a way to do that properly with MacPorts; if not, a symlink might work.) But this is probably a bad idea, and I wouldn't be surprised if you came back with "That seemed to work but then I got this other error 348 minutes into rebuilding stuff", and nobody would be able to help you.
I'm currently running Matplotlib 0.99.1.1 on Ubuntu 10.04 LTS (Lucid Lynx).
I would like to upgrade Matplotlib to version 1.1.0. I have tried following the
instructions at SourceForge, which didn't seem to do anything (IPython still thinks I have version 0.99.1.1).
I have tried searching for how to do this another way but, being relatively new to Linux, am a little confused what I need to do now. I have tried a few suggestions on the forums but still I cannot seem to install Matplotlib-1.1.0
This thread for example doesn't seem to work for me (pip complains of an "Unknown or unsupported command 'install'").
Any help is much appreciated!
Unless my memory fails me completely, I followed the build from source instructions you link to on two Lucid systems of mine. These instructions, to be precise:
http://matplotlib.sourceforge.net/users/installing.html#installing-from-source
Worked like a charm, after I remembered to do python setup.py install. And, yes,prior to the install, I removed the 0.99 matplotlib via synaptic. Did you try removing the older version first?
https://launchpad.net/ubuntu/oneiric/+source/matplotlib
There is a section for binary builds, just grab the appropriate package for your system architecture and dpkg -i the_package_name.deb
I'm not sure what went wrong with my system, but the issue resolved itself. Either one of the procedures I followed while searching for an answer worked, or the build from source instruction worked.
Perhaps my computer just took a while to realise I did in fact have the newest version installed.
For future reference, I would follow the install from source instructions on the matplotlib site at SourceForge, noting the answer by Zhenya.
I was trying to setup Django dev environment on Mac and arrived into a hell. It all started when trying to install PIL, which failed after trying 15 or so different recipes I found on blogs. So I wanted to install the Python, this time 2.7, and reinstall setuptools, easy_install, pip from scratch.
After just installing Python 2.7, and easy_install with setuptools for 2.7, this all in turn created such a mess that is unbelievable. Different version of Python are installed everywhere, easy_install is installed everywhere and points randomly to different python hashbangs (sometimes to #!/usr/bin, #!/usr/local/, #!/Library/...)
Now I can't even do easy_install pip, which I always could. So I'm already in a hell and I haven't even attempted to install MySQL yet.
My question finally is did anyone bump into such problems, it would help enough to know that I'm not alone.
Second, would it be easier to set up the entire environment on Ubuntu than it is on a Mac?
Thirdly, is there any guide that can really clearly explain how to set up but also tear down the stack for Python development on a Mac?
It wouldn't hurt to run a VM with vagrant. This post should tell you more:
http://stevelosh.com/blog/2011/06/django-advice/
Of course using virtualenv should also help alleviate some of these issues.
I've gone through the same hell 2 weeks ago :)
I needed to make working python 2.7 and virtualenv on OSX 10.6.8.
You haven't mentioned virtualenv in your question but I strongly recommend it. That way you minimize amount of globally installed packages. Everything is... cleaner.
My idea is to only have following things globally:
python (from brew)
pip (via easy_install)
virtualenv (via pip)
virtualenvwrapper (via pip)
other through either virtualenv or buildout
I've just checked and pip PIL installs fine within my virtualenv.
Here are notes from this battle (gist.github.com):
#NOTE: .pydistutils.cfg seems to be not compatible with brew install python
#areas I needed to clean before installation
#clean up ~/Library/Python
#clean up .local
brew install python
easy_install pip
pip install virtualenv
pip install virtualenvwrapper
mkdir $HOME/.virtualenvs
Example .bash_profile:
#homebrew
export PATH=/usr/local/bin:/usr/local/sbin:${PATH}
# homebrew python 2.7
export PATH="/usr/local/share/python:${PATH}"
#virtualenv wrapper
export WORKON_HOME=$HOME/.virtualenvs
source /usr/local/share/python/virtualenvwrapper.sh
Good luck!
Second, would it be easier to set up
the entire environment on Ubuntu than
it is on a Mac?
To answer this question (though I never used Mac though): I never had problems setting up a python environment for Django development on Ubuntu. Though in any case you should go with the built-in Python version if possible. Attempting to install any other Python versions usually ends up messy. Luckily with Ubuntu 11.04 the standard version is already 2.7.
I'm using django development environment on a MAC OS X 10.8 with python 2.7. I don't use virtualenv ore some other things.
With all the respect can say that there is NO ANY PROBLEMS to develop on a mac. Mac is a UNIX like system and you've probably seen that all tools for developers have MAC ports.
As for the setup mess. It's a good idea to use virtualenv. As for PIL installation. I needed to compile it with TrueType. As I'm in common with UNIX like environments it was not heavy task for me to compile PIL from sources using GCC (it's already installed on a MAC)... There are some mess with Django to setup virtualenv... There are certainly lots of articles to setup it on Google.
I use Eclipse and write all my PYTHONPATH variables there. You can forget installing everything like in Linux and try not to make anymore mess with installed tools. Try to read THIS article if you feel like you're ok to use Eclipse for your development on a MAC. It also has a recipe to avoid mess with installation of many copies of Python and other dev utils.
Yes I have had problems with MacOS. I think rather than trying to figure it out I just switched to Ubuntu. I use a mac with Ubuntu installed in VMware Fusion. I have developed on both and prefer the Ubuntu because I'm just more comfortable with installing packages and the file structure.
I love using the VM because I'm never scared of having to start over. I can get a whole new OS installed and get the packages with what I use in just a few hours. Not to mention with 6month rollouts I can do complete installs of new versions instead of updates.
Depending on your production environment, it may be beneficial to use an OS that is similar, if you can install a package on ubuntu desktop, you already know how to do it on ubuntu server.
Fedora Core 9 includes Python 2.5.1. I can use YUM to get latest and greatest releases.
To get ready for 2.6 official testing, I wanted to start with 2.5.4. It appears that there's no Fedora 9 YUM package, because 2.5.4 isn't an official part of FC9.
I downloaded 2.5.4, did ./configure; make; make install and wound up with two Pythons. The official 2.5.1 (in /usr/bin) and the new 2.5.4. (in /usr/local/bin).
None of my technology stack is installed in /usr/local/lib/python2.5.
It appears that I have several choices for going forward. Anyone have any preferences?
Copy /usr/lib/python2.5/* to /usr/local/lib/python2.5 to replicate my environment. This should work, unless some part of the Python libraries have /usr/bin/python wired in during installation. This is sure simple, but is there a down side?
Reinstall everything by running easy_install. Except, easy_install is (currently) hard-wired to /usr/bin/python. So, I'd have to fix easy_install first, then reinstall everything.
This takes some time, but it gives me a clean, new latest-and-greatest environment. But is there a down-side? [And why does easy_install hard-wire itself?]
Relink /usr/bin/python to be /usr/local/bin/python. I'd still have to copy or reinstall the library, so I don't think this does me any good. [It would make easy_install work; but so would editing /usr/bin/easy_install.]
Has anyone copied their library? Is it that simple?
Or should I fix easy_install and simply step through the installation guide and build a new, clean, latest-and-greatest?
Edit
Or, should I
Skip trying to resolve the 2.5.1 and 2.5.4 issues and just jump straight to 2.6?
Normally, you would only have one version of a python release installed. Since 2.5.1 and 2.5.4 are from the same release, copying your libraries should work fine. What you would need to watch out for, is that you now have /usr/bin/python, and /usr/local/bin/python in your path, and some utilities may get confused.
If you need to have both micro-releases installed at once, I would keep 2.5.4 out of your path altogether, or allow it to completely clobber the other (do so at your own risk though ;)
If you go with the former, you can also point 2.5.4 to your site-packages by using the PYTHONPATH environment variable.
Ubuntu takes a different route, and this is how you can handle different major releases. The python binary is given with the version appended:
/usr/bin/python -> python2.6
/usr/bin/python2.5
/usr/bin/python2.6
Each has their own /usr/lib/python2.X directory with versions of all the modules.
And lastly, you can further customize your setup by modifying your site.py
I suggest you create a virtualenv (or several) for installing packages into.
I've had similar experiences and issues when installing Python 2.5 on an older release of ubuntu that supplied 2.4 out of the box.
I first tried to patch easy_install, but this led to problems with anything that wanted to use the os-supplied version of python. I was often fiddling with the tool chain to fix different errors that might crop up with every install. Installing any python software via apt, or installing any software from apt that had a python easy_install script as part of the install, was often amusing. I'm sure I could probably have been more vigilant in patching easy_install, but I gave up.
Instead, I copied the library, and everything worked. As you say, there may be issues depending on what you have installed, but I didn't run into issues. Double-checking Python's site.py module, I did see that it operates entirely on relative paths, building absolute paths dynamically; this gave me some confidence to try the "copy everything" approach. I double-checked any .pth files, then went for it.