SimpleITKPythonPackage icon indicating copy to clipboard operation
SimpleITKPythonPackage copied to clipboard

Versioning scheme

Open jcfr opened this issue 9 years ago • 6 comments

Moving forward, few options:

  1. use Version.cmake and integrate code that was in setup.py.in
  2. for each SimpleITK release, add similar tag to this repo and use https://github.com/warner/python-versioneer. and if the version need to be generated based on the source of SimpleITK, we could tweak versionner to do so.

For a simple example, see https://github.com/scikit-build/scikit-ci/commit/01987f08a30b94469021b1b5bc93fb981bc5b62e

jcfr avatar Nov 15 '16 20:11 jcfr

Cc: @blowekamp

jcfr avatar Nov 15 '16 20:11 jcfr

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?

blowekamp avatar Nov 15 '16 21:11 blowekamp

I am a big fan of SimpleITK's automatic generation of PEP 440 version tag based on SimpleITK's repo.

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 setup.cfg, here is an example.

The different versioning scheme are detailed here

This approach means that the versioning of the wheels will be based on the tag associated with SimpleITK/SimpleITKPythonPackage repository. Nothing prevent the tag associated with this project to match the one associated with upstream SimpleITK. That way the generated wheels will have the same major/minor/patch version.

Let me know what you think.

jcfr avatar Jan 19 '17 04:01 jcfr

There is some really great stuff to already do this in SimpleITK: https://github.com/SimpleITK/SimpleITK/blob/master/CMake/sitkSourceVersion.cmake https://github.com/SimpleITK/SimpleITK/blob/master/CMake/sitkSourceVersionVars.cmake.in

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?

blowekamp avatar Jan 19 '17 16:01 blowekamp

see is some file similar to "cmake/_version.py" make some CMake call to run CMake script

Makes sense. We could then use all the logic of python-versioneer and plug the SimpleITK custom implementation in a file named SimpleITK/_version.py

Does scikit-build provide a way to call execute CMake?

Not yet. That said, similarly to cmaker.configure, we could add a cmaker.run method ...

And a way to exchange variables?

What do you exactly mean by "exchange" ?

jcfr avatar Jan 19 '17 18:01 jcfr

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: `macro( _set_if_not_empty var value ) if( NOT "${value}" STREQUAL "" ) set( ${var} "${value}" ) endif() endmacro()

set( _GIT_VERSION_MAJOR "0" ) set( _GIT_VERSION_MINOR "10" ) _set_if_not_empty( _GIT_VERSION_PATCH "0" ) _set_if_not_empty( _GIT_VERSION_TWEAK "" ) _set_if_not_empty( _GIT_VERSION_RC "" ) _set_if_not_empty( _GIT_VERSION_POST "" ) _set_if_not_empty( _GIT_VERSION_DEV "200" ) _set_if_not_empty( _GIT_VERSION_HASH "78a4f" )`

This is then combined with manual configured info here: https://github.com/SimpleITK/SimpleITK/blob/master/Version.cmake https://github.com/SimpleITK/SimpleITK/blob/ec23b1a8efe86da1bbd4fc5d206df3cbc18893bd/CMakeLists.txt#L23-L50

I suspect ff we can get the values of the CMake variables matching SimpleITK_VERSION_* over to python and into versioner thing should work nicely.

blowekamp avatar Jan 23 '17 15:01 blowekamp