Add isaaclab

[diegoferigo]

This PR adds a new conda-forge recipe for IsaacLab, a GPU-accelerated open-source framework designed to unify robotics research workflows such as reinforcement learning, imitation learning, and motion planning.

https://github.com/isaac-sim/IsaacLab

The recipe targets the upcoming 3.0 release, which represents a major refactor of the project. Key changes compared to previous versions:

• Support for the new Newton physics engine
  • Add newton #32314
• No longer requires Isaac Sim, which is not redistributable on conda-forge

Notes for reviewers:

• The project is large and modular.
• Some optional components have missing dependencies; this initial recipe includes as many as possible, with the remaining ones to be enabled in follow-up PRs.

---

Checklist

• Title of this PR is meaningful: e.g. "Adding my_nifty_package", not "updated meta.yaml".
• License file is packaged (see here for an example).
• Source is from official source.
• Package does not vendor other packages. (If a package uses the source of another package, they should be separate packages or the licenses of all packages need to be packaged).
• If static libraries are linked in, the license of the static library is packaged.
• Package does not ship static libraries. If static libraries are needed, follow CFEP-18.
• Build number is 0.
• A tarball (url) rather than a repo (e.g. git_url) is used in your recipe (see here for more details).
• GitHub users listed in the maintainer section have posted a comment confirming they are willing to be listed there.
• When in trouble, please check our knowledge base documentation before pinging a team.

[conda-forge-admin]

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

I wanted to let you know that I linted all conda-recipes in your PR (recipes/isaaclab/recipe.yaml) and found some lint.

Here's what I've got...

For recipes/isaaclab/recipe.yaml:

• ❌ The top level meta keys are in an unexpected order. Expecting ['schema_version', 'context', 'recipe', 'source', 'build', 'outputs', 'about', 'extra'].
• ❌ context.python_min has a value that is interpreted as a floating-point number. Please quote it (like "3.11") to ensure that it is interpreted as string and preserved exactly.

For recipes/isaaclab/recipe.yaml:

• ℹ️ It looks like the '???' output doesn't have any tests.
• ℹ️ It looks like the '???' output doesn't have any tests.
• ℹ️ It looks like the '???' output doesn't have any tests.
• ℹ️ It looks like the '???' output doesn't have any tests.
• ℹ️ It looks like the '???' output doesn't have any tests.
• ℹ️ It looks like the '???' output doesn't have any tests.
• ℹ️ It looks like the '???' output doesn't have any tests.
• ℹ️ It looks like the '???' output doesn't have any tests.
• ℹ️ It looks like the '???' output doesn't have any tests.
• ℹ️ It looks like the '???' output doesn't have any tests.
• ℹ️ It looks like the '???' output doesn't have any tests.
• ℹ️ It looks like the '???' output doesn't have any tests.
• ℹ️ It looks like the '???' output doesn't have any tests.
• ℹ️ It looks like the '???' output doesn't have any tests.
• ℹ️ It looks like the '???' output doesn't have any tests.
• ℹ️ It looks like the '???' output doesn't have any tests.
• ℹ️ Recipes should usually depend on matplotlib-base as opposed to matplotlib so that runtime environments do not require large packages like qt.
• ℹ️ No valid build backend found for Python recipe for package `` using pip. Python recipes using `pip` need to explicitly specify a build backend in the `host` section. If your recipe has built with only `pip` in the `host` section in the past, you likely should add `setuptools` to the `host` section of your recipe.
• ℹ️ No valid build backend found for Python recipe for package `` using pip. Python recipes using `pip` need to explicitly specify a build backend in the `host` section. If your recipe has built with only `pip` in the `host` section in the past, you likely should add `setuptools` to the `host` section of your recipe.
• ℹ️ No valid build backend found for Python recipe for package `` using pip. Python recipes using `pip` need to explicitly specify a build backend in the `host` section. If your recipe has built with only `pip` in the `host` section in the past, you likely should add `setuptools` to the `host` section of your recipe.
• ℹ️ No valid build backend found for Python recipe for package `` using pip. Python recipes using `pip` need to explicitly specify a build backend in the `host` section. If your recipe has built with only `pip` in the `host` section in the past, you likely should add `setuptools` to the `host` section of your recipe.
• ℹ️ No valid build backend found for Python recipe for package `` using pip. Python recipes using `pip` need to explicitly specify a build backend in the `host` section. If your recipe has built with only `pip` in the `host` section in the past, you likely should add `setuptools` to the `host` section of your recipe.
• ℹ️ No valid build backend found for Python recipe for package `` using pip. Python recipes using `pip` need to explicitly specify a build backend in the `host` section. If your recipe has built with only `pip` in the `host` section in the past, you likely should add `setuptools` to the `host` section of your recipe.
• ℹ️ No valid build backend found for Python recipe for package `` using pip. Python recipes using `pip` need to explicitly specify a build backend in the `host` section. If your recipe has built with only `pip` in the `host` section in the past, you likely should add `setuptools` to the `host` section of your recipe.
• ℹ️ No valid build backend found for Python recipe for package `` using pip. Python recipes using `pip` need to explicitly specify a build backend in the `host` section. If your recipe has built with only `pip` in the `host` section in the past, you likely should add `setuptools` to the `host` section of your recipe.
• ℹ️ No valid build backend found for Python recipe for package `` using pip. Python recipes using `pip` need to explicitly specify a build backend in the `host` section. If your recipe has built with only `pip` in the `host` section in the past, you likely should add `setuptools` to the `host` section of your recipe.
• ℹ️ No valid build backend found for Python recipe for package `` using pip. Python recipes using `pip` need to explicitly specify a build backend in the `host` section. If your recipe has built with only `pip` in the `host` section in the past, you likely should add `setuptools` to the `host` section of your recipe.

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

