Skip to content

improve version output

@gregory.ashton @rory-smith @avi.vajpeyi @moritz.huebner For a while I've noticed that the version outputs of bilby, bilby_pipe and parallel_bilby are confusing, because they always give the impression one is using a released version, even when one may in fact not be. For example, @marta.colleoni and others at UIB were just discussing version requirements with @isobel.romero-shaw who reported this output from parallel_bilby 1.0.0: (CLEAN) d9725af 2020-12-14 21:10:03 -0600. But if I go to https://git.ligo.org/lscsoft/parallel_bilby/-/tags/1.0.0 then that release tag in fact shows as 931c0aa8 (Nov 25, 2020) while the d9725af is actually a newer version. Similarly, if I grab today's bilby master, it outputs 1.1.2: (CLEAN) e9d72733 2021-05-20 03:02:01 +0000 but is actually 6 commits ahead of the 1.1.2 release (which was 678c4032).

I recommend moving these packages to using versioneer, which also has the nice side advantage that the package can be directly imported from the source tree without producing No version information file '.version' found errors. You can see how that package is used in https://git.ligo.org/lscsoft/pesummary which for example currently returns as a version string 0.12.1+1.g22cea6c where the +1 indicates it is 1 commit ahead of the last release. To further improve the output, you can also have a look at this small hack I did in PyFstat to clean it up, with an example output like v1.11.6+10.de5aef43.clean:

  • strip the confusing "g for git" it adds by default to the start of the hash (I always end up searching for that whole past-the-last-dot string in the version history, not finding it, getting confused, then remembering to strip the g)
  • increase to 8 chars to match gitlab default display
  • add ".clean" if so

(If you like keeping the commit date in the output, versioneer may have an option for that, but I haven't checked. In any case the most important is to make sure the user is clear about whether a tagged release or a different commit is used, and then extra info can always be found by following the commit hash.)