At 05:16 PM 6/28/2006 -0400, Jim Fulton wrote:

Interesting. I thought that --tag-svn-revision was a common/recommended practice.

It *is* -- but not for releases being sent to PyPI. a dev-rNNNN release is a development snapshot rather than an official release.

I followed the advice to have a setup.cfg like:

[egg_info] tag_build = .dev tag_svn_revision = 1

But I noticed that the release with the meta data didn't have the subversion information or the .dev tag, which is consistent with register not being aware of the extra information.

Is this a bug? :)

Probably. :) A workaround would be to either put "egg_info" before "register", or to move the "register" after the "bdist_egg". I'll add this to the bug list nonetheless.

If it isn't, then I recommend that you either stop recommending that people use setup.cfg this way or stop recommending that they upload their files to PyPI.

Do you really need to upload every development snapshot to PyPI? Common practice for the dev-rNNNN stuff is that you either remove it from setup.cfg when you create a release branch, or temporarily remove it when issuing a release snapshot. Admittedly, this procedure is awkward, and in 0.7 there will be some kind of options you can give to egg_info like --no-revision and --release-build to indicate that the svn revision and build tag should be omitted. The use in this case would be something like "setup.py egg_info --release-build --no-revision register bdist_egg upload" -- which of course you could create a shortcut for (using "setup.py alias"), maybe something like "release".

At 05:42 PM 6/28/2006 -0400, Jim Fulton wrote:

If I want people to be able to download it, I have to upload it somewhere.

Not necessarily. If you have a pure-Python package, and your target audience has Subversion, you can provide a URL on PyPI that always obtains the most recent possible development snapshot. For example, "easy_install setuptools==dev" will check out the setuptools trunk and install an egg from it, properly tagged as a development release with the subversion revision. "easy_install setuptools==dev06" will check out the head of the 0.6 maintenance branch. Of course, if you want to provide *built* daily snapshots, then this doesn't help you.

I have two choices, upload it to pypi, or create my own download area. I would do one or the other, not both. It seems confusing, to me and to consumers to have two download areas, my own and pypi's. I'd rather use PyPi's because it's integration with setup.py is so convenient.

OTOH, if it is considered bad form to upload dev releases to PyPi, I can just write helper scripts to upload somewhere else.

I don't know if there's a consensus that it's bad form. I do think that it would quickly become annoying to readers of Planet Python or even just the PyPI RSS feed if every Zope project was churning out snapshots of every SVN checkin, every day. :) As it is, there are lots of projects that churn their PyPI releases more often than I'd prefer to see going by, but ah well. Moderation in all things is best, I suppose. :) I won't say you *should* do one thing or the other, but I will note that the "rotate" command of setuptools is meant to help clean up directories containing automated nightly builds or svn snapshots. So, if you have servers whose job it is to do continuous builds, they can do stuff like "bdist_egg -b /output-dir rotate -k5 -m.egg -d /output-dir" to put the built egg in /output-dir and keep the 5 newest eggs. Several projects can safely share the same output directory, and the output directory doesn't need to be served by anything fancy; see e.g. http://peak.telecommunity.com/snapshots/ for an example of such a directory.

At 06:27 PM 6/28/2006 -0400, Jim Fulton wrote:

I didn't realize that this information was being broadcast. I imagine I am unintentionally annoying people with all of my experiments. :(

Don't worry about it; there's always a certain amount of release flutter taking place for other packages. It just takes a while to get the procedures down. I was more worried about the prospect of one release per commmit per project, or even daily snapshots of every project in Zope. :)

It isn't my intention to provide daily builds. I just happen wanted to make quick and dirty releases while stuff is new. These are like alpha release, but I'm leveraging the revision tagging to automate generation of release numbers.

Hm. Well, different strokes for different folks. I prefer to bump the alpha or beta number, since a short number is easier for humans to refer to; it's annoying to have to ask if someone has 0.6a9dev-r19684, versus something like 0.6a9snap3. The latter can be done with tag_build='snap3' in your setup.cfg, modulo the "register" issue we've already discussed. But of course your practices are up to you; I just mention this as an idea to make communications about your projects a little easier, at the cost of editing setup.cfg (or overriding --tag-build on the command line) when you do a release.

At 06:19 AM 6/29/2006 -0400, Jim Fulton wrote:

1. If I'm going to edit setup.cfg, I might as well edit setup.py

Note that you needn't edit anything if you use the --tag-build option, e.g.: python setup.py egg_info --tag-build=snap3 register sdist bdist_egg upload Assuming that setup.cfg normally contains: [egg_info] tag_build=dev and you're not using tag-svn-revision by default. In a future version of setuptools (maybe 0.6c1), there'll also be a command line option to turn *off* --tag-svn-revision.

2. A reason I want to automate this is a feat that I'll forget to edit setup.py or setup.cfg and overrite existing releases (or fail to do an update without realizing it because the existing release doesn't get overwritten.

Another issue is that I see us moving toward lots of fairly fine-grained packages and I want to keep the ceremony pretty low.

Yes, I once forgot to do this for setuptools itself, which is why I want options to remove the tags, then I can just add those notes to my release script. However, I also have an automated tool to do version edits across many files in a project. A simple ZConfig-based file describes what version numbers appear in what formats in what files, and is made executable via a #! line that runs a Python program that accepts various version-changing commands. I can run "./version incr build" to bump from 0.6a1 to 0.6a2, for example, or './version incr minor' to bump from 0.6 to 0.7. The tool then edits the relevant .py and .txt files, including setup.py itself. Here's the 'version' script for setuptools; it might give you some ideas for making a similar tool for Zope projects. You'll notice that it also edits my release.sh script, so that it knows what files it will be uploading to various servers... #!/usr/local/bin/invoke /usr/local/bin/c6peak version-config # This is a PEAK 'version' tool configuration file, that's # also executable. PJE uses it to bump version numbers in # the various parts of the project without having to edit them # by hand. The current version is stored in the version.dat # file. # These are not the droids you're looking for. You can go on # about your business... <Scheme default> DefaultFormat full part major part minor part status choice alpha beta "release candidate" final part build part date timestamp <Formats> trailer remap status "a%(build)s" "b%(build)s" "c%(build)s" "%(dot-maint)s" dot-maint optional build ".%(build)s" full "%(major)s.%(minor)s %(status)s %(build)s" short "%(major)s.%(minor)s%(trailer)s" </Formats> </Scheme> <Module> Name setuptools <Edit> File setup.py File ez_setup.py Match 'VERSION = "%(short)s"' </Edit> <Edit> File release.sh Match 'VERSION="%(short)s"' </Edit> <Edit> File setuptools/__init__.py Match "__version__ = '%(short)s'" </Edit> </Module>