[github-actions]

Hi! This is the staged-recipes linter and your PR looks excellent! 🚀

[jeongseok-meta]

Hi @diegoferigo, thanks for starting the IsaacLab 3 kit-less recipe and documenting the missing optional dependencies.

I continued from your draft by cherry-picking your three commits with authorship preserved, then added a small follow-up cleanup commit on top. The continuation draft is #33296. Current changes there are limited to lint cleanup, switching to matplotlib-base, adding tests for the active outputs, adding myself as a co-maintainer, and validating that the active external dependency set now solves on conda-forge. I also verified that warp-lang (NVIDIA Warp) and newton already have conda-forge feedstocks.

I kept IsaacSim out of that draft because the redistributability concern discussed in #32468 still looks unresolved. Happy to defer to you if you prefer to keep this work on #32698 instead.

[diegoferigo]

Thanks for your contributions @jeongseok-meta! I'm still interested in moving this PR forward. It is not stale, I was mainly waiting for upstream updates. One open question for me is conda-forge policy around packaging projects that are still in beta. I initially expected a stable release around May, but based on my latest discussions with upstream developers, that now seems unlikely before late July or August.

In the meantime, I've been using a vendored recipe handled with pixi-build in my pixi projects (already including some of the fixes you contributed) so I can stay aligned with the latest upstream revisions. Given the revised timeline, packaging a pre-release may now be worth considering. That said, I would still prefer to wait for the next tagged release, since a few things have changed upstream, especially around subpackages. Adding subpackages to an existing feedstock is somewhat cumbersome because it requires going through conda-forge/admin-requests.

The current IsaacLab pinning situation is also not great for conda-forge, and I think that not even my relaxed pinning approach used here is the right long-term solution. Ideally, most dependencies should use >= constraints, with only targeted upper bounds where strictly necessary. I'm discussing this with upstream and encouraging them to move in that direction for future releases.

That said, I'd be very happy to co-maintain this recipe. We should just align on the remaining steps needed to finalize support. My preference would be to wait at least for the next beta release, but I don't feel strongly about that if conda-forge admins are comfortable starting with pre-release versions. WDYT?

[jeongseok-meta]

Thanks, that makes sense. I will defer to your original PR and stop pushing my continuation draft so this stays centered on your work. The commits in #33296 are available if any of the lint, test, or dependency cleanup is useful; happy to help cherry-pick pieces or review when you decide whether to wait for the next beta or proceed with the current prerelease.

[diegoferigo]

Thanks, I'll definitely cherry pick your last modifications. Would you still be interested in co-maintain the final feedstock?

[jeongseok-meta]

Would you still be interested in co-maintain the final feedstock?

Yes!

[jeongseok-meta]

Hi @diegoferigo, I did a fresh dependency-availability check while leaving this PR as the source of truth and not pushing to your branch.

The active kit-less dependency set looks better now than it did in March. On conda-forge, warp-lang >=1.12.0 now solves on linux-64/Python 3.11 (warp-lang 1.13.0), and newton, mujoco-warp, dex-retargeting, pink, daqp, hf-xet, and usd-exchange all exist. I also spot-checked solves with pixi exec for warp-lang>=1.12.0, for the newton/mujoco-warp/dex-retargeting/pink/daqp/usd-exchange/hf-xet group, and for the pinned pillow, transformers, and starlette constraints.

Still missing or version-limited from the commented optional paths: omniverseclient is not on conda-forge, nvidia-srl-usd-to-urdf is not on conda-forge, and robomimic is available only as 0.3.0 rather than the commented 0.4.0 requirement. Happy to help review or cherry-pick focused pieces from #33296 if/when that is useful.

[diegoferigo]

Thanks for the overview, @jeongseok-meta. I tried upgrading my prototyping kit-less environment to Newton 1.2 earlier this morning, and so far things are looking quite good.

My current plan is to get this PR into good shape by temporarily switching to the develop branch, with the goal of merging it alongside the next tagged beta release. I'll share an ETA as soon as I hear back from the upstream developers.

For the initial recipe version, I think requiring a manual installation of omniverseclient from PyPI is acceptable, since we cannot redistribute it regardless AFAIK. I also asked upstream whether it could be made an optional dependency given that it is only used to download a small set of assets that may not be needed by most users.

That would address the most critical issue, although I'm not sure yet what priority upstream is giving to that task.

[jeongseok-meta]

Thanks, that plan sounds good to me. I agree that omniverseclient should not be added as a conda runtime dependency if redistribution is not permitted; documenting that specific asset-download path as optional/manual PyPI setup, or keeping the recipe/tests away from importing that path, seems like the right initial shape. I will keep deferring to your PR as the source of truth and can help review or cherry-pick any focused pieces from #33296 when useful.

[conda-forge-admin]

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 (recipes/isaaclab/recipe.yaml) and found it was in an excellent condition.

[conda-forge-admin]

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 (recipes/isaaclab/recipe.yaml) and found it was in an excellent condition.

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

For recipes/isaaclab/recipe.yaml:

• ℹ️ It looks like the '???' output doesn't have any tests.

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

[diegoferigo-rai]

I created the following upstream PR with the first batch of updates. I tested these changes locally, and they allow us to remove most of the setup.py / __init__.py workarounds currently present in the recipe. The version pinning changes are more delicate, so I plan to address them in a follow-up PR.

• Modernize packaging and version management across sub-packages isaac-sim/IsaacLab#5640