Bug #3848
closed
[SDK] Python SDK should always set proper version when built from git
Description
One thing that would help debug Docker images is if the Arvados Python modules were installed with version numbers that match what we publish. Right now, they just use the plain string '0.1', which means you have to use other metadata to figure out the real version. It would be nice to build the packages with the same version information we use in production, so that pip freeze tells you at a glance what version you're running. See the setup.py egg_info command in Hacking Python SDK for a demonstration of how to do this.
This information would be useful in other contexts, too (i.e., "What version do I have on this development box?"). It might be worth investigating if there's a good way to put this information in setup.py. Note that simply appending the string like we do in our Gemfiles is not appropriate—that will cause setup.py to fail when it's run outside a git tree. Instead this would probably involve extending the egg_info command to look for git information and add it to the default version value.
Updated by Brett Smith over 10 years ago
- Subject changed from Docker images should install Python modules with proper versions to Docker images should install Python modules with proper version numbers
- Description updated (diff)
Updated by Ward Vandewege over 10 years ago
- Subject changed from Docker images should install Python modules with proper version numbers to [SDK] Docker images should install Python modules with proper version numbers
Updated by Ward Vandewege over 10 years ago
- Target version set to Arvados Future Sprints
Updated by Brett Smith over 10 years ago
- Subject changed from [SDK] Docker images should install Python modules with proper version numbers to [SDK] Python SDK should always set proper version when built from git
- Category set to SDKs
Discussed in sprint planning that we want to solve this at the SDK level; i.e., customize the egg_info command in setup.py as discussed in the description.
Updated by Brett Smith over 10 years ago
If this can be done by hooking into egg_info, it's 0.5 points. If it can't, it's 1.0, because you'll have to change the build process in other places like Jenkins.
Updated by Ward Vandewege over 10 years ago
- Target version changed from Arvados Future Sprints to 2014-10-08 sprint
Updated by Brett Smith about 10 years ago
- Status changed from New to In Progress
- Assigned To set to Brett Smith
Moved up in priority. Now that the FUSE driver has a dependency on a specific version of the SDK, it's even more important for developers to be able to get the right version easily.
Updated by Peter Amstutz about 10 years ago
My only comment is that maybe we should be using UTC for the timestamp? Otherwise LGTM.
Updated by Brett Smith about 10 years ago
Peter Amstutz wrote:
My only comment is that maybe we should be using UTC for the timestamp? Otherwise LGTM.
Implemented in 7aa4ca1. Updated the Ruby Gemspecs too, for consistency.
Updated by Peter Amstutz about 10 years ago
Brett Smith wrote:
Peter Amstutz wrote:
My only comment is that maybe we should be using UTC for the timestamp? Otherwise LGTM.
Implemented in 7aa4ca1. Updated the Ruby Gemspecs too, for consistency.
Just curious, what's the rationale for including the git hash in the python package version but not the gem version?
Otherwise looks good, please merge.
Updated by Brett Smith about 10 years ago
- Status changed from In Progress to Resolved
- % Done changed from 0 to 100
Applied in changeset arvados|commit:f1c20b66097f1bb37c0ffc8808b4a5831e91f87b.
Updated by Brett Smith about 10 years ago
Peter Amstutz wrote:
Just curious, what's the rationale for including the git hash in the python package version but not the gem version?
I don't know, that decision predates me. Maybe we usually want it but Ruby Gems don't like hex in the version number?
Merged, thanks.
Updated by Ward Vandewege about 10 years ago
The arvados-dev 3848-build-packages-pyversion branch looks good to me, I tested it and it does what is expected. Thanks!