We Keep Coding

Import python package after installing it with setup.py, without restarting?

I have a package that I would like to automatically install and use from within my own Python script.
Right now I have this:
>>> # ... code for downloading and un-targzing
>>> from subprocess import call
>>> call(['python', 'setup.py', 'install'])
>>> from <package> import <name>
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: No module named <package>
Then I can continue like this:
>>> exit()
$ python
>>> from <package> import <name>
And it works just fine. For some reason, Python is able to pick up the package just fine if I restart after running the setup.py file, but not if I don't. How can I make it work without having the restart step in the middle?
(Also, is there a superior alternative to using subprocess.call() to run setup.py within a python script? Seems silly to spawn a whole new Python interpreter from within one, but I don't know how else to pass that install argument.)

Depending on your Python version, you want to look into imp or importlib.
e.g. for Python 3, you can do:
from importlib.machinery import SourceFileLoader
directory_name = # os.path to module
# where __init__.py is the module entry point
s = SourceFileloader(directory_name, __init__.py).load_module()
or, if you're feeling brave that your Python path knows about the directory:
map(__import__, 'new_package_name')

Hope this helps,
I downloaded from seaborn from GitHub.
Through command prompt, cd to downloads\seaborn folder
python install setup.py
Then using spyder from anaconda, checked if it was installed by running the following in a console
import pip
sorted(["%s==%s" % (i.key, i.version)
for i in pip.get_installed_distributions()])
Seeing that it was not there, go to tools and select "Update module names list"
Again trying the previous code in a python console, the lib was still not showing.
Restarting Spyder and trying import seaborn worked.
Hope this helps.

How to fix the daemonize import error in graphite?

I am configuring a graphite monitoring system. When following the tutorial on https://gist.github.com/surjikal/2777886 I ran into the following import error:
python /opt/graphite/bin/carbon-cache.py start
Traceback (most recent call last):
File "/opt/graphite/bin/carbon-cache.py", line 28, in <module>
from carbon.util import run_twistd_plugin
File "/opt/graphite/lib/carbon/util.py", line 21, in <module>
from twisted.scripts._twistd_unix import daemonize
ImportError: cannot import name daemonize
Googling around I found several possible solutions for this issue:
1) Remove the daemonize imports from /opt/graphite/lib/carbon/util.py
(https://answers.launchpad.net/graphite/+question/239063):
from time import sleep, time
from twisted.python.util import initgroups
from twisted.scripts.twistd import runApp
# from twisted.scripts._twistd_unix import daemonize
# daemonize = daemonize # Backwards compatibility
2) Use Twisted 13.1.0 instead of a higher twisted version.
3) Install daemonize via pip and import it directly (https://www.digitalocean.com/community/tutorials/installing-and-configuring-graphite-and-statsd-on-an-ubuntu-12-04-vps):
# from twisted.scripts._twistd_unix import daemonize
import daemonize
What is the most stable and proven solution for a twisted environment to fix this import issue?

Option (2) sounds like the best option to me - particularly if you can find some documentation from the Graphite team about Twisted 13.1 being a supported version of Twisted (they should document the supported versions of their dependencies).
With option (1) you're diverging your installation from upstream. This is eventually going to be an admin headache.
I'm pretty sure option (3) won't help. The daemonize module is only related in that it has the same name and does vaguely the same thing. It is not a drop-in replacement, though.

FWIW, options (2) and (3) each worked for me when I tried them independently of each other.
For (2), I ran:
pip install --user 'Twisted==13.1.0'
(2) certainly seems more robust than (1) and (3), so I'd go with that if you can.
I'd previously followed advice I found elsewhere on the web to downgrade to Twisted<12.0, but that only worked in tandem with (3).

python pyjamas install on debian

i have installed pyjamas on debian
http://pyjs.org/getting_started.html
however my program does not find the module, what could be the problem, i have installed pyjamas correctly using apt-get
krisdigitx-virtual-machine ~ # python jamas.py
Traceback (most recent call last):
File "jamas.py", line 3, in <module>
from pyjamas import Window
ImportError: No module named pyjamas
krisdigitx-virtual-machine ~ #
#!/usr/bin/env python
from pyjs import Window
from pyjs.ui import RootPanel, Button
from pyjs.ui import HTML
def greet(sender):
Window.alert("Hello Krishna!")
b = Button("click me", greet)
Rootpanel().add(b)
After some research:
i had to do pyjsbuild jamas.py to get the output directory, however it gives me a new error
jamas TypeError: jamas.RootPanel().add is not a function

Since you get an
ImportError: No module named pyjamas
you may need to add the module's path to $PYTHONPATH with
export PYTHONPATH=$PYTHONPATH:/usr/share/pyjamas/library

Please go to http://pyjs.org/GettingHelp.html
The first link "Getting Started" is a detailled walkthrough for an installation to start from scratch. Basically, what it says there is: Get the up-to-date source code from the git repository.
All steps to get Pyjs and Pyjs Desktop running are described in the Wiki article in the necessary detail, but still concise enough.

python path problem: ImportError when calling zodbconvert (FreeBSD 8.1)

I guess this is a python path problem (on FreeBSD 8.1).
Im trying to convert a Data.fs to Postgresql using zodbconvert. Ive downloaded RelStorage-1.5.0b2 and is running:
/usr/local/Plone/Python-2.6/bin/python zodbconvert.py fstodb.conf
, to use the version that Plone is running with.
The error I get:
Traceback (most recent call last):
File "zodbconvert.py", line 22, in <module>
from persistent.TimeStamp import TimeStamp
ImportError: No module named persistent.TimeStamp
Versions:
Plone 4.0.5 (python 2.6)
Postgresql 9.0.3
FreeBSD 8.1
python26-2.6.6_1
python27-2.7.1_1
PS by default "python --version" is 2.7.1
Thanks.
Nikolaj G.

If you are using buildout (I do hope you are) the easiest way to get all the zodbconvert dependencies properly included in the python path is to have buildout create the script for you:
[buildout]
...
parts =
...
zodbconvert
[zodbconvert]
recipe = zc.recipe.egg
eggs = ${buildout:eggs}
scripts = zodbconvert
Buildout then will create a new bin/zodbconvert script for you that includes all the buildout eggs in sys.path.
Alternatively, you can create a generic python script runner that includes all eggs in your buildout and can run arbitrary scripts; you can use this instead of the bare-bones python interpreter to run arbitrary python scripts with all the buildout eggs in sys.path:
[buildout]
...
parts =
...
zopepy
[zopepy]
recipe = zc.recipe.egg
eggs = ${buildout:eggs}
interpreter = zopepy
scripts = zopepy
The bin/zopepy script can then be use to run arbitrary python scripts with all your buildout eggs already in sys.path, so bin/zopepy zodbconvert.py fstodb.conf should work.
Note that the Plone unified installer already comes with the zopepy part included, and my choice of partname for this script was deliberately using the same name.
If you are not using buildout (and with Plone 4, that's not a good idea on the whole), you can also list the required packages (ZODB3, zope.interface, RelStorage, psycopg2) in your PYTHONPATH environment variable.

quick fix..
locate persistent
export PYTHONPATH=$PYTHONPATH:/path/to/your/python_persistent_dir

You have not included the ZODB package with your Python installation. Either adjust the PYTHONPATH to include the ZODB package or just easy_install ZODB - depending on what you are trying to do.

How can I use Django with MySQL in MAMP stack?

I have difficulty especially in installing MySQLdb module (MySQL-python-1.2.3c1), to connect to the MySQL in MAMP stack.
I've done a number of things such as copying the mysql include directory and library (including plugin) from a fresh installation of mysql (version 5.1.47) to the one inside MAMP (version 5.1.37).
Now, the MySQLdb module build and install doesnt give me error.
The error happens when I'm calling 'import MySQLdb' from python shell (version 2.6).
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "build/bdist.macosx-10.6-universal/egg/MySQLdb/__init__.py", line 19, in <module>
File "build/bdist.macosx-10.6-universal/egg/_mysql.py", line 7, in <module>
File "build/bdist.macosx-10.6-universal/egg/_mysql.py", line 6, in __bootstrap__
ImportError: dlopen(/Users/rhenru/.python-eggs/MySQL_python-1.2.3c1-py2.6-macosx-10.6-universal.egg-tmp/_mysql.so, 2): Symbol not found: _mysql_affected_rows
Referenced from: /Users/rhenru/.python-eggs/MySQL_python-1.2.3c1-py2.6-macosx-10.6-universal.egg-tmp/_mysql.so
Expected in: flat namespace
in /Users/rhenru/.python-eggs/MySQL_python-1.2.3c1-py2.6-macosx-10.6-universal.egg-tmp/_mysql.so
Any idea, what else do I need to do to make it works?
Thanks a bunch,
Robert
=========
Add the system response after using virtualenv as suggested by Hank Gay below...
(MyDjangoProject)MyMacPro:MyDjangoProject rhenru$ which python
/Users/rhenru/Workspace/django/MyDjangoProject/bin/python
After I run python in virtualenv, importing MySQLdb:
>>> import MySQLdb
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "build/bdist.macosx-10.6-universal/egg/MySQLdb/__init__.py", line 19, in <module>
File "build/bdist.macosx-10.6-universal/egg/_mysql.py", line 7, in <module>
File "build/bdist.macosx-10.6-universal/egg/_mysql.py", line 6, in __bootstrap__
ImportError: dlopen(/Users/rhenru/.python-eggs/MySQL_python-1.2.3c1-py2.6-macosx-10.6-universal.egg-tmp/_mysql.so, 2): Symbol not found: _mysql_affected_rows
Referenced from: /Users/rhenru/.python-eggs/MySQL_python-1.2.3c1-py2.6-macosx-10.6-universal.egg-tmp/_mysql.so
Expected in: flat namespace
in /Users/rhenru/.python-eggs/MySQL_python-1.2.3c1-py2.6-macosx-10.6-universal.egg-tmp/_mysql.so
import sys and sys.path
>>> import sys
>>> print sys.path
['', '/Users/rhenru/Workspace/django/MyDjangoProject/lib/python2.6/site-packages/distribute-0.6.10-py2.6.egg', '/Users/rhenru/Workspace/django/MyDjangoProject/lib/python2.6/site-packages/pip-0.7.1-py2.6.egg', '/Users/rhenru/Workspace/django/MyDjangoProject/lib/python26.zip', '/Library/Python/2.6/site-packages/PyXML-0.8.4-py2.6-macosx-10.6-universal.egg', '/Library/Python/2.6/site-packages/pydot-1.0.2-py2.6.egg', '/Library/Python/2.6/site-packages/pyparsing-1.5.2-py2.6.egg', '/Library/Python/2.6/site-packages/vobject-0.8.1c-py2.6.egg', '/Library/Python/2.6/site-packages/pytz-2010h-py2.6.egg', '/Library/Python/2.6/site-packages/MySQL_python-1.2.3c1-py2.6-macosx-10.6-universal.egg', '/Library/Python/2.6/site-packages/distribute-0.6.12-py2.6.egg', '/Library/Python/2.6/site-packages/pip-0.7.1-py2.6.egg', '/Users/rhenru/Workspace/django/MyDjangoProject/lib/python2.6', '/Users/rhenru/Workspace/django/MyDjangoProject/lib/python2.6/plat-darwin', '/Users/rhenru/Workspace/django/MyDjangoProject/lib/python2.6/plat-mac', '/Users/rhenru/Workspace/django/MyDjangoProject/lib/python2.6/plat-mac/lib-scriptpackages', '/Users/rhenru/Workspace/django/MyDjangoProject/Extras/lib/python', '/Users/rhenru/Workspace/django/MyDjangoProject/lib/python2.6/lib-tk', '/Users/rhenru/Workspace/django/MyDjangoProject/lib/python2.6/lib-old', '/Users/rhenru/Workspace/django/MyDjangoProject/lib/python2.6/lib-dynload', '/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6', '/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/plat-darwin', '/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-tk', '/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/plat-mac', '/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/plat-mac/lib-scriptpackages', '/Users/rhenru/Workspace/django/MyDjangoProject/lib/python2.6/site-packages', '/Library/Python/2.6/site-packages', '/Library/Python/2.6/site-packages/PIL', '/Library/Python/2.6/site-packages/setuptools-0.6c11-py2.6.egg-info', '/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python', '/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/PyObjC', '/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/wx-2.8-mac-unicode']

How are you installing MySQL-Python? I just tested in a fresh virtualenv and pip install mysql-python seems to have done the trick.
UPDATE:
pip is sort of like a package manager for Python packages.
By default, pip installs to your current site-packages directory, which is on your $PYTHONPATH. This lets other libraries/applications (like Django) access it. pip also works well with virtualenv (it should; Ian Bicking wrote them both), which is a nifty library that lets you sandbox an application. This is nice because it means you can try out new things without polluting (or even needing write access to) the global site-packages directory.
It probably seems like yak-shaving right now, but I'd say it's worth the effort to get up to speed on pip and virtualenv (you may also want to look into virtualenvwrapper, but we'll skip that for now; it's just sugar for virtualenv). It will lead to a slightly more complicated deployment scenario than putting everything in the global site-packages, but for development it's really no harder, and there are lots of good guides to deploying using a virtualenv.
I'd recommend something like the following:
curl -0 http://python-distribute.org/distribute_setup.py
python distribute_setup.py
easy_install pip
pip install virtualenv
virtualenv --distribute MyDjangoProject --no-site-packages
cd MyDjangoProject
source bin/activate (this activates the sandbox that virtualenv created)
pip install django mysql-python
At this point, you should have a totally functional Django+MySQL install (if I missed any steps, just comment and I'll try to add it in). You can start your Django project like this: django-admin.py startproject MyDjangoProject. cd into your project's directory, edit your settings.py file to point to your MySQL database, and run the dev server to test it out like so: ./manage.py runserver (you may need to chmod u+x your manage.py file). Voila! You should be able to access your site on localhost:8000. When you're done working on the project, you can just use deactivate to exit the virtualenv sandbox.
Try not to hold all this against Django: a lot of it is just best practices stuff for working with Python libraries. You could get by with a lot less, but this way it's more reproducible and you're less likely to accidentally mess up one of this project's dependencies when working on a different project.

I had this problem and it turned out to be due to an errant configuration:
export VERSIONER_PYTHON_PREFER_32_BIT=yes
I can't recall what I had this enabled for (some package that required 32-bit), probably related to Google AppEngine. But Setting it to 'no' solved by issues.
Otherwise I just installed everything using homebrew and pip.