search

desihub / QuasarNP

Pure Numpy implementation of QuasarNet
MIT License
0 stars 0 forks source link

add __version__ string #5

Closed sbailey closed 3 years ago

sbailey commented 3 years ago

Please add a __version__ string so that future tags can use quasarnp.__version__ to record what version of QuasarNP was used. @dkirkby may have opinions about how that should be handled here.

dkirkby commented 3 years ago

The challenge of course is keeping git tags, setup.py and this file in synch: is there another pkg with a good solution to this we can mirror @sbailey?

weaverba137 commented 3 years ago

This package is now in the desihub group and is being added to the pipeline, therefore it should strictly follow the template set by other current packages, such as desispec, desitarget or desiutil.

dylanagreen commented 3 years ago

I can get on this, it may take a day or two to implement and check that it is working as intended. I will use desispec/desitarget/desiutil as a template to follow.

sbailey commented 3 years ago

Consider using desimeter/setup.py as the template to follow -- that will use desiutil for python setup.py version [--tag X.Y.Z] so that QuasarNP can be tagged following the procedures for the other desi packages (see https://desi.lbl.gov/trac/wiki/Computing/Software/Guidelines#CodeTags), while not requiring desiutil for other operations like installation, which may be desirable for this as a semi-independent package that doesn't otherwise have desi dependencies.

dylanagreen commented 3 years ago

I have added a version string in 3cf4f85af92, if so desired I can update the 0.1.0 tag to match this commit, which will ensure that installs of QuasarNP @ 0.1.0 will include the version string, or update the string to 0.1.1 and create a new tag to match. I'm not sure what the preferred solution in this case would be. @sbailey any preference? I'll close this issue once we have a decision.

dkirkby commented 3 years ago

I recommend creating a new 0.1.1 tag instead of modifying the commit associated with 0.1.0

dylanagreen commented 3 years ago

Closed with 64e7ff4.

sbailey commented 3 years ago

Thanks for adding the version string.

postfacto: I agree with @dkirkby about a new 0.1.1 tag instead of modifying the 0.1.0 tag (full disclosure: I modified the 0.1.0 installation at NERSC so that it would have a version string that I could use).

I recommend that after making a tag, you immediately update and recommit the version string to be something like 0.1.1.dev so that intermediate commits between 0.1.1 and the next tag don't inadvertently claim to be 0.1.1. e.g. the DESI tagging procedure boils down to:

  1. update change log and version string, commit
  2. make tag, push tag
  3. update version string to X.Y.Z.devNNNN, commit and push

the desiutil version infrastructure helps pick a unique NNNN so that you can additionally record interim devNNNN versions between tags, but in practice we rarely use that; the main point is to have something that distinguishes the interim state from actual tags.