Using pixi with direnv

[humphd]

We're using pixi and direnv. Running pixi shell does something pretty similar to using direnv, and I wondered if I could simply do it all via direnv (i.e., skip pixi shell completely).

For example, when I run my stuff in a devcontainer, pixi shell creates and sources a shell script that looks something like this:

export PIXI_PACKAGE_MANIFEST="/workspaces/project/pixi.toml"
export PIXI_PACKAGE_PLATFORMS="linux-64,linux-aarch64,osx-64,osx-arm64"
export PATH="/workspaces/project/.pixi/env/bin:/home/user/.cache:/vscode/vscode-server/bin/linux-arm64/f1b07bd25dfad64b0167beb15359ae573aecd2cc/bin/remote-cli:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
export CONDA_PREFIX="/workspaces/project/.pixi/env"
export PIXI_PROMPT="(project) "
export PIXI_PACKAGE_VERSION="0.1.0"
export PIXI_PACKAGE_NAME="project"
export CONDA_DEFAULT_ENV="project"
export PIXI_PACKAGE_ROOT="/workspaces/project"

I'm wondering if I could basically move a bunch of this to my .envrc file, and have it get sourced automatically by direnv? Because it's in a devcontainer, paths are stable for all users.

Would using that approach cause issues, due to side effects of running pixi shell, that I'm not aware of? For example, I know that I'd need to handle pixi install on my own beforehand (I do).

Thanks for your guidance.

[ruben-arts]

Hi @humphd,

This could in theory work but I would not recommend this workflow as it might break as soon as you update any dependency.

Just to give an example, this is 1/3 of the exported values if I activate an environment that includes ROS2 and CMake:

export PIXI_PACKAGE_VERSION="0.1.0"
export CONDA_TOOLCHAIN_HOST="x86_64-conda-linux-gnu"
export DEBUG_FORTRANFLAGS="-march=nocona -mtune=haswell -ftree-vectorize -fPIC -fstack-protector-strong -fno-plt -O2 -ffunction-sections -pipe -isystem /home/rarts/examples/turtlesim-pixi/.pixi/env/include -march=nocona -mtune=haswell -ftree-vectorize -fPIC -fstack-protector-all -fno-plt -Og -g -Wall -Wextra -fcheck=all -fbacktrace -fimplicit-none -fvar-tracking-assignments -ffunction-sections -pipe"
export LD_GOLD="/home/rarts/examples/turtlesim-pixi/.pixi/env/bin/x86_64-conda-linux-gnu-ld.gold"
export AR="/home/rarts/examples/turtlesim-pixi/.pixi/env/bin/x86_64-conda-linux-gnu-ar"
export ROS_PYTHON_VERSION="3"
export RANLIB="/home/rarts/examples/turtlesim-pixi/.pixi/env/bin/x86_64-conda-linux-gnu-ranlib"
export F95="/home/rarts/examples/turtlesim-pixi/.pixi/env/bin/x86_64-conda-linux-gnu-f95"
export LD="/home/rarts/examples/turtlesim-pixi/.pixi/env/bin/x86_64-conda-linux-gnu-ld"
export GXX="/home/rarts/examples/turtlesim-pixi/.pixi/env/bin/x86_64-conda-linux-gnu-g++"
export CXX_FOR_BUILD="/home/rarts/examples/turtlesim-pixi/.pixi/env/bin/x86_64-conda-linux-gnu-c++"
export CFLAGS="-march=nocona -mtune=haswell -ftree-vectorize -fPIC -fstack-protector-strong -fno-plt -O2 -ffunction-sections -pipe -isystem /home/rarts/examples/turtlesim-pixi/.pixi/env/include"
export GCC="/home/rarts/examples/turtlesim-pixi/.pixi/env/bin/x86_64-conda-linux-gnu-gcc"
export GPROF="/home/rarts/examples/turtlesim-pixi/.pixi/env/bin/x86_64-conda-linux-gnu-gprof"
export BUILD="x86_64-conda-linux-gnu"
export CMAKE_PREFIX_PATH="/home/rarts/examples/turtlesim-pixi/.pixi/install/turtle_controller_cpp_py:/home/rarts/examples/turtlesim-pixi/.pixi/env:/home/rarts/examples/turtlesim-pixi/.pixi/env/x86_64-conda-linux-gnu/sysroot/usr"
export CPPFLAGS="-DNDEBUG -D_FORTIFY_SOURCE=2 -O2 -isystem /home/rarts/examples/turtlesim-pixi/.pixi/env/include"
export DEBUG_CXXFLAGS="-fvisibility-inlines-hidden -fmessage-length=0 -march=nocona -mtune=haswell -ftree-vectorize -fPIC -fstack-protector-all -fno-plt -Og -g -Wall -Wextra -fvar-tracking-assignments -ffunction-sections -pipe -isystem /home/rarts/examples/turtlesim-pixi/.pixi/env/include"

