Open MicahGale opened 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.
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.
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
andCMakeLists.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:
pyproject.toml
oropenmc/__init__.py
, etc.Cmake
).version.txt
that both APIs must readMake it independent of both, but embedded in the git meta-data (i.e.,
git tag
).setuptools-scm
.CMake
. Though something likescikit-build
could handle that.git clone
.Compatibility
This should be done in a way that is seamless to the user.