Build pip wheel from existing source tree with ITKPythonPackage

darrent1974 · June 15, 2020, 10:02am

Hi,

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

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

Regards,

Darren Thompson

dzenanz · June 15, 2020, 2:02pm

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.

matt.mccormick · June 15, 2020, 2:59pm

Hi Darren,

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

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

github.com

InsightSoftwareConsortium/ITKPythonPackage/blob/88d65caabf3ce82ff69fed98bdd15895e5b3f773/scripts/internal/manylinux-build-wheels.sh#L86-L135


      
          mkdir -p ${build_path} \
          && cd ${build_path} \
          && cmake \
            -DCMAKE_BUILD_TYPE:STRING=${build_type} \
            -DITK_SOURCE_DIR:PATH=${source_path} \
            -DITK_BINARY_DIR:PATH=${build_path} \
            -DBUILD_TESTING:BOOL=OFF \
            -DPython3_EXECUTABLE:FILEPATH=${Python3_EXECUTABLE} \
            -DPython3_INCLUDE_DIR:PATH=${Python3_INCLUDE_DIR} \
            -DCMAKE_CXX_COMPILER_TARGET:STRING=$(uname -p)-linux-gnu \
            -DCMAKE_CXX_FLAGS:STRING="$compile_flags" \
            -DCMAKE_C_FLAGS:STRING="$compile_flags" \
            -DCMAKE_BUILD_TYPE:STRING="${build_type}" \
            -DWRAP_ITK_INSTALL_COMPONENT_IDENTIFIER:STRING=PythonWheel \
            -DWRAP_ITK_INSTALL_COMPONENT_PER_MODULE:BOOL=ON \
            -DITK_WRAP_unsigned_short:BOOL=ON \
            -DITK_WRAP_double:BOOL=ON \
            -DPY_SITE_PACKAGES_PATH:PATH="." \
            -DITK_LEGACY_SILENT:BOOL=ON \
            -DITK_WRAP_PYTHON:BOOL=ON \

This file has been truncated. show original

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:

github.com

InsightSoftwareConsortium/ITKPythonPackage/blob/master/scripts/WHEEL_NAMES.txt

itk-core
itk-numerics
itk-io
itk-filtering
itk-registration
itk-segmentation
itk-meta

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

./scripts/dockcross-manylinux-build-wheels.sh cp38

if you are just targetting Python 3.8, for example.

Then, run,

cd ..
./ITKPythonPackage/scripts/dockcross-manylinux-build-tarball.sh

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/dockcross-manylinux-build-module-wheels.sh cp38, as outlined here:

github.com

InsightSoftwareConsortium/ITKPythonPackage/blob/master/scripts/dockcross-manylinux-download-cache-and-build-module-wheels.sh

#!/bin/bash

########################################################################
# Pull this script and run from an ITK external module root directory
# to generate the Linux Python wheels for the external module.
#
# ========================================================================
# PARAMETERS
#
# Versions can be restricted by passing them in as arguments to the script
# For example,
#
#   scripts/dockcross-manylinux-build-module-wheels.sh cp39
#
# ===========================================
# ENVIRONMENT VARIABLES
#
# These variables are set with the `export` bash command before calling the script.
# For example,
#

This file has been truncated. show original

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

Hope this helps,
Matt

darrent1974 · June 16, 2020, 3:38am

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 manylinux-build-wheels.sh script in ITKPythonPackage?

Thanks for getting back to me so quickly.

Darren

matt.mccormick · June 17, 2020, 1:26am

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

github.com

InsightSoftwareConsortium/ITKPythonPackage/blob/88d65caabf3ce82ff69fed98bdd15895e5b3f773/scripts/internal/manylinux-build-wheels.sh#L39


# Compile wheels re-using standalone project and archive cache
for PYBIN in "${PYBINARIES[@]}"; do
    export Python3_EXECUTABLE=${PYBIN}/python3
    Python3_INCLUDE_DIR=$( find -L ${PYBIN}/../include/ -name Python.h -exec dirname {} \; )

    echo ""
    echo "Python3_EXECUTABLE:${Python3_EXECUTABLE}"
    echo "Python3_INCLUDE_DIR:${Python3_INCLUDE_DIR}"

    # Install dependencies
    ${PYBIN}/pip install --upgrade -r /work/requirements-dev.txt

    build_type=""
    compile_flags="-O2 -DNDEBUG"
    source_path=/work/ITK-source/ITK
    build_path=/work/ITK-$(basename $(dirname ${PYBIN}))-manylinux1_${ARCH}
    SETUP_PY_CONFIGURE="${script_dir}/../setup_py_configure.py"
    SKBUILD_CMAKE_INSTALL_PREFIX=$(${Python3_EXECUTABLE} -c "from skbuild.constants import CMAKE_INSTALL_DIR; print(CMAKE_INSTALL_DIR)")

    # Clean up previous invocations
    rm -rf ${build_path}

github.com

InsightSoftwareConsortium/ITKPythonPackage/blob/88d65caabf3ce82ff69fed98bdd15895e5b3f773/scripts/internal/manylinux-build-wheels.sh#L58-L74


${PYBIN}/python ${SETUP_PY_CONFIGURE} "itk"
# Generate wheel
${PYBIN}/python setup.py bdist_wheel -G Ninja -- \
      -DITK_SOURCE_DIR:PATH=${source_path} \
      -DITK_BINARY_DIR:PATH=${build_path} \
      -DITKPythonPackage_ITK_BINARY_REUSE:BOOL=OFF \
      -DITKPythonPackage_WHEEL_NAME:STRING="itk" \
      -DITK_WRAP_unsigned_short:BOOL=ON \
      -DITK_WRAP_double:BOOL=ON \
      -DCMAKE_CXX_COMPILER_TARGET:STRING=$(uname -p)-linux-gnu \
      -DCMAKE_CXX_FLAGS:STRING="$compile_flags" \
      -DCMAKE_C_FLAGS:STRING="$compile_flags" \
      -DCMAKE_BUILD_TYPE:STRING="${build_type}" \
      -DPython3_EXECUTABLE:FILEPATH=${Python3_EXECUTABLE} \
      -DPython3_INCLUDE_DIR:PATH=${Python3_INCLUDE_DIR} \
      -DITK_WRAP_DOC:BOOL=ON \
      -DDOXYGEN_EXECUTABLE:FILEPATH=/work/tools/doxygen-1.8.11/bin/doxygen

darrent1974 · June 17, 2020, 1:30am

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.

Darren