Add from source wrapping by CavRiley · Pull Request #50 · conda-forge/itk-feedstock

CavRiley · 2026-05-25T16:26:53Z

Checklist

Used a personal fork of the feedstock to propose changes
Bumped the build number (if the version is unchanged)
Reset the build number to 0 (if the version changed)
Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
Ensured the license file is being packaged.

This PR adds a wrapping output to itk conda packaging (discussed in InsightSoftwareConsortium/ITKPythonPackage#302). This allows ITK remote modules to be packages as conda packages usable in Python conda environments.

I also experimented with using these conda packages as caches for building Python wheels for ITK. While this worked for mac and windows builds, to make manylinux compatible wheels, I believe the conda packages would need to be created within the manylinux docker environments with the correct compilers and toolchains (which may not be possible here).

Also experimented with inclusion of this in the libitk-feedstock but ended up moving the work here, seen in this PR.

conda-forge-admin · 2026-05-25T16:28:26Z

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found it was in an excellent condition.

I do have some suggestions for making it better though...

For recipe/meta.yaml:

ℹ️ The recipe is not parsable by parser conda-souschef (grayskull). This parser is not currently used by conda-forge, but may be in the future. We are collecting information to see which recipes are compatible with grayskull.
ℹ️ The recipe is not parsable by parser conda-recipe-manager. The recipe can only be automatically migrated to the new v1 format if it is parseable by conda-recipe-manager.
ℹ️ 'Free Disk Space' is deprecated.
Deprecated. Use workflow_settings.free_disk_space instead.
Free up disk space building.
The following components can be cleaned up: apt, cache, docker.
When set to true, only apt and cache are cleaned up.
Set it to the full list to clean up all components.

_{This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/27852953943. Examine the logs at this URL for more detail.}

blowekamp · 2026-06-08T23:08:00Z

@thewtex Can you approve the workflow runs for this PR?

thewtex · 2026-06-09T13:22:26Z

@blowekamp @CavRiley yes, triggered! ✨

CavRiley · 2026-06-09T15:30:03Z

@thewtex @blowekamp thank you!

FYI: the build process for these is successful on my forks GHAs but fail at validation due to the new itk-devel output and/or job timeouts.

blowekamp · 2026-06-09T15:51:18Z

@thewtex @blowekamp thank you!

FYI: the build process for these is successful on my forks GHAs but fail at validation due to the new itk-devel output and/or job timeouts.

Is the second package really needed?

Last time I added a second package I did this:
conda-forge/admin-requests#2070

CavRiley · 2026-06-09T16:10:49Z

Is the second package really needed?

Depends on the remote modules need or willingness to support conda environments. The second package only holds the build tree, so if the need is not there, then it can be removed

blowekamp · 2026-06-09T16:45:46Z

Is the second package really needed?

Depends on the remote modules need or willingness to support conda environments. The second package only holds the build tree, so if the need is not there, then it can be removed

Most modules are being moved to the main ITK repository right now. Unless you have an immediate need or application for itk-devel, I would delay added it.

Replace the PyPI wheel repackaging with a from-source ITK build that produces a self-contained `itk` package: the Python module plus the C++ runtime libraries it links against. Target Python 3.10, 3.11 and 3.12 across linux-64, linux-aarch64, osx-64, osx-arm64 and win-64.

…6.05.21.10.20.43

The from-source ITK build with Python wrapping fills the ~14 GB GitHub-hosted runner, so the test phase failed extracting the itk package with "No space left on device". Set github_actions.free_disk_space so the rerendered workflow reclaims runner space before building. Re-rendered.

The build requirement `cmake >=3.16.3, <3.30.0` had a space after the comma, which conda-build can misparse (treating `<3.30.0` as a build string). Use `cmake >=3.16.3,<3.30.0`.

Windows and macOS built on Azure-hosted agents (2 and 3 cores), where a full 2;3;4-dim ITK wrapping build did not finish within the 6 h job cap (Windows especially, on 2 cores). Route osx + win to GitHub Actions (windows-latest and macos-15-intel are 4 cores) so the builds fit the same 6 h limit with margin. Re-rendered.

osx_arm64 was cross-compiled on the osx_64 (Intel) runner via build_platform: osx_arm64: osx_64, which skips the arm64 tests and ignores GitHub's native Apple-Silicon runners. Build it natively on macos-latest (arm64) via provider: osx_arm64: github_actions, so the arm64 Python wrapping is import-tested on the target architecture. Re-rendered.

CavRiley · 2026-06-15T16:22:24Z

@thewtex We may need to request more CI compute resources on GHA or Azure runners (seen in conda-forge admin requests).

Also should consider which Python versions to target, or whether to build against the stable ABI mirroring the wheels.

blowekamp · 2026-06-15T16:58:56Z

@thewtex We may need to request more CI compute resources on GHA or Azure runners (seen in conda-forge admin requests).

Also should consider which Python versions to target, or whether to build against the stable ABI mirroring the wheels.

It look to me that the osx intel build is running on an OS ARM build. The emulation is slowing things down.

I am not sure how or if GHA can be configured to use the intel image.

CavRiley · 2026-06-15T17:47:34Z

+          - CONFIG: osx_64_python3.10.____cpython
+            STORE_BUILD_ARTIFACTS: False
+            UPLOAD_PACKAGES: True
+            os: macos
+            runs_on: ['macos-15-intel']


@blowekamp I would think this configuration enforces the intel runner image. But the Set up job step for the osx-64 jobs use the macos-15 image name. Is there a possibility that image name refer to both ARM and intel images?

Yes, I think you are correct.

I was looking for this string in the "Set up job" step in the action and didn't see it. Look again at the log, I don't see clear information about what the architecture is for the runner.

On line 732 of the "Build on macOS" step during conda configuration there is this line in a conda info call:

virtual packages : __archspec=1=skylake

As far as I know, the emulator would have reported an "M" architecture if emulated, but I could be wrong

blowekamp · 2026-06-15T19:12:58Z

With Mac OSX Tahoe 27, intel's are no longer supported. With this legacy configuration being the only one timing out perhaps this PR can move forward with out it?

CavRiley · 2026-06-15T19:27:08Z

With Mac OSX Tahoe 27, intel's are no longer supported. With this legacy configuration being the only one timing out perhaps this PR can move forward with out it?

I think that is reasonable.

@hjmjohnson may be able to provide an Intel mac as a self-hosted runner but I cannot confirm that.

thewtex · 2026-06-19T17:30:36Z

@thewtex We may need to request more CI compute resources on GHA or Azure runners (seen in conda-forge admin requests).

Also should consider which Python versions to target, or whether to build against the stable ABI mirroring the wheels.

@CavRiley yes, good ideas. These could be follow-up PR's. From your link, it looks like there may be self-hosted runners that may be useful.

It looks like osx_64 could be disabled by specifying build_platform in conda-forge.yml.

CavRiley added 6 commits June 9, 2026 18:51

MNT: Re-rendered with conda-smithy 3.61.2 and conda-forge-pinning 202…

9cf7034

…6.05.21.10.20.43

MNT: Fix cmake version spec spacing flagged by conda-forge linter

fdd6d6b

The build requirement `cmake >=3.16.3, <3.30.0` had a space after the comma, which conda-build can misparse (treating `<3.30.0` as a build string). Use `cmake >=3.16.3,<3.30.0`.

CavRiley force-pushed the add-from-source-wrapping branch from d67502d to 199a610 Compare June 9, 2026 23:52

CavRiley commented Jun 15, 2026

View reviewed changes

CavRiley marked this pull request as ready for review June 19, 2026 13:34

CavRiley requested a review from thewtex as a code owner June 19, 2026 13:34

CavRiley added 3 commits June 19, 2026 13:19

MNT: Cross-compile osx-64 on osx_arm64 runners

30a8605

BUG: Add osx-64 TryRunResults for cross-compile configure

2836284

MNT: Remove unused osx-arm64 TryRunResults (arm builds natively)

a809e83

Uh oh!

Conversation

CavRiley commented May 25, 2026

Uh oh!

conda-forge-admin commented May 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

blowekamp commented Jun 8, 2026

Uh oh!

thewtex commented Jun 9, 2026

Uh oh!

CavRiley commented Jun 9, 2026

Uh oh!

blowekamp commented Jun 9, 2026

Uh oh!

CavRiley commented Jun 9, 2026

Uh oh!

blowekamp commented Jun 9, 2026

Uh oh!

CavRiley commented Jun 15, 2026

Uh oh!

blowekamp commented Jun 15, 2026

Uh oh!

CavRiley Jun 15, 2026

Choose a reason for hiding this comment

Uh oh!

blowekamp Jun 15, 2026

Choose a reason for hiding this comment

Uh oh!

CavRiley Jun 15, 2026

Choose a reason for hiding this comment

Uh oh!

blowekamp commented Jun 15, 2026

Uh oh!

CavRiley commented Jun 15, 2026

Uh oh!

thewtex commented Jun 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

conda-forge-admin commented May 25, 2026 •

edited

Loading

thewtex commented Jun 19, 2026 •

edited

Loading