Conda packages can include activation scripts that get scanned by pixi shell to create the activation script. This can also change version by version. If you would want to hard code these variables you should run a check script that syncs these variables with the lockfile.

I'm actually wondering what you miss in the current capabilities of pixi to skip the use of direnv. If it is just setting the environment variables or simple scripts, then maybe you can check the activation scripts feature. This will run additional scripts that you make yourself to create the environment you want.

[humphd]

@ruben-arts, this is really helpful. I suspected as much. I'll look at the activation scripts, to see if it has any potential.

We're using direnv to make it easier to set environment variables automatically as we move around in a monorepo, based on folder depth and presence of .envrc and/or .env files in the tree.

One more question: I assume that despite your advice above re: variables, adding .pixi/env/bin to the PATH is relatively safe?

Thanks for the help figuring this out.

[ruben-arts]

I see, hopefully the idea of a workspace will help with that in the future. In this case adding the bin folder to the PATH shouldn't be an issue, its all unix logic in the end 😉.

[burdiyan]

I'm actually wondering what you miss in the current capabilities of pixi to skip the use of direnv. If it is just setting the environment variables or simple scripts, then maybe you can check the activation scripts feature. This will run additional scripts that you make yourself to create the environment you want.

@humphd For me the most desired feature is for Pixi to automatically activate the environment when I navigate into the directory. If it could do that on Windows automatically that would be awesome!

In addition to that, Direnv has nice integration with VS Code. I used to use Direnv + Nix, and VS Code was recognizing all of the tools installed in my local Nix dev environment. I wish I could do the same thing for Pixi, and if it would work without Direnv I'd be more than happy.

[humphd]

A note that in v0.13, relying on .pixi/bin in your PATH is going to break, and needs to be .pixi/envs/default/bin.

[pavelzw]

The stuff that @ruben-arts pasted can now be automatically generated by pixi using pixi shell-hook

if you add the following to your .envrc, this should be what you're looking for:

# installs the environment if needed,
# direnv ensures that the environment is deactivated when exiting the directory
eval "$(pixi shell-hook)"

Beware that when you already sourced pixi shell-hook from your .envrc and then run pixi run ..., you will activate your environment twice.
This won't create problems in 99% of cases but just keep this behavior in mind

❯ cd test-pixi
direnv: loading /private/tmp/test-pixi/.envrc
direnv: export +CONDA_DEFAULT_ENV +CONDA_PREFIX +PIXI_ENVIRONMENT_NAME +PIXI_ENVIRONMENT_PLATFORMS +PIXI_PROJECT_MANIFEST +PIXI_PROJECT_NAME +PIXI_PROJECT_ROOT +PIXI_PROJECT_VERSION +PIXI_PROMPT ~PATH
❯ pixi run env | grep PATH
PATH=/private/tmp/test-pixi/.pixi/envs/default/bin:/private/tmp/test-pixi/.pixi/envs/default/bin:...

Notice how here, PATH got prepended twice with the pixi prefix.

[ruben-arts]

You don't need the pixi install as pixi shell-hook checks if the env is up-to-date and installs it when needed.

[ruben-arts]

@pavelzw Added this description also to the documentation: https://pixi.sh/latest/environment/#using-pixi-with-direnv