Problem description:
Using pip, I upgraded to the latest version of requests (version 2.7.0, with pip show requests giving the location /usr/local/lib/python2.7/dist-packages). When I import requests and print requests.__version__ in the interactive command line, though, I am seeing version 2.2.1. It turns out that Python is using the pre-installed Ubuntu version of requests (requests.__file__ is /usr/lib/python2.7/dist-packages/requests/__init__.pyc -- not /user/local/lib/...).
From my investigation, this fact is caused by Ubuntu's changes to the Python search path (I run Ubuntu 14.04) by prepending the path to Ubuntu's Python package (for my machine, this happens in usr/local/lib/python2.7/dist-packages/easy-install.pth). In my case, this causes the apt-get version of requests, which is pre-packaged with Ubuntu, to be used, rather than the pip version I want to use.
What I'm looking for:
I want to globally prepend pip's installation directory path to Python's search path (sys.path), before the path to Ubuntu's Python installation directory. Since requests (and many other packages) are used in many Python scripts of mine, I don't want to manually change the search path for every single file on my machine.
Unsatisfactory Solution 1: Using virtualenv
Using virtualenv would cause an unnecessary amount of change to my machine, since I would have to reinstall every package that exists globally. I only want to upgrade from Ubuntu's packages to pip's packages.
Unsatisfactory Solution 2: Changing easy-install.pth
Since easy-install.pth is overwritten every time easy-install is used, my changes to easy-install.pth would be removed if a new package is installed. This problem makes it difficult to maintain the packages on my machine.
Unsatisfactory (but best one I have so far) Solution 3: Adding a separate .pth file
In the same directory as easy-install.pth I added a zzz.pth with contents:
import sys; sys.__plen = len(sys.path)
/usr/lib/python2.7/dist-packages/test_dir
import sys; new=sys.path[sys.__plen:]; del sys.path[sys.__plen:]; p=getattr(sys,'__egginsert',0); sys.path[p:p]=new; sys.__egginsert = p+len(new)
This file is read by site.py when Python is starting. Since its file name comes after easy-install.pth alphanumerically, it is consumed by site.py afterwards. Taken together, the first and last lines of the file prepend the path to sys.path (these lines were taken from easy-install.pth).
I don't like how this solution depends on the alphanumeric ordering of the file name to correctly place the new path.
PYTHONPATHs come after Ubuntu's paths
Another answer on Stack Overflow didn't work for me. My PYTHONPATH paths come after the paths in easy-install.pth, which uses the same code I mention in "Unsatisfactory solution 3" to prepend its paths.
Thank you in advance!
This is not recommended, as it hard-codes a path and makes it difficult to run the script elsewhere, but you can do
>>> import sys
>>> sys.path.insert(0,'/home/anand/')
>>> print(sys.path)
['/home/anand/', '', '/usr/local/lib/python2.7/dist-packages/_pdbpp_path_hack', '/usr/local/lib/python2.7/dist-packages/goose-0.0.1-py2.7.egg', '/usr/local/lib/python2.7/dist-packages/jieba-0.33-py2.7.egg', '/usr/local/lib/python2.7/dist-packages/cssselect-0.9.1-py2.7.egg', '/usr/local/lib/python2.7/dist-packages/nanoservice-0.1.5-py2.7.egg', '/usr/local/lib/python2.7/dist-packages/nanomsg-1.0a2-py2.7-linux-x86_64.egg', '/usr/local/lib/python2.7/dist-packages/msgpack_python-0.4.2-py2.7-linux-x86_64.egg', '/usr/local/lib/python2.7/dist-packages/DecisionTree-2.2.5-py2.7.egg', '/usr/local/lib/python2.7/dist-packages/nudepy-0.2-py2.7.egg', '/usr/local/lib/python2.7/dist-packages/wsgilog-0.3-py2.7.egg', '/usr/local/lib/python2.7/dist-packages/distribute-0.7.3-py2.7.egg', '/usr/local/lib/python2.7/dist-packages/PIL-1.1.7-py2.7-linux-x86_64.egg', '/usr/local/lib/python2.7/dist-packages/MySQL_python-1.2.5-py2.7-linux-x86_64.egg', '/usr/local/lib/python2.7/dist-packages/munkres-1.0.7-py2.7.egg', '/usr/local/lib/python2.7/dist-packages/parsedatetime-1.4-py2.7.egg', '/usr/local/lib/python2.7/dist-packages/argparse-1.3.0-py2.7.egg', '/usr/local/lib/python2.7/dist-packages/tusker-0.1-py2.7.egg', '/usr/local/lib/python2.7/dist-packages/SQLAlchemy-1.0.3-py2.7-linux-x86_64.egg', '/usr/local/lib/python2.7/dist-packages/numpy-1.9.2-py2.7-linux-x86_64.egg', '/usr/local/lib/python2.7/dist-packages/turkic-0.2.5-py2.7.egg', '/usr/local/lib/python2.7/dist-packages/scikits.bootstrap-0.3.2-py2.7.egg', '/usr/local/lib/python2.7/dist-packages/pyvision-0.1-py2.7-linux-x86_64.egg', '/home/anand/playspace/languages/python_pkgs/ets', '/usr/local/lib/python2.7/dist-packages/Scrapy-1.1.0dev1-py2.7.egg', '/usr/lib/python2.7/dist-packages', '/home/anand/playspace', '/home/anand/workspace/pyvision/src', '/home/anand/playspace/yapf', '/usr/lib/python2.7', '/usr/lib/python2.7/plat-x86_64-linux-gnu', '/usr/lib/python2.7/lib-tk', '/usr/lib/python2.7/lib-old', '/usr/lib/python2.7/lib-dynload', '/usr/local/lib/python2.7/dist-packages', '/usr/local/lib/python2.7/dist-packages/Orange/orng', '/usr/local/lib/python2.7/dist-packages/PIL', '/usr/lib/python2.7/dist-packages/PILcompat', '/usr/lib/python2.7/dist-packages/gst-0.10', '/usr/lib/python2.7/dist-packages/gtk-2.0', '/usr/lib/pymodules/python2.7', '/usr/lib/python2.7/dist-packages/wx-3.0-gtk2']
>>>
After this your imports will look into the prepended path before looking anywhere else.
You shouldn't need to mess with pip's path, python actually handles it's pathing automatically in my experience. It appears you have two pythons installed. If you type:
which pip
which python
what paths do you see? If they're not in the same /bin folder, then that's your problem. I'm guessing that the python you're running (probably the original system one), doesn't have it's own pip installed. You probably just need make sure the path for the python you want to run should come before /usr/bin in your .bashrc or .zshrc
If this is correct, then you should see that:
which easy_install
shares the same path as the python installation you're using, maybe under /usr/local/bin. Then just run:
easy_install pip
And start installing the right packages for the python that you're using.
Answer to direct question
You could create a directory called sitecustomize in your site-packages directory. We'll turn this into a sitecustomize module as described here (Python 2 here). Specifically:
an attempt is made to import a module named sitecustomize, which can perform arbitrary site-specific customizations. It is typically created by a system administrator in your site-packages directory.
In the sitecustomize directory create a file called __init__.py and add the manipulations you want to perform there. A very simple example is:
import sys
sys.path = ['/your/path/to/pip/install'] + sys.path
In your case, I think your/path... would be /usr/local/lib/python2.7/dist-packages. You might want to do something more sophisticated, but this crudely prepends to sys.path and is run whenever python is started (e.g. starting the interpreter in the command line, or running a python script from a file).
Caveat
I'm not a huge advocate of doing this - it's a bit of a blunt way to do what you want. But you specifically say that using a virtualenv is undesirable for you and you want to make the change "globally" and I think this will do what you want.
Thoughts on underlying issue
I think #fivetentaylor's answer is on the right track here - it appears you are using pip from one install with python executable for another. Masking this by messing with the path could get very confusing very quickly. I'd definitely ensure you have a separate pip for each install of python and you use that. That should keep the directory structures for the separate installs separate. Otherwise, you are forcing one install to use packages from a different installation's directories. No problem technically, but confusing logistically.
Using virtualenv would cause an unnecessary amount of change to my machine, since I would have to reinstall every package that exists globally. I only want to upgrade from Ubuntu's packages to pip's packages.
Nope, you can use --system-site-packages.
Edit
# make your new virtualenv
user#darkstar:~$ mkvirtualenv --system-site-packages max
(max)user#darkstar:~$ python
>>> pprint(sys.path)
['',
'/home/user/.virtualenvs/max/lib64/python27.zip',
'/home/user/.virtualenvs/max/lib64/python2.7',
'/home/user/.virtualenvs/max/lib64/python2.7/plat-linux2',
'/home/user/.virtualenvs/max/lib64/python2.7/lib-tk',
'/home/user/.virtualenvs/max/lib64/python2.7/lib-old',
'/home/user/.virtualenvs/max/lib64/python2.7/lib-dynload',
'/usr/lib64/python2.7',
'/usr/lib/python2.7',
'/usr/lib64/python2.7/lib-tk',
'/home/user/.virtualenvs/max/lib/python2.7/site-packages',
'/usr/lib64/python2.7/site-packages/google_api_python_client-1.2-py2.7.egg',
'/usr/lib64/python2.7/site-packages',
'/usr/lib64/python2.7/site-packages/PIL',
'/usr/lib64/python2.7/site-packages/gtk-2.0',
'/usr/lib64/python2.7/site-packages/IPython/extensions']
As you see, the path of this virtualenv include the system path.
To check if it was working, i installed a package system-wide after making the virtualenv.
root#darkstar:~: pip install igraph
Collecting igraph
Downloading igraph-0.1.8-py2.py3-none-any.whl (119kB)
100% |████████████████████████████████| 122kB 1.7MB/s
Collecting ipython (from igraph)
Downloading ipython-3.2.1-py2-none-any.whl (3.4MB)
100% |████████████████████████████████| 3.4MB 203kB/s
Installing collected packages: ipython, igraph
Successfully installed igraph-0.1.8 ipython-3.2.1
root#darkstar:~: python -c 'print __import__("igraph")'
<module 'igraph' from '/usr/lib64/python2.7/site-packages/igraph/__init__.pyc'>
(max)user#darkstar:max$ python -c 'print __import__("igraph")'
<module 'igraph' from '/usr/lib64/python2.7/site-packages/igraph/__init__.pyc'>
Obviously, what is installed inside the virtualenv takes precedence over the system-wide libraries.
I belive that answer your needs.
Well, the alternatives presented by the others are very acceptable and might even be better. However, if you are intent on using the sys.path() way, then just treat it like a list and use the insert method.
import sys
sys.path.insert(0, "path_to_pip")
from subprocess import call
call("sudo pip install requests")
I would do this with sitecustomize as described in the site.py docs. This file is imported after the initial sys.path is configured and you can use it to alter sys.path in arbitrary ways as needed.
I've used it as a sysadmin to include custom release locations and it does the job quite nicely.
https://docs.python.org/2/library/site.html
While bufh's answer will solve your problem now, you'll likely find that there'll be some other package where you don't want to use the Ubuntu-provided version. So here's why you want to use virtualenvs to manage the versions of packages (and not try to override the system versions).
As you've noticed, the order of sys.path sets the order that python packages are found. This means that changing sys.path affects how python scripts find their imports, both scripts you've written, and those provided by Ubuntu. Given that python scripts are used in Ubuntu programs, it's possible to "break" Ubuntu in interesting ways by changing which version of python packages Ubuntu programs use (which is the reason dist-packages exists).
To avoid this, virtualenv was created, which effectively allows there to be different sets of packages to be used. There's now a bunch of utilities which make using and managing virtualenvs easier. The one that's probably of most interest for you is pipsi, which creates a virtualenv per script, and avoids the need to activate it.
From the sounds of things, Ubuntu is using a package path configuration file as documented here to set up any packages it installs.
Looking at site.py I see that there is a specific order of path resolution that invokes the configuration files as it resolves the site packages directories.
I think that gives you three options that I can see:
Use virtualenv --system-site-packages as per #bufh's answer.
Use pip user installs to set up the packages you need in the path before the standard site packages.
Use sitecustomize to re-write your sys.path (e.g. to put your local directories first).
Related
Context
On a provided Linux-server without root access I am bound to preinstalled Python-packages (e.g. cannot upgrade them).
However, I am able to install a package directly from a wheel (.whl) by using pip3 install /path/package_name --user which will install the package to a site-package-folder preserved to my user.
In my special case I want to upgrade the scikit-learn-package. This package is already preinstalled and I cannot upgrade it (root access missing), however, I can install the newer version in the --user-folder.
In the filesystem I can see that both installations are now present in their respective folders.
Both paths are known to python (checked by using sys.path).
Question/Problem
When I import scikit-learn via import sklearn and print the version (sklearn.__version__), I'll always end up with the preinstalled version and not the new one I installed in my --user-directory.
Given two installations of the same module with a differing version: How can I define in Python during the import which module/version to load?
The premise is that I cannot disable/uninstall the old version (root access again..).
Thanks to #0 0 I was able to figure out the solution as well as a workaround:
Solution
When I compared sys.path with the defined PYTHONPATH in the shell (the PYTHONPATH initializes sys.path like answered here on SO) I saw that the PYTHONPATH did not know about the --user-folder (even though sys.path knew - this puzzles me a bit).
Thus, I added to my .bashrc:
cd # Go to the user folder where .bashrc is stored
nano .bashrc
export PYTHONPATH=$(python3 -m site --user-site)$PYTHONPATH
python3 -m site --user-site identifies the --user-folder pip uses.
In order to load the module first, put it before the current PYTHONPATH.
When now loading sklearn in Python I get the correct version.
Workaround
For the sake of completeness:
One can also just rename the doubled package and import that.
cd $(python3 -m site --user-site) # Go to the folder pip installed the package while using --user
mv package_name package_name_new # Rename it
Then in Python load it this way:
import package_name_new
NOTE: This workaround will cause trouble if you have dependencies relying on it! Thus, better use the correct solution.
I have spent days struggling to get a scientific Python environment running on Mac OS Lion. I tried the SciPack Superpack route, and also various manual installations via pip and easy_install, but still got errors trying to import or use various modules. Based on the advice in this Stackoverflow thread I set up a fresh installation using MacPorts.
However, when I run the macports Python, it is ignoring packages in the macports installation and instead trying to load incompatible packages from the old installation. I am absolutely sure that I am running the newly installed macports Python. I have checked the symlinks and have checked python_select and have launched Python by directly typing the path to the new installation. But when I try to import, say, statsmodels, it pulls in the old version from another directory.
Here are the contents of sys.path (edited for brevity):
['',
'/Library/Python/2.7/site-packages/mrjob-0.4.3_dev-py2.7.egg',
'/Library/Python/2.7/site-packages/statsmodels-0.6.0-py2.7-macosx-10.9-intel.egg',
...
'/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python',
'/Library/Python/2.7/site-packages/twilio-3.6.6-py2.7.egg',
'/Library/Python/2.7/site-packages/six-1.6.1-py2.7.egg',
'/Library/Python/2.7/site-packages/httplib2-0.9-py2.7.egg',
'/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python27.zip',
'/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7',
'/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-darwin',
'/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-mac',
'/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-mac/lib-scriptpackages',
'/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-tk',
'/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-old',
'/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/readline',
'/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload',
'/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages',
'/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/PyObjC',
'/Library/Python/2.7/site-packages']
The macports installation is in /opt/local, while the older installation is under /Library/Python. As you can see, the older packages are higher up in the list, which means that they have higher priority.
Environmental variable PYTHONPATH is empty. If I do put anything into PYTHONPATH, that appears in sys.path after the /Library entries but before the /opt entries. So it does not solve the problem.
If I invoke the new python with the -S option, sys.path becomes:
['',
'/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python27.zip',
'/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/',
'/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-darwin',
'/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-mac',
'/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-mac/lib-scriptpackages',
'/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-tk',
'/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-old',
'/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload']
That succeeds in getting rid of the alien site packages entries, but it also nukes macports' site-packages entries so then I can't load anything.
I believe that the culprit is a file called /Library/Python/2.7/site-packages/easy-install.pth , with the following contents (again edited for brevity):
import sys; sys.__plen = len(sys.path)
./mrjob-0.4.3_dev-py2.7.egg
...
./statsmodels-0.6.0-py2.7-macosx-10.9-intel.egg
...
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python
./twilio-3.6.6-py2.7.egg
./six-1.6.1-py2.7.egg
./httplib2-0.9-py2.7.egg
import sys; new=sys.path[sys.__plen:]; del sys.path[sys.__plen:]; p=getattr(sys,'__egginsert',0); sys.path[p:p]=new; sys.__egginsert = p+len(new)
If I rename that file before launching macports python, python no longer is adding these alien packages to its sys.path. Now sys.path looks a lot like it does when I use "python -S" option except it has these additional entries at the end:
'/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages',
'/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/PyObjC',
'/Library/Python/2.7/site-packages'
Now I am able to load macports' own packages, say for example statsmodels. By checking statsmodels.__file__ I have confirmed that it is importing the local package and not the alien package.
However, I consider this a workaround/kludge rather than a real solution. A solution should make it behave as expected, which is: Macports' Python, launched from /opt/local/... installation, should prioritize packages installed via macports into the /opt/local/... directory tree and go looking elsewhere only if the module does not exist locally. So for example I would expect the /opt/local entries to come first in sys.path, with the /Library entries further down the list.
It seems like this should be the default behavior and I've seen a lot of comments here on Stackoverflow that just assert that this is how Macports Python behaves. So...how do I make it so?
There are at least two separate root causes for the problem you are seeing. One is that non-system OS X framework builds of Python 2.7, including MacPorts Python 2.7, deliberately include the system Python site-packages location, /Library/Python/2.7/site-packages, in sys.path, normally at the end of sys.path after that instance's own site-packages directory. This has been a debated feature in upstream Python and there is an open MacPorts issue to remove it (https://trac.macports.org/ticket/34763), the argument being that it is better to keep the system Python and the MacPorts Python totally separate.
The second root cause is the behavior of the original setuptools package and its easy_install command as supplied with OS X. As you have discovered, it does some fancy manipulation of sys.path by some magic tricks with .pth files, including easy-install.pth, to ensure that the packages that have been installed using easy_install show up first in sys.path and override other installed versions of those packages. Also as you have found, one way - and the easiest way - to remove that behavior is to delete the easy-install.pth file in /Library/Python/2.7/site-packages. That is assuming you don't want to use any of the packages installed there with the Apple-supplied system Python.
The long-term strategy to avoid this problem in the future is to make sure you do not use the Apple-supplied easy_install or easy_install-2.7 commands found in /usr/bin. They will install packages to /Library/Python for use by the system Python and will create or update easy-install.pth. In general, you should avoid use of easy_install all together. Its modern replacement is pip which provides better control and avoids tricks with .pth files. If MacPorts doesn't already provide a port for the Python package you want to install, usually of the form py27-xxxx, install and use the MacPorts py27-pip port instead of easy_install:
/opt/local/bin/pip-2.7 install xxxx
You can also use the usual MacPorts features like port select pip pip27.
I have a couple projects that require similar dependencies, and I don't want to have pip going out and DLing the dependencies from the web every time. For instance I am using the norel-django package which would conflict with my standard django (rdbms version) if I installed it system wide.
Is there a way for me to "reuse" the downloaded dependancies using pip? Do I need to DL the source tar.bz2 files and make a folder structure similar to that of a pip archive or something? Any assistance would be appreciated.
Thanks
Add the following to $HOME/.pip/pip.conf:
[global]
download_cache = ~/.pip/cache
This tells pip to cache downloads in ~/.pip/cache so it won't need to go out and download them again next time.
it looks like virtualenv has a virtualenv-clone command, or perhaps virtualenvwrapper does?
Regardless, it looks to be a little more involved then just copyin and pasting virtual environment directories:
https://github.com/edwardgeorge/virtualenv-clone
additionally it appears virtualenv has a flag that will facilitate in moving your virtualenv.
http://www.virtualenv.org/en/latest/#making-environments-relocatable
$ virtualenv --relocatable ENV from virtualenv doc:
This will make some of the files created by setuptools or distribute
use relative paths, and will change all the scripts to use
activate_this.py instead of using the location of the Python
interpreter to select the environment.
Note: you must run this after you’ve installed any packages into the
environment. If you make an environment relocatable, then install a
new package, you must run virtualenv --relocatable again.
Also, this does not make your packages cross-platform. You can move
the directory around, but it can only be used on other similar
computers. Some known environmental differences that can cause
incompatibilities: a different version of Python, when one platform
uses UCS2 for its internal unicode representation and another uses
UCS4 (a compile-time option), obvious platform changes like Windows
vs. Linux, or Intel vs. ARM, and if you have libraries that bind to C
libraries on the system, if those C libraries are located somewhere
different (either different versions, or a different filesystem
layout).
If you use this flag to create an environment, currently, the
--system-site-packages option will be implied.
If I install all packages using
python setup.py install --prefix=~/.local
how can I make Python read my packages from there and not from the system wide version? I tried editing PYTHONPATH to put ~/.local/lib/python2.x/site-packages/ first, but it does not help.
I thought that ~/.local is guaranteed to be read first in Python 2.6 and later versions. Is this true? Is something special required to make it true? That would solve the issue. Right now it seems that PYTHONPATH paths get incorporated into sys.path but are in the list after the system-wide site-packages directories, making the system wide version get used instead of the one in ~/.local.
Using pip is not an option unfortunately.
It is recommended that you use virtualenv with a proper activation script which will take care of settings up PYTHONPATH properly, without messing up system-wide Python installation in any way
http://www.virtualenv.org/en/latest/index.html
I followed the instructions in this post. Everything installed successfully. However, when I run python I cannot import pygtk. Specifically, it says this:
>>> import pygtk \n
“ImportError: No module named pygtk”
I'm guessing I have to do some commands like make or something, but I can't find anywhere where it says what to do. Please help, I am getting very frustrated.
Edit: I should probably mention I'm on Mac OS X
How are you running python? Is it the one that comes with OSX (/usr/bin/python) or the MacPorts version (/opt/local/bin/python)?
The page you linked to has the instructions for installing pygtk under using MacPorts. So it should run with that installation of python. See the MacPorts wiki for help on how to configure your PATH variable to use the appropriate python installation.
EDIT: Try running the macports python explicitly: "/opt/local/bin/python" and then import pygtk. Also, check under the macports python site-packages directory on the filesystem to see if pygtk exists there (usually something like /opt/local/lib/python2.5/site-packages).
If you are running git mergetool from virtual environment, then python interpreter cannot find pygtk. fix your python path for virtualenv or deactivate virtualenv first.
Below worked for me - assumes you have HomeBrew installed
I was trying to install meld and was getting the same error - this fixed it
brew install python
It is likely that you've installed pip separately (rather than through macports). So, your packages are being installed in a location that is not readable by macports-installed python. For example, in my OS X, the following code works:
[user]$ /usr/bin/python
>>> import pip
>>> for package in pip.get_installed_distributions():
>>> print package, package.location
But if I start /opt/local/bin/python (which is my default python) and say "import pip", then it gives an importerror stating there is no module named pip.
There might be two things that work for you:
1) Install pip using macports, and set that as your default (port install pip). Install pygtk again with this pip
2) Launch python explicitly with /usr/bin/python, and write your codes there.
There may be a way to have the /opt python (from macports) read modules installed by non-macports pip, but I am not aware of it.
a> pip install pygtk - (windows only),
b> brew install python
Not sure why, first options is saying its only works on windows.
Below is working fine for me.
A very general view on the problem, this is what I do if python complains about not finding a module that I know exists:
(This is very general rather basic stuff, so apologies if this is stuff that you already tried even before posting here... in that case I hope it'll be useful to someone else)
1: Go to the python installation directory and make sure the module is actually there (or: figure out where exactly it is -- I have some modules that are part of a project, and thus not in the main directory). ... sometimes this will uncover that the module is not actually installed although it looked like it was)
2: make sure you're writing it correct (capital/lowercase letters are a likely source of frustration -- the import statement needs to reflect the module's directory name)
3: if it isn't located in the python path, either setting the $PYTHONPATH environment variable or putting something like this at the beginning of your script will help:
import sys
sys.path.append('\\path\\to_the_directory\\containing_themodule')
(double slashes required to make sure they're not read as special characters)
in this example, pytk would be in \path\to_the_directory\containing_themodule\pytk'.