So far I’ve found that distributing .egg files is mostly useless:

  • Source tarballs as created with the distutils/setuptools sdist command are not only equivalent to eggs, they often contain more information (such as top-level README.txt or INSTALL.txt files). Also, not everybody has embraced easy_install yet and a tarball is the least surprise to the old-school folks.
  • .egg files are marked with the Python version they were created with. So if you only upload an .egg file that was created with, say, Python 2.4, and you don’t provide a source tarball, Python 2.5 users will be out of luck trying to easy_install your package (even though it may perfectly work on Python 2.5).
  • If the package contains C extensions, you pretty much can’t risk uploading an .egg file because it’ll contain binaries. With Linux and MacOSX this is unacceptable due to the various ways Python itself can be built on these platforms (and will therefore likely be incompatible with anything you’ve built). One notable exception is Windows which (thanks to its homogeneousness) makes it possible to distribute binaries w/o problems. Then again, because Windows users rarely have the right compiler installed, it pretty much requires you to distribute binaries.

So why are we still uploading .egg files to PyPI? Isn’t it enough and even better to just upload the source tarball? (And a Windows binary egg only if the package contains C extensions.)


So Sweden just passed “lex Orwell” allowing their Gestapo^H^H^H^H^H^H^Hsecret service to put all electronic traffic coming in or going out of the country under surveillance (fellow Zopista and Swede Lennart Regebro has written about this as well). This is, by far, the most drastic law in this respect and I’m literally speechless. Fortunately, something like this would be quite unconstitutional in this country (but then again IANAL, so what do I know). Mind you, this hasn’t stopped the German coalition of the willing from passing a law on data retention whereby all telecommunication providers in Germany must store telecom data for 6 months and provide them to the authorities when necessary. And if you live in any other European country, chances are good your government has also passed similar laws as there’s a EU guideline that inspired the German law.

Anyway, all of this really isn’t a scandal. It’s sad, wrong, and many other things. The real scandal, however, is that nobody is using email encryption. If we all wrote encrypted emails, good luck to any government agent trying to make out what we’re writing each other. We use encryption when buying junk off the internet, when doing online banking, even when checking in code into a version control repository. Why aren’t we doing email encryption?

Yes, I’m aware email encryption is out there and actively used, for instance by enterprises and corporations to prevent industry espionage (when I worked for Siemens, Infineon, etc., confidential emails to out-of-office addresses always had to be encrypted). When I say “nobody is using it,” I mean my mom and dad, my best friends, my fellow students at university, heck, even I. Where’s the built-in encryption functionality for Apple Mail? For Thunderbird? For Outlook? For Gmail? Who needs Exchange for the rest of us when there isn’t even email encryption for the rest of us?

See Hope to see you there!

Update: Christian, the organizer of the training has set up a website with registration information at

ZopeSkel is a neat collection of Zope-related PasteScript templates, but I have two beefs with it. First of all, most templates ask way too many questions (why does it want a description of my package as reST now???), but I can deal with that (just hit return a bunch of times until the annoyance is over). What’s very annoying is the setup.cfg file it generates. It needs to go.

Here’s why: It sets a bad example. The setup.cfg files that ZopeSkel generates are configured so that they adds the ‘dev’ marker and the current SVN revision number to the egg’s version number. In other words, ZopeSkel suggests that continuous releases are a good idea. They’re not. If you don’t want to deploy from a release, then just get a checkout and deploy a development egg. If you want to deploy from a release, make a release (yes, I know that it takes time, but we have release procedures for a reason). Of course, when you want to make a proper release and you forget about setup.cfg, you will generate a fubared release (e.g. foo-1.3dev-r2342 instead of foo-1.3).

It does make sense to mark the trunk or development branches with the ‘dev’ marker (so that accidental releases don’t happen), but the logical places for this is (because that’s where you’d expect to set the version number for a release).