Python packages specified via PYTHONPATH (such as ROS 2 Python packages) are considered in pixi environment even if they are related to the apt python installation about pixi

[ruben-arts]

He @traversaro, thanks for the write up. We remember this issue as we also started with conda to run ROS.

The discussion on what is should be default in isolation is indeed a hard one, we still have to figure that out.

To help your users directly setting these variables can be set with the activation.scripts

You could just generate a clean_env.sh and clean_env.bat which exports these variables:

export PYTHONUSERBASE=intentionally-disabled
export PYTHONPATH=

[traversaro]

Thanks @ruben-arts, we used your workaround in robotology/icub-models-generator#263 . Not sure if you want to keep this issue open or not, feel free to close if you think the problems discussed in the issue is tracked already somewhere else.

[traversaro]

This is probably also related to #288, as the workaround of setting PYTHONPATH could be simpler if it was possible to set env variables for all tasks and shells.

[traversaro]

We remember this issue as we also started with conda to run ROS.

The discussion on what is should be default in isolation is indeed a hard one, we still have to figure that out.

Indeed, I was aware of this for conda for a long time. The main difference I see between pixi and conda is about user expectation (or at least, how I started to introduce conda and pixi to our users). When I started to introduce conda, I always warned users that conda and apt are different things, it is important not to mix them, etc, etc (see https://github.com/robotology/robotology-superbuild/blob/master/doc/conda-forge.md and https://github.com/robotology/robotology-superbuild/blob/master/doc/install-mambaforge.md for example documents I pointed users to). So users are at least aware of possible conflicts.

The pixi story is a bit different. Quoting from https://prefix.dev/blog/uv_in_pixi#our-goals-for-pixi, the goal of pixi presented to the users is to be able to start working on a project with just:

Hence why I think it could make sense to think about what should be isolated by default in the pixi case.

To help your users directly setting these variables can be set with the activation.scripts

You could just generate a clean_env.sh and clean_env.bat which exports these variables:

export PYTHONUSERBASE=intentionally-disabled
export PYTHONPATH=

Cool, that is indeed much better then my solution! I will probably start adding it by default to any pixi package using Python packages. Just to understand, are these pixi activation scripts expected to run before any conda package activation script? Otherwise I am afraid of corrupting the value of PYTHONPATH set by some conda package. I could check directly the code, but I would like to understand if this is an implementation detail, or part of the documented and intended behavior of the functionality, thanks!

[ruben-arts]

Yeah I totally agree with you!

Just to understand, are these pixi activation scripts expected to run before any conda package activation script? Otherwise I am afraid of corrupting the value of PYTHONPATH set by some conda package.

This is what the activation script looks like that we generate. As you can see we put the custom activation in last.

➜ pixi shell-hook
export PATH="/home/rarts/development/pixi/examples/ros2-nav2/.pixi/envs/default/bin:/home/rarts/.local/bin:/home/rarts/bin:/usr/lib64/ccache:/home/rarts/.cargo/bin:/home/rarts/.npm-global/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/var/lib/snapd/snap/bin:/home/rarts/.pixi/bin"
export CONDA_PREFIX="/home/rarts/development/pixi/examples/ros2-nav2/.pixi/envs/default"
export PIXI_ENVIRONMENT_PLATFORMS="osx-arm64,linux-64,osx-64"
export CONDA_DEFAULT_ENV="ros2-nav2"
export PIXI_PROJECT_ROOT="/home/rarts/development/pixi/examples/ros2-nav2"
export PIXI_ENVIRONMENT_NAME="default"
export PIXI_PROJECT_VERSION="0.1.0"
export PIXI_PROMPT="(ros2-nav2) "
export PIXI_PROJECT_MANIFEST="/home/rarts/development/pixi/examples/ros2-nav2/pixi.toml"
export PIXI_PROJECT_NAME="ros2-nav2"
. "/home/rarts/development/pixi/examples/ros2-nav2/.pixi/envs/default/etc/conda/activate.d/gazebo_activate.sh"
. "/home/rarts/development/pixi/examples/ros2-nav2/.pixi/envs/default/etc/conda/activate.d/gdal-activate.sh"
. "/home/rarts/development/pixi/examples/ros2-nav2/.pixi/envs/default/etc/conda/activate.d/geotiff-activate.sh"
. "/home/rarts/development/pixi/examples/ros2-nav2/.pixi/envs/default/etc/conda/activate.d/libglib_activate.sh"
. "/home/rarts/development/pixi/examples/ros2-nav2/.pixi/envs/default/etc/conda/activate.d/libxml2_activate.sh"
. "/home/rarts/development/pixi/examples/ros2-nav2/.pixi/envs/default/etc/conda/activate.d/proj4-activate.sh"
. "/home/rarts/development/pixi/examples/ros2-nav2/.pixi/envs/default/etc/conda/activate.d/ros-humble-ros-workspace_activate.sh"
. "/home/rarts/development/pixi/examples/ros2-nav2/.pixi/envs/default/etc/conda/activate.d/ruby_activate.sh"
. "/home/rarts/development/pixi/examples/ros2-nav2/clean_env.sh"

[traversaro]

Ah, the problem is that for example in your use case /home/rarts/development/pixi/examples/ros2-nav2/.pixi/envs/default/etc/conda/activate.d/ros-humble-ros-workspace_activate.sh also sets the PYTHONPATH, so we would interfere with it if we unset the PYTHONPATH in /home/rarts/development/pixi/examples/ros2-nav2/clean_env.sh. Note that perhaps PYTHONPATH set by ros-humble-ros-workspace_activate.sh is not necessary, but I would need to double check this. Anyhow, this for sure is an improvement over setting the env variable manually in every step, thanks!

[ruben-arts]

Closing this in favor of #289