`pixi shell` blocks

phreed · February 12, 2025, 8:46pm

When activating a pixi environment via pixi shell the terminal blocks.
It does not produce a prompt.
It does not respond to keyboard input (including Ctrl-C and Ctrl-Z).
The running pixi process does respond to several interrupts:
e.g.
kill -s STOP PID
Backgrounds the process; then the terminal responds to input but it still does not show any sign of handling those inputs.

Here is a trace from running: pixi shell -vvv

 INFO pixi_manifest::discovery: Found manifest in directory: "/var/home/phreed/Projects/cts-3.x", continuing further.
DEBUG pixi_config: Loading config from /etc/pixi/config.toml
DEBUG pixi_config: Loading config from /var/home/phreed/.config/pixi/config.toml
DEBUG pixi_config: Loading config from /var/home/phreed/.pixi/config.toml
DEBUG pixi_config: Loading config from /var/home/phreed/Projects/cts-3.x/.pixi/config.toml
DEBUG pixi_config: Failed to load local config: /var/home/phreed/Projects/cts-3.x/.pixi/config.toml (error: no file was found at /var/home/phreed/Projects/cts-3.x/.pixi/config.toml)
 INFO pixi::environment: verifying prefix location is unchanged, with prefix file: /var/home/phreed/Projects/cts-3.x/.pixi/envs/conda-meta/pixi_env_prefix
 INFO pixi::lock_file::update: the lock-file is up-to-date
 INFO pixi::lock_file::update: Environment 'default' is up-to-date with lock file hash
DEBUG pixi::activation: Running activation script for Default
DEBUG pixi::cli::shell: Pixi environment activation:
{"PIXI_ENVIRONMENT_NAME": "default", "PROJECT_DIR": "/var/home/phreed/Projects/cts-3.x", "PIXI_PROMPT": "(cts-3.x) ", "GSETTINGS_SCHEMA_DIR_CONDA_BACKUP": "", "PIXI_PROJECT_NAME": "cts-3.x", "PIXI_PROJECT_VERSION": "0.1.0", "JAVA_HOME": "/var/home/phreed/Projects/cts-3.x/.pixi/envs/default/lib/jvm", "GSETTINGS_SCHEMA_DIR": "/var/home/phreed/Projects/cts-3.x/.pixi/envs/default/share/glib-2.0/schemas", "CONDA_DEFAULT_ENV": "cts-3.x", "PIXI_PROJECT_ROOT": "/var/home/phreed/Projects/cts-3.x", "PATH": "/var/home/phreed/Projects/cts-3.x/.pixi/envs/default/bin:/var/home/phreed/.pixi/bin:/home/linuxbrew/.linuxbrew/bin:/home/linuxbrew/.linuxbrew/sbin:/var/home/phreed/.local/bin:/var/home/phreed/bin:/usr/lib64/ccache:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/var/home/phreed/.local/share/JetBrains/Toolbox/scripts:/var/home/phreed/.local/share/JetBrains/Toolbox/scripts", "PIXI_ENVIRONMENT_PLATFORMS": "linux-64", "CONDA_PREFIX": "/var/home/phreed/Projects/cts-3.x/.pixi/envs/default", "JAVA_LD_LIBRARY_PATH": "/var/home/phreed/Projects/cts-3.x/.pixi/envs/default/lib/jvm/lib/server", "PIXI_EXE": "/var/home/phreed/.pixi/bin/pixi", "PIXI_PROJECT_MANIFEST": "/var/home/phreed/Projects/cts-3.x/pixi.toml", "PIXI_IN_SHELL": "1"}
DEBUG rattler_shell::shell: Guessing the current shell is bash. Parent process name: bash and args: []
 INFO pixi::cli::shell: Starting shell: Bash(Bash)

The last message I see is produced here:

github.com/prefix-dev/pixi

src/cli/shell.rs

fc3e1a861

use std::{collections::HashMap, io::Write};

use clap::Parser;
use miette::IntoDiagnostic;
use rattler_conda_types::Platform;
use rattler_shell::{
    activation::PathModificationBehavior,
    shell::{CmdExe, PowerShell, Shell, ShellEnum, ShellScript},
};

use crate::cli::cli_config::{PrefixUpdateConfig, WorkspaceConfig};
use crate::lock_file::UpdateMode;
use crate::workspace::get_activated_environment_variables;
use crate::{
    activation::CurrentEnvVarBehavior, environment::get_update_lock_file_and_prefix, prompt,
    workspace::virtual_packages::verify_current_platform_has_required_virtual_packages,
    UpdateLockFileOptions, WorkspaceLocator,
};
use pixi_config::{ConfigCliActivation, ConfigCliPrompt};

This file has been truncated. show original

Following that the start_unix_shell function is called where a tempfile is created.

github.com/prefix-dev/pixi

src/cli/shell.rs

fc3e1a861


      
          let mut temp_file = tempfile::Builder::new()
              .prefix("pixi_env_")
              .suffix(&format!(".{}", shell.extension()))
              .rand_bytes(3)
              .tempfile()
              .into_diagnostic()?;

