Wednesday, May 17, 2006

The missing Mercurial manual

I think I've found my ideal solution for version control. I used bzr for a few weeks, and appreciated its distributed nature - no single repository has to be the ultimate authority, so it works well for machines that can't all be connected to the same network. I use a travelling USB drive to sync my machines, so it was perfect... except that bzr can take several minutes for just a few merges. It got annoying when the merge was keeping me from leaving work.

Mercurial is also distributed, but it's very, very fast. It's even (gasp) well-documented! There are, however, a few things I think a newbie should know up-front.
  • The tutorial assumes you'll start by copying an existing mercurial repository. I wanted my own, though, and it took me several tries to figure out that I needed to do this:
    ~/existing$ hg init
    ~/existing$ hg add foo.bar
    ~/existing$ hg commit
    ~/existing$ cd ..
    ~$ hg clone existing newdir

    Later on, if I make new files in existing, they won't get to newdir until I
    ~/existing$ hg add newfoo.bar
    ~/existing$ hg commit
    ~/existing$ cd ../newdir
    ~/newdir$ hg pull
    ~/newdir$ hg update

    pull brings fresh metadata in from the other repository, storing it in .hg, but doesn't actually go on to update the files themselves. That's what update does. It took a while to get it, but now that I do, it seems intuitive and helps me feel in control.
  • Your EDITOR or HGEDITOR environment variable must be set, or else hg commit will hurl you pitilessly into vi (*nix) or throw up its hands and scoff at you (Windows).
  • But, if you use gedit and already have another file open in it, you get
    ~/existing$ hg commit
    transaction abort!
    rollback completed

    I suspect that may happen with other multi-file editors, too. I'll use EXPORT HGEDITOR=pico.

Tuesday, May 16, 2006

Python in OTN again

Here's a cheer to Przemek Piotrowski for his recent OTN article, Build a Rapid Web Development Environment for Python Server Pages and Oracle. Python Server Pages are just one of the 1022 ways to build a web application with Python, but his methodical instructions would be useful for doing anything remotely related (including installation of Oracle XE and mod_python).

Friday, May 05, 2006

SQLpython - a SQL client of your very own

Luca Canali has written SQLpython, a lovely new SQL command-line tool for Oracle.

Right now, the most popular SQL command-line tools are
  • SQLPlus, included with Oracle, is sometimes great, sometimes annoying, and impossible to modify (source code not available).
  • gqlplus is open-source. It's written in C, though, which means (to my mind) that you'll need all of your strength and all of your courage if you want to modify it.
So, download sqlpython.tar, untar it, put sqlpython.py and mysqlpy.py somewhere handy (like your Python library), and then:
$ python
>>> import mysqlpy
SQL.NoConnection> connect hr/hr@xe
SQL.xe> select * from employees;
Now comes the fun part! Open up mysqlpy.py and sqlpython.py and start modifying. They're very basic right now, but very clean, concise, easy to understand, and easy to modify. For instance, I wanted to be able to issue Python commands like this:
SQL.xe> py print 'This is a python command';
This is a python command.
So I added this method to mysqlpy:
    def do_py(self, arg):
exec(arg)
That's all I did - not one keystroke more - and it works. Now that's extensibility!

If you're not an Oracle person and you're envious, as far as I can tell, it should be easy to modify SQLpython to use any DB-API2 adapter.