Cleanup the Windows instructions for using conda/pixi.

[clalancette]

This makes the instructions match what CI does in ros2/ci#802 . This relies on ros2/ros2#1642 being merged first.

[github-actions]

HTML artifacts: https://github.com/ros2/ros2_documentation/actions/runs/13703707605/artifacts/2705157385.

To view the resulting site:

1. Click on the above link to download the artifacts archive
2. Extract it
3. Open html-artifacts-4989/index.html in your favorite browser

[j-rivero]

Nice reduction in the number of steps required.

There are some references to chocolatey in the Troubleshooting and Contributing documents:

source/How-To-Guides/Installation-Troubleshooting.rst:We've seen that sometimes the chocolatey packages for ``asio``, ``tinyxml2``, etc. do not add important registry entries and CMake will be unable to find them when building ROS 2.
source/How-To-Guides/Installation-Troubleshooting.rst:We've not yet been able to identify the root cause, but uninstalling the chocolatey packages (with ``-n`` if the uninstall fails the first time), and then reinstalling them will fix the issue.
source/How-To-Guides/Installation-Troubleshooting.rst:- ``choco uninstall patch; colcon build --cmake-clean-cache`` - This is a bug in the `GNU Patch For Windows package <https://chocolatey.org/packages/patch>`_. If this package is not installed, the build process will instead use the version of Patch distributed with git.
source/The-ROS2-Project/Contributing/Windows-Tips-and-Tricks.rst:Unfortunately, the ``patch`` executable as delivered by chocolatey requires Administrator access to run.

Do we need to remove these ones?

[ros-discourse]

This pull request has been mentioned on ROS Discourse. There might be relevant details there:

https://discourse.ros.org/t/upcoming-switch-of-windows-installation-to-pixi-conda/41916/1

[sloretz]

This is so much better!

Testing Windows Development Setup on a Windows 11 machine. I'm still waiting for colcon build --merge-install to complete because it's a very slow machine.

I also had to uninstall stuff previously installed for ROS 2. I don't think we need to include this in these pages, but posting in case someone else runs into this.

• choco uninstall all
• Had to manually delete a bunch of system environment variable entries so packages don't try to use uninstalled programs.

[ahcorde]

I'm not pretty sure about the --quiet flag, I was expecting something when I executed the command, a window or something but the command just returned without a message. Removing this flag I was able to see a wizard running.

[clalancette]

Yeah, these instructions are directly copied out of the Dockerfile. I agree that this isn't great, but even if we remove --quiet, a lot of stuff happens kind of "behind the scenes" that is not obvious. My take on this is that we leave this as-is, but add a note saying that this will take a while and not print anything.

[ahcorde]

These instructions are working on cmd.exe but in some parts of the documentation we are also adding instructions for PowerShell. Does it make sense to add them here ?

[mjcarroll]

Worth noting that on Windows 11, I needed to make sure that the execution policy was set correctly:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

[knmcguire]

Just mind that the Set-ExecutionPolicy is a powershell only command. This is not necessary in the command prompt as mentioned that the user should open in the instructions.

But yes it is a bit confusing to switch terminals half way...

[clalancette]

Since I don't have Windows 11 installed: is the Set-ExecutionPolicy needed to install MSVC, to install pixi itself, to run pixi install, or to use pixi shell (or all of them)? That will determine where we end up putting this command.

[knmcguire]

It's used for executing powershell scripts with the .ps1 file extension that didn't come natively with the windows install so it's for sourcing the workspace. This could holds for when MSVC compiler is sourced, when pixi shell is started (not installed), and when a ROS 2 environment is sourced with install/setup.psi, IF used in powershell

But, the instructions though say to switch to a regular command prompt instead , which does not require the execution policy change in order to source .bat files, which is the the source(batch) files for the regular command prompt and are not as restricted. So I never had to do this policy change myself

[knmcguire]

Hi! Probably there are too many 'captains' (reviewers) on this ship, but my curiosity got the better of me and tried these instructions out anyway😄

I found a couple of more issues with the instructions of the source build which I've added, I couldn't test out the binary build since the right zip aren't available yet.

[knmcguire]

On Window 11 (version 10.0.26100) I got a permission error. I had to go to C:/Users/[USER]/downloads and download the vsbuildstool there (and run it with .\ as @sloretz already mentioned below.)

irm : Access to the path 'C:\vs_buildtools_2019.exe' is denied.
At line:1 char:1
+ irm https://aka.ms/vs/16/release/vs_buildtools.exe -OutFile vs_buildt ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Invoke-RestMethod], Unaut
   horizedAccessException
    + FullyQualifiedErrorId : System.UnauthorizedAccessException,Microsoft
   .PowerShell.Commands.InvokeRestMethodCommand

[knmcguire]

This is most likely due to that powershell was not run with administrator access. Either that needs to be added to the instructions, or the user account of the computer needs to get full control

[knmcguire]

Just mind that the Set-ExecutionPolicy is a powershell only command. This is not necessary in the command prompt as mentioned that the user should open in the instructions.

But yes it is a bit confusing to switch terminals half way...

[clalancette]

These instructions are working on cmd.exe but in some parts of the documentation we are also adding instructions for PowerShell. Does it make sense to add them here ?

But yes it is a bit confusing to switch terminals half way...

I don't disagree with these sentiments. These instructions were originally written to more-or-less directly mimic what the Dockerfile does in ros2/ci#802 . In that PR, we use powershell to do some of the setup, cmd to do some of the other setup, and then cmd again to actually run the build and test. While we could probably change that code to use powershell everywhere, that is going to require a lot more validation. I'm not going to have time to do that.

So we need to decide: is it better to more closely follow the CI instructions, or is it better to have a "consistent" powershell experience in the user instructions? Thoughts?

[knmcguire]

For this PR, following the CI instructions should be fine. It's already such an improvement to what it was before, so anything that will just enhance that (like making it PowerShell consistent), can be in a separate PR after this one.

[ros-discourse]

This pull request has been mentioned on ROS Discourse. There might be relevant details there:

https://discourse.ros.org/t/ros-pmc-minutes-for-2025-03-12/42493/1