id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc	launchpad_bug
1259	_version.py is being generated in the wrong place	zooko	zooko	"The buildbot clearly told us that something was wrong with [changeset:59dcd5014dcb440a] when every builder went red. I really couldn't figure out how the patch, which didn't touch any of the tahoe-lafs code ''or'' any of the setup script code could possibly cause this problem.

After much head-scratching I realized that I was looking at the consequences of my own decision to make {{{darcsver}}} too clever by half almost three years ago:

http://tahoe-lafs.org/trac/darcsver/browser/trunk/darcsver/setuptools_command.py?annotate=blame&rev=109#L74

If the user of {{{darcsver}}} (which is in this case the tahoe-lafs setup.py) doesn't specify into what file(s) the resulting version number should go, then {{{darcsver}}} will guess about where it should go. Before [changeset:59dcd5014dcb440a], {{{darcsver}}} was guessing correctly by noticing that all of the contents of the {{{allmydata-tahoe}}} package (""distribution"") came from a directory named {{{src/allmydata/}}}, so it decided to put the version number into {{{src/allmydata/_version.py}}}. After [changeset:59dcd5014dcb440a], it now guesses it should put the version number into {{{src/_version.py}}} instead since [changeset:59dcd5014dcb440a] added some files in a new directory named {{{src/buildtest/}}} which is outside of {{{src/allmydata/}}}.

I'm pretty sure the best fix for this is to make the tahoe-lafs setup.py explicitly specify which file the version number should go into.

In addition, I should probably consider removing the magical cleverness from darcsver so that users who don't bother to specify a filename get a runtime failure instead of a good guess."	defect	closed	major	1.8.1	packaging	1.8.0	fixed	packaging setuptools darcs