E pur si muove

When essential tools break...

Saturday, August 26, 2006

I hate it when that happens. Current case:

flub@coronation:/tmp/sandbox$ gpg --clearsign test
gpg: selecting openpgp failed: unknown command
gpg: signing failed: general error
gpg: test: clearsign failed: general error

That's just to get desparate. Some quick poking around results in leading me to think that this only happens when the smart card is involved. --symetric and --list-keys etc seem to work fine.

What's changed on my system? The hardware is still fine as it works on my Debian Sarge box. grrr...

Update: it ends up that seahorse-agent is the bad guy! Disable the agent and all is fine again. I should figure out the details sometime later and amke sure it works. Next problem however is making debsign work with the card nicely, weird that no DD has done that yet.

Update2: seems the debsign problem was just that I was signing from inside my chroot which didn't have access to the required hardware. Oh well, it was late last night.

UTF-8 and Emacs

Thursday, August 24, 2006

While looking around in Manoj's Debian web-page/directory for his new Python policy (for how to package Python stuff for Debian) I stumbled, amongst other intresting things, across this cool UTF-8 demo file.

To my surprise my web browser (Epiphany) shows nearly everything perfect, so does gedit. However my much beloved and favourite religion Emacs, where I spend most of my text-editing time, does not! Even after I installed all the xfonts-intl-* on my Debian box. Surely Manoj knows which packages are needed (given that he even reads mail with Emacs while I use merely mutt), why not write that down into the same file?

No editors or religions where harmed in the creation of this post, a web browser and keyboard have been harmed however as I had to write it into a silly web form wich makes me angry from time to time for not being enough Emacs like.

[I know I should get a better blogging system, maybe ikiwiki is the way to go...]

site module musings

Tuesday, August 22, 2006

The site package reads .pth files and inserts directories listed there in sys.path. However it only scans lib directories (lib/python2.4/site-packages/ and lib/python/site-python/ on UNIX) starting with sys.prefix or sys.exec_prefix for these .pth files. Thus if you install a module distribution using the .pth mechanism but passing --prefix=/foo or --home=/bar to you're in trouble.

Is it such a weird idea to at least scan the directories given in $PYTHONPATH for .pth files? I would even suggest that site just scans the entire sys.path for .pth files, but it might be that I'm overlooking a security issue there (but having an insecure direcotry on sys.path is dangerous anyway and should not happen afaik). I can agree that scanning for a .pth file inside a directory added by a .pth file is rather useless though.

So this leaves me with the idea of filing a bug to change site to scan $PYTHONPATH directories too... If no one stops me I might do that soon.

Python web frameworks

Tuesday, August 22, 2006

It appears discussing web frameworks is popular currently. It also appears GvR has decided he likes Django and hopes it will become sort of the default.

I've been looking at this Django and TurboGears things for a while unable to decide if I should move the website that I appear to be maintaining (which was originally written in PHP and is rather unmaintainable by now) to one of them. I'm not going to add my own comparison here, but I remember from last time I looked at them they both had points I liked and I disliked and I was left undecided. Point is this "blessing" of Django doesn't help me at all. Firstly it's only the personal decision of one person, it doesn't help that that person doesn't like XML so effectively didn't really consider TurboGears.

Today however I had the idea to see if any of the two had any pre-build packages that one can use, like PHP has for forums, photo galleries etc.[1]

I couldn't find a link on the TurboGears website, but using Google I immediately ended up at a part of that was exactly this: a collection of useful applications/widgets. It's called cogbin. I'm not quite sure how it got hidden so well on their site, maybe because there aren't too many available yet. But it's important to note that they integrated it with the Python Cheese Shop by using the trove classifiers. I can't explain how good I find that.

For Django I found nothing of like this. Not on their site and not using Google. Did I just miss it or are they just not as organised?

So maybe I'm tending towards TurboGears for the moment. Their approach also seems more modular which seems to fit more in with the UNIX philosophy in my oppinion. They're even talking about things like markup, SQLAlchemy and Routes. All very exciting things IMHO.

[1] Now we're at it it's maybe also a good time to define interfaces to interact between components like this. I'm thinking mainly about user authentication and creation (but I'm sure there is more). That's a different story though. setup(..., extra_path="foobar", ...)

Monday, August 21, 2006

The extra_path keyword that you can pass to setup() when using the distutils for building and installing a package is completely undocumented as far as I know. I have no idea how I found it the first time (about a year ago) but now it was there and was not doing the Right Thing. The only option I found was to look at the source code of the distutils itself and figure it out from there with much trial and error.

What I'm trying to achieve doesn't seem so weird though. I'm keeping some modules under a src/ directory but don't want them installed in the ``root'' package but in .../site-packages/hprof/ with that being imported into the ``root'' package via .../site-packages/hprof.pth. Rather similar to what Numeric does I've discovered by now.

Anyway, the end of the story is that had to use the following keywords to setup():

package_dir={'': 'src'},
ext_modules=[Extension("_hotshot", ["_hotshot.c"])],

All files, including _hotshot.c live under src/ here, and this ends up installed in the system as described above. According to the distutils code the extra_path keyword is a hack specifically made for Numeric maybe that's why it's not too wel documented.

In case you're wondering what the point is, it's all in that _hotshot module you can see above. I'm creating my own version of that and need to be able to manipulate the sys.path such that it is loaded before the system provided one. Hence the reason for me to install into .../site-packages/hprof/ as I can easily move that earlier in the path before importing _hotshot.

Yes, this also means I'm finally getting an updated version of hprof out soon. Only a year after I got paid by Google for it :-). I must say it's quite disturbing discovering that I screwed up the build system completely last time. It seems I got away with it though... I'll still need to do some more testing tomorrow when I'm more awake, but should get a 0.1.1 out soon. Then build a Debian package and create a patch for the _hotshot.c in the trunk of, which --if it gets accepted-- could remove the need for the custom _hotshot I need to ship now and hence get rid of the weird and complicated build system.

We'll see how that ends, I need to do some job hunting in between too however :-(.

Today's WTF: sys.path in python != sys.path in ipython

Thursday, August 17, 2006

Spot the current directory (<snip>/build/lib.linux-i686-2.4) in the path:

<snip>/build/lib.linux-i686-2.4$ echo $PYTHONPATH

<snip>/build/lib.linux-i686-2.4$ python
Python 2.4.3 (#2, Apr 27 2006, 14:43:58)
[GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.path
['', '<snip>/build/lib.linux-i686-2.4', '/home/flub/lib/python', '/home/flub/lib/python2.4', '/usr/lib/', '/usr/lib/python2.4', '/usr/lib/python2.4/plat-linux2', '/usr/lib/python2.4/lib-tk', '/usr/lib/python2.4/lib-dynload', '/usr/lib/python2.4/site-packages', '/usr/lib/site-python']
>>> Ctrl-D

<snip>/build/lib.linux-i686-2.4/$ ipython
In [1]:import sys
In [2]:sys.path
In [3]: Ctrl-D

This seriously screws up my interactive sessions with ipython since the module in /usr/lib gets loaded before my own modified one. Why does ipython think it is a good idea to do it that way?

Since we're at the subject, notice the PYTHONPATH environment variable. Why does just the existence of this variable -- what it is set to does actually not matter at all -- make the current directory show up in the path. Also what's the point of the empty ('') string at the beginning of the path? What does that do?

Lots of questions, I know, but I haven't found any of the answers anywhere so far. Maybe I have just looked to hard, but I'm very intrigued.

Subscribe to: Posts (Atom)