Build pip wheel from existing source tree with ITKPythonPackage


I’ve searched but couldn’t find any answer matching what I’m after.

I’ve created a suite of docker containers, dash web apps, back-end processing services, clara framework workflows, jupyterlab servers which all use source builds of ITK combining some remote modules in addition to some of my own custom written external modules. Some of the containers also require python wrapping. The configuration is a bit non-standard as I make use of some GPU-enabled filters, Intel TBB and I need to python wrap a few more types and dimensions than the default.

Currently, I build and install everything fine in my “builder” container and then deploy the “build” to the other containers by copying the required files (headers, libs, help, etc) via dockerfile commands.

However, I would much prefer to build an internal use “wheel” (I only need a single flavor) in my builder container and then deploy this to all my containers that need a python enabled version of my full ITK environment. This way I would have a “properly” installed ITK package that pip knows about which doesn’t get clobbered by the public package when other packages get installed that also depend on ITK.

I’ve spent a couple of days fiddling around with ITKPythonPackage, cloning the repo into my builder container and trying to configure it to do what I want, but aren’t getting there.

Firstly, is it possible to get ITKPythonPackage to do what I want? I’m assuming it’s pretty much the analog of what you are doing for the nightly builds.

If so, can someone give me some pointers as to what I need to set, configure and execute to build a wheel and bundle the libs etc.

FYI, I’ve tried using the superbuild option and setting ITK_SOURCE_DIR and ITK_BINARY_DIR to a successfully built source tree but I’m not sure what to do next or to be honest what it is actually trying to do :slight_smile:

Any help achieving this would be much appreciated. If there is another way, I’d be interested in that too!


Darren Thompson

I am not sure whether regular build of ITK can include remote and external modules (@matt.mccormick knows). If not, you will need an additional step for each remote you want to make a wheel for. But just following the build instructions should get you there. If there are inconsistencies, missing steps etc please report them as an issue in that repo, or better yet as PRs fixing them.

Hi Darren,

Yes, the ITKPythonPackage repository should help you meet your goals.

Customize the build settings, other types, etc. here:

If you were just adding double support, note that that is enabled with itk-5.1.

Enabling remote modules may work, but that is untested. In addition to enabling the Module_<RemoteName> in the CMake configuration, add itk-remote here:

In either case, you can then generate the wheels by running,

./scripts/ cp38

if you are just targetting Python 3.8, for example.

Then, run,

cd ..

This generates a ITKPythonBuilds-linux.tar.zst file that can be used to build your additional external or remote modules. Unpack it in the remote or external module repository, then run ./ITKPythonPackage/scripts/ cp38, as outlined here:

The above script is used by GitHub Actions during remote module Python package builds.

Hope this helps,

1 Like

Thanks Matt, this was the sort of info I was looking for. The next complexity is that two of my external modules have CUDA as a dependency (and other less complicated things). All of my containers derive from an Ubuntu 18.04 + cuda 10 base image. If I am to use dockcross for compilation of ITK and the python modules - what is the best way to shoehorn CUDA into dockcross? Do I need to derive my own custom dockcross image or is it best to install the cuda sdk and other requirements via the script in ITKPythonPackage?

Thanks for getting back to me so quickly.


@darrent1974 yes, since you are already in Docker, it may be easier to forgo dockcross and just invoke bdist_wheel directly with your target Python and CMake flags, i.e. these calls:

Ok, thanks Matt I’ll give that a crack.

I was hoping you would suggest something of this sort. The dockcross path seemed like a bit of a rabbit hole.


1 Like