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

Versioning scheme #6

Open
jcfr opened this issue Nov 15, 2016 · 6 comments
Open

Versioning scheme #6

jcfr opened this issue Nov 15, 2016 · 6 comments

Comments

@jcfr
Copy link
Collaborator

jcfr commented Nov 15, 2016

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 scikit-build/scikit-ci@01987f0

@jcfr
Copy link
Collaborator Author

jcfr commented Nov 15, 2016

Cc: @blowekamp

@blowekamp
Copy link
Member

blowekamp commented Nov 15, 2016

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?

@jcfr
Copy link
Collaborator Author

jcfr commented Jan 19, 2017

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 jcfr added the question label Jan 19, 2017
@blowekamp
Copy link
Member

blowekamp commented Jan 19, 2017

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?

@jcfr
Copy link
Collaborator Author

jcfr commented Jan 19, 2017

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" ?

@blowekamp
Copy link
Member

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.

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

No branches or pull requests

2 participants