Not content to leave well enough alone, I offer up some extensions to Ian Bicking's virtualenv script that make it even more useful.
This article was originally published by Python Magazine in May of 2008.
Read More
IPython is a feature-rich interactive shell for Python developers. Virtualenv creates isolated development environments so you can test or install packages without introducing conflicts. In this column, I examine how both tools can make your life a little easier.
This column was originally published by Python Magazine in February of 2008.
Read More
The May issue is available online now.
Our cover story this month is the first of a 3 part series from Terry Hancock introducing Python programming with PyGame. Terry does an excellent job of covering the basics, and while the article is targeted at younger readers, it isn't dumbed down at all. I've read the rest of the series already (perks of being on the staff), and I highly recommend it as a summer project if you have someone interested in learning about programming while having fun with basic animation techniques.
Also up this month, Michael Foord explains how to use ConfigObj to manage the configuration files for your application. It has many features that may make it a more attractive option than the core module ConfigParser.
Jon Miller makes a strong argument for using LDAP to establish consistent system configurations in his piece, titled LDAP backed initScripts in Python. LDAP was new territory for me, and I think the idea of using a central server to host all of the configuration for your data center makes a lot of sense.
Paul McGuire's article, Writing a Simple Interpreter/Compiler with Pyparsing, brought back a lot of memories from some of my favorite topics in college. The language he chose to implement as an example is pretty twisted, to say the least. If you have a parsing task, Pyparsing may be the tool for you.
In his Welcome to Python column this month, Mark Mruss covers descriptors and properties for new-style classes. No more __getattr__() methods with case statements in them!
Steve Holden presents his PyCon report, including his own Teach me Twisted session. I had to leave early from that session, so I was glad to hear that it went well.
Brian Jones wonders about training and certification for Python programmers. There has been some discussion of certification online recently, too. I'm not sure where I stand on the idea, yet. What do you think, do we need a standard certification program?
And my own column covers virtualenvwrapper, a couple of bash shell functions to making Ian Bicking's virtualenv even more useful.
Check it out, and as always let us know what you think!
Last week I finally cleaned up the wrapper code I've been using with Ian Bicking's virtualenv. The results are a set of bash functions imaginatively dubbed "virtualenvwrapper".
The basic idea is that you source the script in your ~/.bashrc, and then you can use the functions it defines to manage your virtual environments, either from other scripts or from the command line.mkvirtualenv is a thin wrapper around virtualenv itself, and creates environments in a special directory, which you can control through the WORKON_HOME variable. Now that I think of it, that variable should probably have a different name. Oh, well.
Most of the time, you'll use the function workon. Without arguments, it will list the environments you have available. With a single argument, it switches to that environment.
Once you're done with an environment, use rmvirtualenv to remove it.
So it's nothing earth-shattering, but I find it very useful. I put it together because I create and delete virtual environments so frequently -- one per article and column for the magazine, plus one for each of my own projects -- that I really needed to enforce some sanity around them.
In addition to the organization, the extra feature workon adds is activation hooks for the environment. Each time you switch environments, workon looks for (and runs) $VIRTUAL_ENV/bin/predeactivate in the current environment (before switching) and $VIRTUAL_ENV/bin/postactivate in the new environment (after switching). The hooks are intended for saving editor state, loading new project files, etc.
For now there's just one file, but I'm still distributing it in a versioned tarball because that's just easier with my existing workflow and release tools. I'm not sure how to use distutils with a bash script, or even if that's a good idea, so it's a manual download, too.
