Posted by: bjb

Recently I recorded an episode for Hacker Public Radio. It answers some questions that another contributor, knox, had about virtualenvwrapper. My episode will (if all goes well) be published on June 27 as episode 2322.

 continue reading
Posted by: bjb

I looked up a question on stackoverflow, and even found it. But it had no answer, so I wrote one.

With luck, it’s not too far wrong.

… well I guess I answered the wrong question. Oops.

Can an existing folder be redeclared a virtual enviroment with VirtualEnvWrapper?

I thought this was a project that had been made with virtualenv, and they wanted to put it under virtualenvwrapper. But apparently it was made with virtualenvwrapper, and I don’t know what they want to do with it.

They can probably get the answer to their question from my answer, though.

My answer:

Yes.

Anatomy of virtualenvwrapper

The existing project has two parts:

  • the virtualenv, where python and the python libs are installed, and
  • the project directory where your code is (that uses the virtualenv).

Virtualenvwrapper adds a third part, the virtualenvwrapper hooks. These are mainly shell functions that are called at certain times in a project or virtualenvs life cycle. They live in a third directory — by default, they are installed to ~/.virtualenvs (at least that was true on my Debian wheezy system). The hooks include postactivate, which we will edit below, and a bunch of others such as premkproject, premkvirtualenv, etc. The following list of keywords gives you the flavour of the hooks: initialize, pre/post, mk/rm, project/virtualenv, activate/deactivate. virtualenvwrapper puts these scripts in $VIRTUALENVWRAPPER_HOOK_DIR, which defaults to $WORKON_HOME.

virtualenvwrapper assumes

  • all the virtualenvs are in one place ($WORKON_HOME) (defaults to ~/.virtualenvs) Let’s say you have two virtualenvs, one called MYVENV and the other called MYOTHERVENV
  • all the project directories are in another place ($PROJECT_HOME).

Let’s say you have a project “is” in directory /home/me/where/my/proj that uses virtualenv MYVENV.

how to use workon to work on your pre-existing code and virtualenv

Here I’m assuming all your virtualenvs are in one place (in my case, they are all in /usr/local/virtualenv).

one-time operations

** edit ~/.virtualenvs/postactivate (+) to have

    case $env_name in
        MYVENV)
            cd /home/me/where/my/proj/is
            ;;
        MYOTHERVENV)
            cd /home/me/where/my/other/project/is2
            ;;
    esac

** links

    for hk in get_env_details initialize postactivate postdeactivate \
            postmkproject postmkvirtualenv postrmproject \
            postrmvirtualenv preactivate predeactivate premkproject \
            premkvirtualenv prermproject prermvirtualenv; do \
        ln -s ~/.virtualenvs/$hk /usr/local/pythonenv/$hk; \
    done

any time you want to work on your project that uses MYVENV virtualenv

    WORKON_HOME=/usr/local/pythonenv workon MYVENV

Of course if all your virtualenvs are indeed in the same place, you can define WORKON_HOME in your .profile and you won’t have to specify it on the command line every time.

Categories: ,
Posted by: bjb

My app wasn’t running in the virtualenv I had prepared for it … I activated a virtualenv by sourcing /usr/local/pythonenv/DJANGO-1-1/bin/activate, and then ran ./manage.py runserver. However, according to the debug stuff I put in the template (django.get_version() and python.VERSION), the app wasn’t using the right django.

It turns out that manage.py has #!/usr/bin/python at the top — it wasn’t running the python in the path but a hardcoded path to the system python. To use the virtualenv’s python, change that top line to:

#!/usr/bin/env python

This will use the python that can be found in the path of the calling process — which is what you want when using virtualenv.

It may be that newer django’s will generate the /usr/bin/env line, but if you created your project with an older django, you might need this step.

Categories: , ,
Posted by: bjb

If you are using pip install somepackage, and it is not going into your virtualenv, perhaps you are tripping over the same thing I did.

I had activated the virtualenv with /usr/local/pythonenv/DJANGO-1-1/bin/activate, and (DJANGO-1-1) was appearing in the shell prompt. which pip showed /usr/local/pythonenv/DJANGO-1-1/bin/pip. python followed by

import sys
for p in sys.path:
    print p

showed that the system site-packages directories were not being included. So why was the python package being installed to /usr/local/python2.6/site-packages???

Well, the pythonenvs had been installed as root. I was actually running sudo pip install somepackage and that meant I was losing the virtualenv environment (which sets some environment variables that don’t survive the sudo to root transition).

So the solution was to run [UPDATED 2011/01/04]

sudo /usr/local/pythonenv/DJANGO-1-1/bin/pip install -E /usr/local/pythonenv/DJANGO-1-1/ somepackage

and indeed I threw in the --download-cache option to cut down on the download time (although I subscribe to DSL, my download times are closer to dial-up speeds) for subsequent installs into the DJANGO-1-0 and DJANGO-1-2 virtual envs.

