Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create single source of truth for version identifier #3136

Open
MicahGale opened this issue Sep 20, 2024 · 4 comments
Open

Create single source of truth for version identifier #3136

MicahGale opened this issue Sep 20, 2024 · 4 comments

Comments

@MicahGale
Copy link
Contributor

MicahGale commented Sep 20, 2024

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
Copy link
Contributor

gonuke commented Sep 20, 2024

  • @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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants