feat: add conda recipe for houdini 22.0

[kenyrish-amazon]

What was the problem/requirement? (What/Why)

There is no sample conda recipe for Houdini 22.0. The newest Houdini application recipe in this directory is houdini-21.0.

What was the solution? (How)

Adds conda_recipes/houdini-22.0, following the structure of the existing houdini-21.0 recipe: the same six files, the same rattler-build recipe shape, and the same Plugin Sync support.

Two things genuinely differ for Houdini 22.0 rather than being copied over:

• GCC 14.2. Houdini 22.0 archives are built with GCC 14.2, where 21.0 and earlier used GCC 11.2, so the source archive filename differs (houdini-22.0.368-linux_x86_64_gcc14.2.tar.gz).
• libatomic. The 22.0 installer needs libatomic from the system package manager, in addition to the dependencies 21.0 required.

Source is read from archive_files with a sha256, matching houdini-20.5, houdini-redshift-2026, houdini-vray-7, blender-4.4 and maya-2025, so that the documented step of placing the downloaded archive in conda_recipes/archive_files works as written.

What is the impact of this change?

Adds a new sample recipe. No existing files are modified.

How was this change tested?

Built and verified end-to-end on a Deadline Cloud package build queue (linux-64).

• Build + package: ./submit-package-job houdini-22.0 builds cleanly — Houdini installs (68,510 files, 6.67 GiB) and the .conda is produced and published to the channel.
• Install + run: a consuming job installed houdini=22.0.* from the channel and ran hython, which reported 22.0.368, then cooked a Geometry ROP to completion.
• Karma render: a second consuming job used the built package to render a USD/Karma ROP (/out/karma1/rop_usdrender) from a test scene, producing the expected image. Karma is Houdini's built-in renderer, so it is exercised by the base houdini package with no additional recipe (unlike Redshift or V-Ray, which have their own recipes).

Checklist

• Recipe changes use rattler-build recipe.yaml format (not conda-build meta.yaml)
• Build number bumped in recipe.yaml for any modified existing version — n/a, new version so build number is 0
• New packages are added to gates.json for the appropriate stage/platform — n/a, samples repo has no gates.json
• Source artifacts are uploaded (or acquisition is configured in deadline-cloud.yaml) — read from archive_files per the documented download step
• Test bundles exist for new packages/versions — verified via a consuming install+render job

[github-actions]

$HOME/houdini22.0/packages is a host-wide shared location, but this script writes into it per session. Two sessions running concurrently on the same worker (same HOME) will interfere:

• both copy .json files into the same directory, so a later cp clobbers the earlier one (different plugin content, same basename);
• whichever session deactivates first rm -fs the package files by name (per the manifest), pulling them out from under the still-running session, which then silently loses its plugins.

Houdini honours HOUDINI_PACKAGE_DIR (colon-separated list of package directories), so a session-scoped directory avoids the shared-state entirely, e.g. write the .json files into $_SP_PLUGIN_DIR/packages and export HOUDINI_PACKAGE_DIR="$_SP_PLUGIN_DIR/packages${HOUDINI_PACKAGE_DIR:+:$HOUDINI_PACKAGE_DIR}". That also makes the deactivate script a single rm -rf with no manifest bookkeeping.

[github-actions]

missing_dso_allowlist: ["**"] disables every linkage check, and there is no tests: section, so a package with unresolvable shared libraries will build and publish cleanly and only fail on the farm. That risk is concrete here: 22.0 needed libatomic added to the dnf download list precisely because of a missing DSO.

The houdini-20.5 recipe guards against this with a smoke test that would have caught it:

tests:
  - script:
      - houdini -h
      - hython -h

Worth adding (or narrowing the allowlist to the DSOs that are genuinely expected to be resolved at runtime rather than **).

[github-actions]

The new recipe is not added to the recipe index in conda_recipes/README.md. That table lists Houdini 20.5, 21.0, and the Redshift/V-Ray plugin recipes, and the repository checklist requires updating the nearest category table when a sample is added. Suggested row, next to the 21.0 entry:

| [Houdini 22.0](houdini-22.0/) | Packaging Houdini 22.0 with Plugin Sync activation | Your jobs require Houdini 22 or frequently updated plugins |

Without it the sample is undiscoverable from the collection README.

[github-actions]

Generic plugins are downloaded but never made visible to Houdini, and never cleaned up.

$_SP_GENERIC_DIR (.../deadline-plugins/generic) is populated from s3://.../plugins/generic/, but after that it is used nowhere: the .json scan on line 44 iterates "$_SP_PLUGIN_DIR"/*.json only, DEADLINE_CLOUD_HOUDINI_PLUGIN_SYNC_DIR is exported as the Houdini dir only, and the deactivate script only does rm -rf "$DEADLINE_CLOUD_HOUDINI_PLUGIN_SYNC_DIR" — so the generic tree is left on disk. A customer who uploads a cross-DCC plugin under plugins/generic/ gets a silent no-op (the S3 transfer cost and log lines suggest it worked). Compare conda_recipes/cinema4d-2026/recipe/zzz-cinema4d-plugin-sync-activate.sh, which folds the generic dir into g_additionalModulePath alongside the DCC dir.

Either scan both directories for package .json files, e.g.

for _sp_json_file in "$_SP_PLUGIN_DIR"/*.json "$_SP_GENERIC_DIR"/*.json; do

(and export the generic path too, so descriptors can reference it), or drop the generic download block entirely rather than paying for a transfer whose result is unreachable.