Posted by: bjb

I’m trying out byteflow under django 1.2, and I finally have it working. There were only a few changes to make.

First off, the databases are specified differently in django 1.2 — there is the option to connect to multiple databases now. Strangely however, django did not force me to change my database settings … I guess there is some backward compabitility stuff for now.

old settings_local.py

    DATABASE_ENGINE = 'postgresql_psycopg2'
    DATABASE_NAME = 'byteflow'
    DATABASE_USER = 'db_user'
    DATABASE_PASSWORD = 'sekrit'

new settings_local.py

    DATABASES = { 'default' :
        {
            'ENGINE' : 'postgresql_psycopg2',
            'NAME'   : 'byteflow',
            'USER'   : 'db_user',
            'PASSWORD' : 'sekrit',
        }
    }

There are also some deprecation warnings in the logs about admin.site.root, in urls.py (I may have added all those ‘settings.BLOG_URLCONF_ROOT’ in when using ‘bjb’ as my URL_PREFIX):

old:
    url(r'^%sadmin/(.*)' % settings.BLOG_URLCONF_ROOT,
        admin.site.root, name='admin'),

new:
    url(r'^%sadmin/(.*)' % settings.BLOG_URLCONF_ROOT,
        include(admin.site.urls)),

But this didn’t work for me so I went back to the old way. The problem was that when I asked to edit a blog post, it brought me to the main admin page. When I clicked on the Change link, it stayed on the main admin page. I’ll have to look into that another time.

An update was required to apps/tagging/managers, in usage_for_queryset, to update the database query for the django 1.2 database scheme (multiple databases). I found this hint.

Also, in order to run django 1.2 on my stable machine, I set up a virtualenv (with --no-site-packages) in which to run it. Had to install all the site-packages into the virtualenv:

  • BeautifulSoup-3.1.0.1
  • Django-1.2.1
  • PIL
  • mx
  • openid
  • psycopg2-2.0.7

That’s about it except for infrastructure:

  • easy-install
  • pip-0.8
  • setuptools-0.6c8

Well I suppose I should have started by upgrading byteflow, I’ll have to try that another time. Maybe some of my changes have been fixed in upstream already. However I did quickly note that the byteflow install page still says it requires django 1.0.

Posted by: bjb

Using my blog for it’s intended purpose: notes to self.

django on my server is an older version, my apps developed on my desktop need a newer version of django. I need to deploy virtualenv on my server so I can run a newer version of django for some apps. Like ipaddr and byteflow.

byteflow in particular, needs jquery.js (for attaching an image to a post, via postimage app and TAGGING_AUTOCOMPLETE_JS_BASE_URL setting) and that is not included in django 1.0.2.

But I’m out of time for today, so this is a task for another day.

Categories: , ,
Posted by: bjb

I created a new django app on my development machine running Debian SID (updated Aug 14-ish) and wanted to run it on my server machine running Debian stable (lenny). It didn’t work:

 machine    |           devel                   server
----------------------------------------------------------
Debian      |        sid (Aug 14)           stable (lenny)
django      |            1.2                      1.0
python      |            2.6                      2.5

There were complaints about missing modules, missing middleware, etc etc. Commenting out those bits resulted in more complaints about other things. So I figured I’d just have to run a “private” copy of django for that application.

To figure out what to copy, I looked at the python-django package contents using

dpkg -L python-django

and that pointed me to this directory full of django implementation files:

/usr/lib/pyshared/django

So I copied that over to the stable machine next to the little application, told the application to use that django by inserting that directory at the beginning of PYTHONPATH in the wsgi script, and ran the application.

It couldn’t find the module core.handlers.wsgi

That file was there …. but no __init__.py file in core/handlers.

It turns out there were lots of missing __init__.py files … and it turns out that although Debian installs the django python implementation files in /usr/lib/pyshared/django, it uses them from another directory /usr/lib/pymodules/python2.6/django, which is a mirror directory structure with a bunch of links to /usr/lib/pyshared/django for the files in /usr/lib/pyshared/django, plus some other files (like the missing (and usually empty) __init__.py files, plus a pile of .pyc files).

My guess is that Debian makes the mirror directory so that the .pyc files will not mess up the “source” install directory.

The upshot is, that if you’re going to run another django by copying django to a directory local to the application and altering the PYTHONPATH, copy the /usr/lib/modules/python2.6/django directory and not the /usr/lib/pyshared/django directory.

But, the better solution is to use python virtual environments (venv). My app is a tiny thing that only uses django and nothing else (django was really overkill for my app) but it’s a Bad Idea to solve the “wrong-django” problem this way. For example, any time a file disappears from the new version of django, my app would still find it in the old path (which didn’t get removed when I altered PYTHONPATH).