I do see /tmp/pixi_env_*.sh files being created.

Here is the contents of an examplar:

export PIXI_PROJECT_VERSION="0.1.0"
export CONDA_DEFAULT_ENV="cts-3.x"
export PIXI_PROJECT_MANIFEST="/var/home/phreed/Projects/cts-3.x/pixi.toml"
export PATH="/var/home/phreed/Projects/cts-3.x/.pixi/envs/default/bin:/var/home/phreed/.pixi/bin:/home/linuxbrew/.linuxbrew/bin:/home/linuxbrew/.linuxbrew/sbin:/var/home/phreed/.local/bin:/var/home/phreed/bin:/usr/lib64/ccache:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/var/home/phreed/.local/share/JetBrains/Toolbox/scripts:/var/home/phreed/.local/share/JetBrains/Toolbox/scripts"
export PIXI_PROJECT_ROOT="/var/home/phreed/Projects/cts-3.x"
export JAVA_LD_LIBRARY_PATH="/var/home/phreed/Projects/cts-3.x/.pixi/envs/default/lib/jvm/lib/server"
export CONDA_PREFIX="/var/home/phreed/Projects/cts-3.x/.pixi/envs/default"
export PIXI_ENVIRONMENT_NAME="default"
export JAVA_HOME="/var/home/phreed/Projects/cts-3.x/.pixi/envs/default/lib/jvm"
export PIXI_EXE="/var/home/phreed/.pixi/bin/pixi"
export PIXI_IN_SHELL="1"
export PROJECT_DIR="/var/home/phreed/Projects/cts-3.x"
export GSETTINGS_SCHEMA_DIR="/var/home/phreed/Projects/cts-3.x/.pixi/envs/default/share/glib-2.0/schemas"
export PIXI_ENVIRONMENT_PLATFORMS="linux-64"
export PIXI_PROJECT_NAME="cts-3.x"
export GSETTINGS_SCHEMA_DIR_CONDA_BACKUP=""
export PIXI_PROMPT="(cts-3.x) "
echo '=== DONE ==='
export PS1="(cts-3.x) ${PS1:-}"
# shellcheck shell=bash
pixi() {
    local first_arg="$1"
    local cmd="$PIXI_EXE $*"

    eval "$cmd"

    case "$first_arg" in
        add|a|remove|rm|install|i)
            eval "$($PIXI_EXE shell-hook --change-ps1 false)"
            hash -r
            ;;
    esac
}

This would indicate it gets at least this far.

github.com/prefix-dev/pixi

src/cli/shell.rs

fc3e1a861


      
          }
          
          const DONE_STR: &str = "=== DONE ===";
          shell_script.echo(DONE_STR).into_diagnostic()?;
          
          temp_file
              .write_all(shell_script.contents().into_diagnostic()?.as_bytes())
              .into_diagnostic()?;
          
          // Write custom prompt to the env file
          temp_file.write(prompt.as_bytes()).into_diagnostic()?;
          
          let mut command = std::process::Command::new(shell.executable());
          command.args(args);
          
          // Space added before `source` to automatically ignore it in history.
          let mut source_command = " ".to_string();
          shell
              .run_script(&mut source_command, temp_file.path())
              .into_diagnostic()?;

wolfv · February 13, 2025, 10:40am

Hi @phreed thank you for bringing this to our attention (speaking as a pixi developer). We would love to fix this.

Could there be a restriction to execute / source files from the temp folder in Bluefin?

Is there an easy way for us to debug this locally?

wolfv · February 13, 2025, 3:02pm

I opened a PR here: fix: flush shell activation file after writing and add some debug info by wolfv · Pull Request #3130 · prefix-dev/pixi · GitHub and you can grab the linux-x64 binary from CI here: https://github.com/prefix-dev/pixi/actions/runs/13309032492/artifacts/2585894310

Is that something that can help? Or do you need the linux-aarch64 ones?

phreed · February 13, 2025, 6:01pm

It appears that the problem is due to an interaction with starship.
I commented out the following at the end of /etc/bashrc

eval "$(starship init bash)"

Now pixi shell behaves as advertised.

j0rge · February 13, 2025, 6:14pm

Thanks for the assist, please let me know if there’s anything we need to do on our end to make the experience better! Thanks for working on pixi!

phreed · February 13, 2025, 6:33pm

It looks like @wolfv has fixed the issue.

wolfv · February 13, 2025, 7:08pm

Awesome, thank you for testing! This one was our fault!

phreed · February 13, 2025, 7:09pm

Have you thought about using pixi instead of brew on x86 as well as arm?

salim · February 13, 2025, 7:18pm

I have no experience with pixi yet and not the breath to figure out myself right now, so I just dare to ask: Any chance pixi would be more polite regarding PATH pollution than Homebrew?

phreed · February 13, 2025, 7:40pm

Maybe, pixi has several features that may help.
To start pixi places its global directory at the start of the PATH much like brew.
With pixi a package is either added to a project or installed globally.
To mimic brew behavior you would do a global install.
When doing a global install you can decide what to expose and how it is to be exposed.
Thus, if the default exposed function conflicts with a system function you can give it a distinct name.
If there is already a matching exposed name the install fails.
Here is an example where a previously installed package has the same exposed name.
e.g.

