-
Notifications
You must be signed in to change notification settings - Fork 11
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
Versioning scheme #6
Comments
Cc: @blowekamp |
I am a big fan of SimpleITK's automatic generation of PEP 440 version tag based on SimpleITK's repo. This creates a version which defines a location anywhere in the next, master or release branches. However, if this python packaging system does not readily support building an arbitrary spot in the SimpleITK repo then there is no need for that fancyness, and a more manual tag could be done. If it's a manually updated version, then how can nightly, or development packages be created? |
This is great. The python-versioneer allow to generate package compliant with PEP-440 very easily. Additionally, when the package is built from the source distribution (which is a tar.gz archive that is not associated with a git checkout), the correct version information are also available. It can be configured quite easily with a adding few line of config to The different versioning scheme are detailed here This approach means that the versioning of the wheels will be based on the tag associated with Let me know what you think. |
There is some really great stuff to already do this in SimpleITK: What I'd ideally like to see is some file similar to "cmake/_version.py" make some CMake call to run CMake script ( https://github.com/SimpleITK/SimpleITK/blob/master/Version.cmake ), to get the SimpleITK defined versions. The propagate those to the Python Packaging. Does scikit-build provide a way to call execute CMake? And a way to exchange variables? |
Makes sense. We could then use all the logic of python-versioneer and plug the SimpleITK custom implementation in a file named
Not yet. That said, similarly to cmaker.configure, we could add a
What do you exactly mean by "exchange" ? |
By "exchange" I mean a general term for some type of information transfer between the python code and the CMake code. This could take the form of arguments to CMake, and returned values form the CMake process. This could be the python code produced command line arguments for the CMake script execution from python argument, and python has the ability to read a CMakeCache style file? Or maybe CMake produces python code which gets executed? I method for communicated this information back and forth is useful, and it would be good to have some abstraction on this. This abstraction I think is useful and generic. For reference here is a produced generated sitkSourceVersionVars.cmake, based on introspection of the git repository. It is generated based solely on the git repo and tags: set( _GIT_VERSION_MAJOR "0" ) This is then combined with manual configured info here: I suspect ff we can get the values of the CMake variables matching |
Moving forward, few options:
For a simple example, see scikit-build/scikit-ci@01987f0
The text was updated successfully, but these errors were encountered: