I originally planned to develop on native Ubuntu, but per a decision from my company, I’m currently developing on Windows 11 instead. The switch to a native Linux environment is planned for later, only if it turns out to be truly necessary.
The issue I’m stuck on is which ROS2 setup to use on Windows 11. I see two options:
WSL2 + Ubuntu 24.04 + ROS2 Jazzy
Native Windows + Pixi-based ROS2 Jazzy
From what I’ve found, WSL2 is now marked as deprecated in recent documentation, while native Pixi doesn’t support Docker, custom ROS message interfaces, or Isaac ROS (GPU-accelerated perception nodes). So each option has its own drawback.
Rather than “use this for learning, then switch to something else once the real project starts,” I’d like to commit to one environment from the start and stick with it all the way through.
The project is a Real-to-Sim training pipeline built on Isaac Sim/Isaac Lab, and there’s a reasonable chance I’ll need Docker workflows, custom ROS interfaces, or GPU-accelerated perception nodes down the line. Given that, I’d appreciate your recommendation on whether WSL2 or native Pixi is the better call.
Based on the title and content of your topic, it looks like it may receive better visibility and feedback in a different category. We took the liberty of moving it for you.
If this was an incorrect assessment, please send me a direct message.
Disclaimer: this moderation suggestion and message were generated with AI assistance.
Hi @jskg9400, you’ve done a good job mapping out the trade-offs already – let me fill
in the gaps from the official docs and give you a direct recommendation.
“Deprecated” for WSL2 does not mean broken. It means NVIDIA is no longer actively
improving the WSL2 ROS bridge path – Pixi is now the preferred method for
Windows + Isaac Sim ROS 2 integration. The WSL2 approach still works (Isaac Sim runs
natively on Windows with its internal ROS 2 libraries; WSL2 runs the ROS nodes; they
communicate via DDS port forwarding), but NVIDIA is not adding new features to it.
Custom ROS interfaces are not supported on either Windows path. This is a
fundamental Windows limitation, not a Pixi vs WSL2 choice. The reason is that
Isaac Sim uses Python 3.12 internally, and custom interface support requires building
your ROS 2 workspace against Python 3.12. On Linux, this is handled via Dockerfiles in IsaacSim-ros_workspaces.
On Windows, no equivalent Python 3.12 build path exists for either method.
Isaac Sim 6.0.1 is not yet paired with any Isaac ROS release – the
compatibility table currently ends at Isaac Sim 5.1.0 (paired with Isaac ROS 4.0.0).
Isaac ROS 4.0 dropped WSL2 support entirely. Earlier Isaac ROS docs (3.x)
listed “Experimental: WSL2 on Windows 11” as a compute target. Isaac ROS 4.0 no
longer does – its x86 platform requirement is Ubuntu 24.04 only (native,
not WSL2).
In short: Isaac ROS GPU-accelerated nodes require native Ubuntu 24.04. There is no
Windows path – not WSL2, not Pixi.
Direct recommendation
Given your stated requirements (Docker workflows, custom ROS interfaces, Isaac ROS
GPU nodes, eventual migration to Ubuntu):
Neither Windows option covers your full requirements. Here is the practical path:
Right now (Windows 11): Use native Pixi for Isaac Sim + Isaac Lab
development. It is the most stable Windows path for Isaac Sim’s ROS 2 bridge.
Standard message types cover the Isaac Sim tutorials and most of Isaac Lab’s
ROS 2 integration.
When you need Docker, custom interfaces, or Isaac ROS: Migrate to native
Ubuntu 24.04. You already know this migration is planned – treat it as the
hard prerequisite for those features, not a “later maybe”. WSL2 does not solve
the custom interfaces problem, and Isaac ROS 4.x does not support WSL2 at all.
If the Ubuntu move is weeks away but Isaac ROS is urgent: Isaac ROS 4.x
inside a Docker container on a native Ubuntu 24.04 machine is the only supported
path. There is no workaround on Windows.
Summary
Requirement
Pixi (Win)
WSL2 (Win)
Native Ubuntu 24.04
Isaac Sim ROS bridge
Yes
Yes (deprecated)
Yes (recommended)
Custom ROS interfaces
No
No
Yes
Docker workflows
No
Yes (complex)
Yes
Isaac ROS 4.x GPU nodes
No
No
Yes
Isaac Sim 6.x + Isaac ROS pairing
n/a
n/a
Yes (pending release)
For a Real-to-Sim pipeline targeting Isaac ROS, native Ubuntu 24.04 is the only
environment that satisfies all four rows. Pixi on Windows is a reasonable starting
point while your company’s platform decision catches up.
I’m currently in front of the same issue, so I wanted to be sure about a thing before starting to install and set up everything.
Does the native pixi for Isaac Sim setup (which is explained here ROS 2 Installation (Other Platforms) — Isaac Sim Documentation ) suport the installation of Isaac Lab directly?
Or is it necessary to install another version of Isaac Sim in addition to the pixi based one in order to let Isaac Lab run correctly?
Good question – it can be confusing because “Pixi-based setup” refers to two separate things.
Short answer: one Isaac Sim install is enough. Isaac Lab and the Pixi ROS workspace both point at the same C:\isaacsim binary – they are complementary, not competing.
What the Pixi ROS workspace actually is
The IsaacSim-ros_workspaces Pixi workspace is a ROS 2 bridge workspace. It installs ROS 2 Jazzy natively on Windows (via RoboStack conda packages) and provides tooling to launch and communicate with Isaac Sim. It does not install Isaac Sim itself.
“Install the standalone Isaac Sim package following Workstation Setup. The Pixi workspace expects it at C:\isaacsim (the default isaac_sim_package_path); if you extracted elsewhere, update the value under [target.win.activation] in pixi.toml.”
So the Pixi workspace wraps and launches the standalone Isaac Sim you already have. It does not bring a second copy.
How Isaac Lab fits in
Isaac Lab installs into that same standalone Isaac Sim. On Windows, the workflow is:
git clone https://github.com/isaac-sim/IsaacLab.git
cd IsaacLab
isaaclab.bat --install
isaaclab.bat looks for Isaac Sim at C:\isaacsim (or whatever ISAACSIM_PATH points to) and installs its extensions there. See the Isaac Lab binaries installation guide for the full steps.
The full picture on Windows 11
Component
What it does
Points at
Isaac Sim standalone (C:\isaacsim)
The simulator binary
– (this is the base)
IsaacSim-ros_workspaces (Pixi)
Installs ROS 2 Jazzy + bridge tooling
C:\isaacsim
Isaac Lab (isaaclab.bat)
Installs RL/robotics extensions
C:\isaacsim
All three share the same Isaac Sim. No duplicate installation needed.
Follow-up: Pixi workspace ships its own Isaac Sim pip package — documentation feedback and confirmation on next steps
Hi, and thanks for the detailed answer above, but I’d like to report something I observed on my machine that seems to differ from the documented flow, and confirm that my planned next steps are correct.
Background: three installations
1. First install — Miniconda environment with Isaac Sim 5.1.0 and the matching Isaac Lab version. Standard conda/pip route, worked as documented.
2. Second install — when I needed ROS 2, I followed the ROS 2 Installation (Other Platforms) guide and set up the Pixi Jazzy workspace. After pixi install I found a second, complete Isaac Sim inside the Pixi environment, in addition to the conda one. At the time I assumed I had made a mistake somewhere.
3. Third install (current, new machine) — this time I deliberately tested the behaviour. I did not install Isaac Sim at all. My entire installation was:
git clone https://github.com/isaac-sim/IsaacSim-ros_workspaces.git
cd IsaacSim-ros_workspaces
git submodule update --init --recursive
cd jazzy_ws
pixi install
pixi run build
No Isaac Sim installer was run, no Workstation Setup was performed, and C:\isaacsim does not exist on this machine. Despite that, pixi run sim starts a fully working Isaac Sim 6.0.1 with the ROS 2 bridge, and pixi run ros2 topic list shows /clock, /rosout and /parameter_events as expected.
I reckon pixi install resolves the [pypi-dependencies] section of the shipped pixi.toml, which declares Isaac Sim itself as a dependency:
with ~25 pip metadata folders confirming it is a pip installation (isaacsim-6.0.1.0.dist-info, isaacsim_core-6.0.1.0.dist-info, isaacsim_ros2-6.0.1.0.dist-info, …) and VERSION = 6.0.1-rc.7+release.42383....
And this is the copy that actually runs. The workspace tasks invoke the bare isaacsim command:
which PATH resolves to the pip entry point at jazzy_ws\.pixi\envs\default\Scripts\isaacsim.exe. Kit’s startup log confirms it, loading all extensions from inside the environment (...\.pixi\envs\default\Lib\site-packages\isaacsim\extscache\...).
To be clear about the repository state: this is unmodified upstream — IsaacSim-ros_workspaces at commit dd3eeed (“Added changes for Isaac Sim 6.0.1”), with git status clean on jazzy_ws/pixi.toml. I changed nothing.
Meanwhile, the Windows activation block still points at a standalone installation:
On my machine this prepends a non-existent directory to PATH. Notably, kit\python\libdoes not exist inside the pip package either — that directory layout only exists in the standalone package. This suggests the variable is meant for a standalone install that the workspace no longer actually requires.
The documentation states:
“Install the standalone Isaac Sim package following Workstation Setup. The Pixi workspace expects it at C:\isaacsim (the default isaac_sim_package_path); if you extracted elsewhere, update the value under [target.win.activation] in pixi.toml.”
But since the workspace pulls its own Isaac Sim through [pypi-dependencies] unconditionally, and the tasks launch that copy, a user following the documentation literally ends up with the standalone and the pip copy — two full Isaac Sim installations of roughly 13 GB each. That is exactly what happened on my second install.
Question 1: Is the PyPI isaacsim dependency the intended mechanism for 6.0.1, with isaac_sim_package_path now being legacy? And is my current setup — Pixi only, no standalone, no C:\isaacsim — a supported configuration, or will it cause problems later?
Question 2 — confirming my planned next steps
Based on your answer, my understanding is that to add Isaac Lab I should:
Download and extract the standalone Isaac Sim package to C:\isaacsim
Modify pixi.toml so the workspace uses that standalone instead of the bundled pip package — i.e. change the sim / check / headless tasks to launch C:\isaacsim, since isaac_sim_package_path alone does not redirect which binary runs
Remove isaacsim from [pypi-dependencies] and re-run pixi install, so the 12.84 GB copy inside the environment is dropped
Install Isaac Lab against C:\isaacsim via isaaclab.bat --install
so that a single Isaac Sim serves both Isaac Lab and the ROS 2 bridge.
Is this correct? Specifically:
Should the pip isaacsim actually be removed from [pypi-dependencies], or is it expected to coexist with a standalone install?
With the standalone launched from within the Pixi environment, will the ROS 2 bridge pick up ROS 2 Jazzy from Pixi rather than the internal Humble libraries bundled in exts\isaacsim.ros2.core\humble\lib? The documentation describes internal-library auto-loading for Ubuntu only, so I would like to be sure this behaves as expected on Windows.
Is editing the shipped pixi.toml the supported way to do this, or is there a cleaner mechanism I am missing?
Environment: Windows 11, RTX A4000 (16 GB), driver 596.72, Isaac Sim 6.0.1, ROS 2 Jazzy via Pixi/RoboStack.
Yes, the confusion here is understandable – the current workflow is genuinely non-obvious
and the documentation does not explain the reasoning behind it. Let me lay it out clearly.
Why you end up with two Isaac Sim installs (by design)
The Pixi ROS 2 workspace (IsaacSim-ros_workspaces) pulls in Isaac Sim as a pip package
automatically when you run pixi install. This is intentional, not a bug. The reason is a torch dependency conflict: Isaac Sim 6.0.1 bundles its own version of PyTorch, and that
bundled torch conflicts with the dependencies that the Pixi ROS 2 environment needs. The pip
install of Isaac Sim is specifically packaged to resolve cleanly inside the Pixi environment
where the standalone binary cannot.
So the two installs serve different purposes:
Install
What it is
What it does
Standalone (C:\isaacsim)
Full binary package or source install
Gives you sample scripts, source files, GUI mode, and custom extensions
Pip install (inside .pixi\envs\)
Binary-only runtime
The actual Python interpreter + Isaac Sim runtime that pixi run python uses
They are not duplicates – they play different roles.
The supported Python standalone workflow
1. Install Isaac Sim the normal way (standalone binary or source) at C:\isaacsim
2. Install the Pixi ROS 2 workspace (this also installs the pip Isaac Sim automatically)
3. Run your scripts with: pixi run python C:\isaacsim\path\to\script.py
Step 3 is the key: pixi run python uses the pip-installed Isaac Sim runtime from the
Pixi environment, but you point it at a script file from your standalone install. This
is how you get the ROS 2 environment (from Pixi) and the sample scripts / editable source
(from the standalone) at the same time.
Note: because the pip install is binary-only, you cannot modify extensions or access editable
source through it. If you need custom extensions, they go in your standalone install, and you
reference them by path when invoking pixi run python.
Does Isaac Lab work with this setup?
Yes. Isaac Lab installs its extensions into your standalone Isaac Sim (at C:\isaacsim),
which is exactly where your scripts live. When you run pixi run python <script_from_isaacsim>,
that script can reference Isaac Lab extensions from the standalone tree. The Pixi runtime
executes the script; the standalone provides the content. They coexist cleanly.
The standard Windows path for Isaac Lab remains:
set ISAACSIM_PATH=C:\isaacsim
isaaclab.bat --install
No second Isaac Lab install or separate Isaac Sim for Isaac Lab is needed.
This changes in Isaac Sim 6.1
The torch conflict that makes the two-install setup necessary in 6.0.1 is being fixed in Isaac Sim 6.1. When 6.1 ships, the Pixi workspace will be able to use your standalone
install directly as the runtime – you will no longer need the separate pip install, and
you will point to the same C:\isaacsim location for both the runtime and the scripts.
If your project timeline allows waiting for 6.1, that setup will be significantly cleaner.
Summary for your situation
For 6.0.1 on Windows 11 with Isaac Lab:
Install Isaac Sim standalone at C:\isaacsim – this is your Isaac Lab home and your scripts home
Run pixi install in the ROS 2 workspace – it pulls the pip runtime automatically (expected)
Use pixi run python C:\isaacsim\path\to\script.py for all ROS 2 bridge work
Do not remove or modify the isaacsim pip dependency in pixi.toml – it is there intentionally
Custom extensions and Isaac Lab live in the standalone; the Pixi runtime runs your scripts from there
The awkwardness is known and will be resolved in 6.1.
Hoping the earlier replies covered what you needed. If you run into a concrete issue while getting set up, please feel free to open a new topic with the specific error or behavior – that will make it easier to track and resolve. Closing this one out for now.