COMP: Update the CI package dependancies.

[hjmjohnson]

No description provided.

[dzenanz]

LGTM, but Matt should review, too.

[hjmjohnson]

@thewtex -- @dzenanz requested your review.

[dzenanz]

Default here is _2_34

[dzenanz]

In readme we mention versions different from the default (_2_34). Is this intentional?

[hjmjohnson]

I don't understand how the readme is related to _2_34. Can the readme be simplified to avoid the bookkeeping overhead of keeping the code insync with the readme?

<< Warning rant begin >>

To be honest, I don't understand all the magic that's going on. I have been trying to get 1 PR for a remote module to pass CI, but after nearly a week of tracking down required changes across a maze of separate repos, and resources pulled from various branches (main/master, release, dashboard, or specific hashes), I'm getting to the end of my ability to provide more time trying to make this work.

I recognize the rational for not repeating code in separate packages, but I'm begining to believe that replication would be much easier to maintain than all the complex interactions between different repos that each require PR's to update and test. Additionally, trying to debug the CI failures is very confusing when the resources needed for a single CI run span many different repos. I have downloaded and learned several repos in the process so far.

I think debugging could be a lot easier if we inline the CI content into the packages that depend on them:
ITKClangFormatLinterAction
ITKApplyClangFormatAction

<< rant end >> :)

[dzenanz]

I have been following your efforts, and trying to support you. I gave SphinxExamples a shot on Friday, but gave up soon - so many moving pieces.

[dzenanz]

I understand your frustration. And I agree that "inlining" some of the things is less elegant, but would require less knowledge to maintain.

[hjmjohnson]

@dzenanz: Thank you for tolerating my rant above.

@thewtex @dzenanz @blowekamp I am going to "unravel and inline" the CI for InsightSoftwareConsortium/ITKLabelErodeDilate#40 (a simple case) and try to minimize the learning curve for maintaining the remote repositories.

AN OBSERVATION NOT A CRITIQUE: It is perfectly reasonable to request @thewtex to review, and it is perfectly reasonable to need to allow a week for that review to happen. However, that means that I can not proceed with the effort of pushing the project forward during my 1 free weekend this month.

Things I am going to try:

• Move config files needed by remote modules CI config into the ITK proper to minimize the number of hashes/branches/repos that need to be synchronously modified.
• Prefer diffing different remote .github/workflow/*.yml to syncronize rather than depending on dynamicly downloaded external resources.

[thewtex]

@hjmjohnson I understand your frustration. There is a lot of complexity. This naturally arises from the need to support ARM64, AMD64, MacOS, Linux, Windows, a stable version that most people are using in production to address a number of important real-world uses cases, and a development version where developers that make experimental improvements the long haul, and a GitHub infrastructure that we can all collaborate on. And we are continuously making strides to reduce that complexity as much as possible.

And consolidation of some configuration files in the ITK repository could be a good step forward, where that makes sense.

However, please do not go about breaking existing infrastructure that does work.

This will slow you down much more and it slows everyone else down, too. Burning everything down due to frustration with the status quo is not a recipe to make progress better or faster.

[dzenanz]

Trying to use this here, I run into:

Run sudo xcode-select -s "/Applications/Xcode_15.0.1.app"
  sudo xcode-select -s "/Applications/Xcode_15.0.1.app"
  shell: /bin/bash -e {0}
xcode-select: error: invalid developer directory '/Applications/Xcode_15.0.1.app'
Error: Process completed with exit code 1.

and into:

HEAD is now at ca1a7e5 ENH: Only extract required directories from the ITKPythonBuilds tar
HEAD detached at ca1a7e5
nothing to commit, working tree clean
~/work/ITKMontage/ITKMontage
ERROR: can not find required binary './ITKPythonPackage/scripts/dockcross-manylinux-build-module-wheels.sh'
Building module wheels
./dockcross-manylinux-download-cache-and-build-module-wheels.sh: line 76: ./ITKPythonPackage/scripts/dockcross-manylinux-build-module-wheels.sh: No such file or directory
Error: Process completed with exit code 127.

[thewtex]

We should use a tagged, tested version on master.

[thewtex]

@hjmjohnson I understand your frustration. There is a lot of complexity. This naturally arises from the need to support ARM64, AMD64, MacOS, Linux, Windows, a stable version that most people are using in production to address a number of important real-world uses cases, and a development version where developers that make experimental improvements the long haul, and a GitHub infrastructure that we can all collaborate on. And we are continuously making strides to reduce that complexity as much as possible.

And consolidation of some configuration files in the ITK repository could be a good step forward, where that makes sense.

However, please do not go about breaking existing infrastructure that does work.

This will slow you down much more and it slows everyone else down, too. Burning everything down due to frustration with the status quo is not a recipe to make progress better or faster.