I've just installed pygtk through Homebrew(awesome tool) as well as its dependences (including gtk+); the thing is when I try to import gtk on the python interpreter it throws an ImportError, which don't happens when importing pygtk or any other module into the interpreter, I can't figure out what's wrong. :S
-
Are you sure you installed `pygtk` into the same Python you're running? – abarnert Mar 15 '13 at 00:48
-
Also, notice that the Brew package clearly says (when you `info` it, `install` it, etc.) "For non-Homebrew Python, you need to amend your PYTHONPATH like so: …". Unless you're using Homebrew Python, did you do that? – abarnert Mar 15 '13 at 00:49
1 Answers
After clarification from the OP, the original answer does not describe his problem… although I think it's related, and it may help other people, so I will leave it. But first, the relevant part.
Before you can import gtk
, you need to call pygtk.require
, as shown in the Getting Started section of the tutorial. (For more details, see the PyGTK FAQ.)
That should solve your problem… but you're just crashing with Fatal Python error: PyThreadState_Get: no current thread
. There are a number of reasons you can get this, but the most likely in this case is that you're running a C extension (pygtk
/gtk
/whatever) built for one version of Python against a different version of Python. (This is actually covered in the PyGTK FAQ as well, but in this case it's a more general issue with CPython C extension modules, not something PyGTK specific.)
If you have multiple Python 2.7 versions (and if you have 2.7.3, you very definitely have two, because Apple's is 2.7.2), you have to figure out which ones you have, and which one you used to build pygtk
, and make sure you use it from the same one.
And that takes us back to the original answer, which I've left below.
There are two reasons you can have this problem.
First, if you haven't installed any extra Python versions besides the ones that came with OS X, you may not have read the instructions that brew
prints out about pygtk
whenever you install it, or info it, etc.:
For example:
$ brew info pygtk
pygtk: stable 2.24.0
...
==> Caveats
For non-Homebrew Python, you need to amend your PYTHONPATH like so:
export PYTHONPATH=/usr/local/lib/python2.7/site-packages:$PYTHONPATH
Homebrew installs Python packages into /usr/local/lib/pythonX.Y—even if it's installing for Apple's Python installation. But Apple's Python installation doesn't look for packages there by default. So, you need to do what this says.
Just typing this line at the Terminal will work for the rest of that terminal session. If you want to make it permanent… well, there are many options, depending on exactly what you want. See this answer for details.
This is explained in more detail at Gems, Eggs and Perl Modules and Homebrew and Python.
(This is one of the multiple reasons why Homebrew usually recommends using pip
whenever possible, rather than looking for packages in brew
. But there are a few exceptions, and I could easily believe pygtk is one of them.)
Second, if you installed Homebrew's Python, you probably don't have your PATH set up right, so you're installing packages into the Homebrew Python's site packages, but then running the Apple Python installation instead.
If you're just typing python
and don't know which one you're running, which python
should tell you. If it's /usr/bin/python
it's Apple's; if it's /usr/local/bin/python
, that's Homebrew's.
You can also tell from the Python startup banner, because Mountain Lion comes with 2.7.2, while Homebrew will install 2.7.3. (Also, IIRC, Apple used a prerelease clang to build their Python, while anything you build with Homebrew will be built with whatever clang/gcc/llvm-gcc you have, which is not going to be a prerelease build…)
NOTE: Just because you see the word "Apple" somewhere in the banner doesn't mean it's Apple's Python! If you build a Homebrew Python, or install a python.org Python, it will almost certainly be built with Apple GCC, Apple Clang, or Apple LLVM-GCC. And it's running on an Apple OS, too. So, "Apple" or "apple" will appear up to three times in the banner for any Python, Apple or not.
The fix for this is to run the Python you want to run. For example:
- Use
virtualenv
to create one or more virtual environments based on either or both installations, and pick and choose using the venv tools. - Always use full paths—e.g., type
/usr/local/bin/python
to run Homebrew's Python,/usr/bin/python
to run Apple's. (And modify the shebang lines in any of your scripts to do the same.) - Change your
PATH
variable to make sure whichever one you want first comes first. For Homebrew, you want either /usr/local/Cellar/python/2.7.3/bin (for just Python) or /usr/local/bin (for everything) before /usr/bin; for Apple, the other way around. - Add the Python framework bin directory(ies) to the PATH, so you can manipulate their order separately from general binaries. (This one isn't really relevant with Homebrew Python, because the Cellar directory serves the same purpose. But it can be useful with other third-party Python installations.)
All of this applies to other tools. Many people get into trouble by having, e.g., one installation's pip
or idle
come first in the path, while a different installation's python
does…
If you've installed a different Python, e.g., by using the installers from python.org, you could easily have both of the above problems. For example, you could be installing stuff for python.org Python, but running Apple Python, and on top of that, neither one may be configured to look in the Homebrew site-packages directory.
-
Thanks for your answer; I was about to reply your comments, I've added the `export PYTHONPATH=/usr/local/lib/python2.7/site-packages:$PYTHONPATH` line at the .profile file so I think is not a path problem (otherwise it won't import pygtk at the interpreter). – Alfageme Mar 15 '13 at 01:16
-
Ops, I accidentally hit enter; I was going to say that I'm running Apple Build; but the version is 2.7.3 (As it appears in the banner) It could be the problem?. I've seen in several places that is needed to write before the `import gtk` the line `pygtk.require("2.0")` and then importing the gtk; that way the interpreter trows me this error: `Fatal Python error: PyThreadState_Get: no current thread` any ideas? – Alfageme Mar 15 '13 at 01:22
-
First, if you're running 2.7.3, you're _not_ running Apple's build. Apple does not distribute a 2.7.3. (Of course you are running a Python built with an Apple-built gcc/llvm-gcc/clang, and on an Apple-built OS, so you will still see their name once or twice in the banner. But that's why I gave very specific instructions on how to tell which one you're running. If you don't know which Python you're running, the first step is to find that out. – abarnert Mar 15 '13 at 01:29
-
Thanks again; I've just ran Apple's Python and the library is importing with no problem, the moment I press enter after importing it launches XQuartz which I think is the cause of the Fatal error on the homebrew version (probably gtk doesn't find the path for X11 or something). – Alfageme Mar 15 '13 at 01:54
-
Out of curiosity, why are you trying to install X11-based Gtk+, and PyGTK instead of PyGObject, and so on in 2013? – abarnert Mar 15 '13 at 01:58
-
Anyway, it's not that gtk doesn't find the path for X11. First, that wouldn't cause the fatal error you see… More importantly, Gtk+ doesn't actually launch XQuartz; it just talks to the X server. Mountain Lion comes with a "fake X" server which, the first time someone tries to talk to it, either finds and launches XQuartz (if present) or pops up a dialog telling the user how to install it (if not). – abarnert Mar 15 '13 at 02:01
-
More likely the reason it crashes at that point is that point is the first time it tries to do something (release the Python GIL, or access the Python C API at all, or…) from C that makes its incorrect build actually matter. – abarnert Mar 15 '13 at 02:03
-
Using Gtk+ is a restriction for a particular college assignment, we've to use gtk in order to open and modify some images and then save them, also, I'm a "newbie" with python so don't know too much about it yet D: – Alfageme Mar 15 '13 at 02:36
-
@Samué: The point isn't that you shouldn't use Gtk+, but that almost any project on Mac should be using the [native-Quartz (Aqua) Gtk+](http://www.gtk.org/download/macos.php) Gtk+ port instead of the older X11-based one. (Less importantly, if you can use Gtk+ 3.0 or later, the [PyGObject](https://live.gnome.org/PyGObject) bindings are much nicer and simpler than the old PyGTK ones—but if you're following a classroom assignment that's Gtk+ 2.x-based, that probably isn't an option—the question is to your teacher, then, instead of to you.) – abarnert Mar 15 '13 at 18:34