setup.cfg considered harmful

June 5, 2008

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).


5 Responses to “setup.cfg considered harmful”

  1. +1 – let’s fix it. Bring it up on the product-developers list and I’m sure Tarek will be on it. 🙂

    I also think ZopeSkel needs to ask fewer questions in some places, and have more sensible defaults.

    FWIW, I use a script ( to release an egg quickly. It deletes setup.cfg. 😉


  2. Hi Philipp,

    -1 on removing the setup.cfg

    Using setup.cfg is perfectly fine, and does not cost more that your release procedure. Marking the dev tag in the .cfg instead of the is perfectly OK.

    I don’t see it as a problem. Anyone is able to mess up a release, by ommiting the dev tag, no matter where it is located. And having it in setup.cfg allows us to do continous releases on our private servers (don’t be PyPI centric on this)

    Furthermore, we have a release procedures as well, wich can automatically be run by collective.release for example, that adds a ‘release’ command:

    $ cd my.package
    $ python release

    And it takes care of everything (creates the tag, change the and setup.cfg files)
    as long as it is in subversion, with a tags/branches/trunk tree


  3. philikon Says:

    If you have a release command that does all this, sure, why not. But then you don’t need setup.cfg, you could have the release command pass in those options as parameters. Either way, other people who try out ZopeSkel don’t necessarily know about this command. I didn’t :). And if I didn’t know about setup.cfg, I would have to look up where I can switch off this stupid dev-rXXXX suffix to my revision number.

    I’m actually not complaining about setup.cfg itself, I’m complaining about the default contents that ZopeSkel generates. This isn’t about whether you can use setup.cfg to set certain options, such as alternative PyPI servers (which you can also configure using command line arguments, I think). It’s about sensible defaults. Continuous releases have caused so much pain in Zope’s eggification, I think it’s safe to say they’re dangerous. In fact, I think they’re an oxymoron. Either you deploy from a development branch (you could also fix the revision of the checkout) or you deploy from a release. Pick one and live with your decision.

  4. Ian Bicking Says:

    Pick which one? I always install both. I install the trunk during development, then releases later. I agree that it’s rather opaque how the version is calculated, and probably some comments should be added to both and setup.cfg to improve this. But I think the idea is right, and that the default setup should work like that.

  5. Deploying from development branches would be easier if more packages linked to their svn server from their homepage. If you’re using pypi as the homepage, add something like this to your long_description:

    `SVN version <svn://;`_.


    (hopefully this fixes the quoting)

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: