-
Notifications
You must be signed in to change notification settings - Fork 503
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
Comments
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 Alternatively, if we use |
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 |
Yes I think a |
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:
Make the Python API "own" the version by embedding it in
pyproject.toml
oropenmc/__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.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
.Something else I missed.
Compatibility
This should be done in a way that is seamless to the user.
The text was updated successfully, but these errors were encountered: