openmc-dev
Create single source of truth for version identifier
Description
This is a continuation of a discussion with @ahnaf-tahmid-chowdhury and @gonuke on slack. Right now version information is stored in pyproject.toml and CMakeLists.txt. This is a very error prone system that will likely lead to disagreement on what version someone is actually using, and so going to a single source of truth is very desirable.
Alternatives
Broadly there seems to be a few broad categories of how to approach this problem:
-
Make the Python API "own" the version by embedding it in
pyproject.tomloropenmc/__init__.py, etc. -
Make the C++ API "own" it by embedding it in the C source code (or
Cmake). -
Make it independent of both and be file based. For example have a
version.txtthat both APIs must read -
Make it independent of both, but embedded in the git meta-data (i.e.,
git tag).- On the python side there is
setuptools-scm. - It is unclear to me if a similar option to this exists for
CMake. Though something likescikit-buildcould handle that. - @gonuke brought up the fact that this would break the versioning for people who download a tar ball of the repo and then build from source. I'm skeptical that there is a large overlap of people building from source, who also don't just
git clone.
- On the python side there is
-
Something else I missed.
Compatibility
This should be done in a way that is seamless to the user.
- @gonuke brought up the fact that this would break the versioning for people who download a tar ball of the repo and then build from source. I'm skeptical that there is a large overlap of people building from source, who also don't just
git clone.
Just because it's rare doesn't mean it's unimportant. One solution is to populate this in some way upon release in the Zip file that is distinct from a largely automated process for other pathways.
Adding my suggestions from the slack channel to here as well.
If we consider using setuptools-scm for the python side, we could run an execute_process command in CMake to get the git tag name and store the value in a variable, or leverage this CMakeExtraUtils.
Alternatively, if we use scikit-build-core, we can utilize the SKBUILD_PROJECT_VERSION variable in CMake.
Another option is to extract the version using regex from a file into CMakeLists.txt or pyproject.toml. We've implemented a similar method in MOAB, where the version is set in CMake and extracted into pyproject.toml via regex.
We could also still use setup.py solely for retrieving the version from __init__.py.
After considering all the options, and since we are planning not to rely on git tags, I believe the best option would be to create a version.txt file and store it in the tools folder. This way, all the build scripts can use that file to obtain version information. Again, if there are any auxiliary files that rely on the version, we can create a method for that as well. Currently, in PyNE, we are planning to use this approach to handle the situation.
Yes I think a version.txt file would be best. In openmc/__init__.py we could read that file into __version__, and then in pyproject.toml point to that with dynamic versioning. I'm not sure how to implement this on the Cmake side though.