openmc-dev / openmc

OpenMC Monte Carlo Code
https://docs.openmc.org
Other
767 stars 493 forks source link

Create single source of truth for version identifier #3136

Open MicahGale opened 1 month ago

MicahGale commented 1 month ago

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:

  1. Make the Python API "own" the version by embedding it in pyproject.toml or openmc/__init__.py, etc.
  2. Make the C++ API "own" it by embedding it in the C source code (or Cmake).
  3. Make it independent of both and be file based. For example have a version.txt that both APIs must read
  4. 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 like scikit-build could 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.
  5. Something else I missed.

Compatibility

This should be done in a way that is seamless to the user.

gonuke commented 1 month ago
  • @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.

ahnaf-tahmid-chowdhury commented 1 month ago

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.

ahnaf-tahmid-chowdhury commented 1 month ago

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.

MicahGale commented 1 month ago

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.