❯ pixi global install starship
Error: 
  × Couldn't install starship
  ╰─▶ Exposed name starship already exists

For more detail I defer to @wolfv .

salim · February 13, 2025, 8:10pm

The problem with Homebrew is that it also exposes (transitive) dependencies to the global PATH if they’re required by the installed tool. Does pixi manage to avoid that (by “sandboxing” the installed tool somehow)?

wolfv · February 13, 2025, 8:24pm

Yes, pixi does exactly that. When you globally install a tool, you create individual environments for each tool, and we only expose the executables from the package that you are interested in. This is completely controllable via the “global manifest file”.

version = 1
[envs.coreutils]
channels = ["conda-forge"]
dependencies = { coreutils = "*" }
exposed = { tee = "tee", md5sum = "md5sum", split = "split", cat = "cat", shuf = "shuf", mkfifo = "mkfifo", pathchk = "pathchk", runcon = "runcon", expand = "expand", tty = "tty", basename = "basename", install = "install", nice = "nice", truncate = "truncate", echo = "echo", du = "du", ptx = "ptx", join = "join", pwd = "pwd", test = "test", csplit = "csplit", sort = "sort", whoami = "whoami", touch = "touch", unlink = "unlink", b2sum = "b2sum", sleep = "sleep", fmt = "fmt", stty = "stty", logname = "logname", chgrp = "chgrp", printenv = "printenv", seq = "seq", uname = "uname", sha224sum = "sha224sum", od = "od", date = "date", base64 = "base64", realpath = "realpath", readlink = "readlink", dircolors = "dircolors", timeout = "timeout", tac = "tac", numfmt = "numfmt", wc = "wc", basenc = "basenc", comm = "comm", nproc = "nproc", expr = "expr", cksum = "cksum", printf = "printf", groups = "groups", chcon = "chcon", factor = "factor", tail = "tail", env = "env", pr = "pr", head = "head", kill = "kill", uniq = "uniq", stat = "stat", link = "link", sum = "sum", tsort = "tsort", mknod = "mknod", users = "users", dd = "dd", who = "who", sha1sum = "sha1sum", mktemp = "mktemp", cut = "cut", sha256sum = "sha256sum", dir = "dir", mkdir = "mkdir", nl = "nl", shred = "shred", fold = "fold", rmdir = "rmdir", sha384sum = "sha384sum", mv = "mv", dirname = "dirname", id = "id", base32 = "base32", pinky = "pinky", ln = "ln", hostid = "hostid", chroot = "chroot", ls = "ls", true = "true", cp = "cp", sync = "sync", yes = "yes", unexpand = "unexpand", chown = "chown", chmod = "chmod", uptime = "uptime", rm = "rm", vdir = "vdir", false = "false", sha512sum = "sha512sum", "[" = "[", tr = "tr", paste = "paste", nohup = "nohup" }

[envs.git-lfs]
channels = ["conda-forge"]
dependencies = { git-lfs = "*" }
exposed = { git-lfs = "git-lfs" }

You can modify the file by hand or use pixi global install foobar

The exposed binaries can also be renamed - which allows you to install multiple versions side by side (for example, you could type exposed = { git-lfs-old = "git-lfs" }).

Unlike Homebrew, pixi (or really the conda ecosystem) also comes with a SAT solver and old versions are never deleted. That means you can still install python=3.5 or whatever.

Pixi also does not care where you put it on the PATH

wolfv · February 13, 2025, 8:25pm

Note that you can also have multiple packages in a single environment, which is particularly useful when you have plugins and the likes

salim · February 13, 2025, 8:45pm

That sounds really promising!

@j0rge What’s your sentiment regarding Provide `pixi` Out-of-the-Box?

j0rge · February 13, 2025, 9:41pm

You mean like this?

github.com/ublue-os/bluefin

Add pixi to dx for conda support

opened 07:10PM - 13 Feb 25 UTC

castrojo

good first issue help wanted dx parity

First class access to the conda ecosystem has become more important for us (AI t…ools, etc). We ship this in lts already: https://github.com/ublue-os/bluefin-lts/blob/main/build_scripts/overrides/aarch64/05-pixi.sh Also upstream is engaged with helping out a user on our forums and that's awesome. Docs bullet will read something like: - Pixi for integrated conda support Or whatever upstream feels is a more apt description.

For all the minutea (adding update support etc) please file issues in the bluefin repo and we can tighten it up before F42. We can certainly add it now though.

Topic		Replies	Views
Ptyxis does not play well with pixi Bluefin	2	161	December 13, 2024
Setting up the Ptyxis Terminal Bluefin developer-experience	15	10420	August 9, 2024
Provide `pixi` Out-of-the-Box Bluefin	1	70	February 13, 2025
Switching to zsh on Aurora (not Aurora-DX) Aurora	7	482	January 24, 2025
Ujust bluefin-cli integration with zsh Bluefin	4	195	December 23, 2024

`pixi shell` blocks

Related topics