_version.py is being generated in the wrong place #1259

Closed
opened 2010-11-14 06:48:34 +00:00 by zooko · 1 comment

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.

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.
zooko added the
packaging
major
defect
1.8.0
labels 2010-11-14 06:48:34 +00:00
zooko added this to the 1.8.1 milestone 2010-11-14 06:48:34 +00:00
zooko@zooko.com commented 2010-11-14 08:07:32 +00:00
Owner

In changeset:e03206cbdf217893:

setup: specify that the version file must go into src/allmydata/_version.py . fixes #1259
In changeset:e03206cbdf217893: ``` setup: specify that the version file must go into src/allmydata/_version.py . fixes #1259 ```
tahoe-lafs added the
fixed
label 2010-11-14 08:07:32 +00:00
Sign in to join this conversation.
No Milestone
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Reference: tahoe-lafs/trac-2024-07-25#1259
No description provided.