Git bash on windows no longer supports pixi shell

[tony-p]

Checks

• I have checked that this issue has not already been reported.

• I have confirmed this bug exists on the latest version of pixi, using pixi --version.

Reproducible example

on windows in git bash

pixi shell

Issue description

On windows in a git bash terminal, pixi shell fails with error

$ pixi shell
  x Unsupported shell: Bash(Bash)

Expected behavior

pixi shell should work as expected

[ruben-arts]

Hey, sorry for the late reaction.

I've been debugging this and it is not as easy as thought on first glance. The issue is that our current implementation for bash is depending on some unix specific dependencies. (PtySession) Which isn't available, so we have to write this interaction ourself. Which is easy for PowerShell and nushell because the except a source file on start. But for bash you have to send a command to the running instance.

I'll look at it some more very soon, but if you have any ideas let me know!

[wolfv]

I wonder if one workaround can be to use

pixi run bash.exe

That should start a bash shell inside an activated environment. Would love to hear if that works - we could add it to our docs, or make that the default behavior on Windows (if it works well enough).

[tony-p]

sorry for slow reply (have been on leave). Just got around to testing and seems to work as desired for the a few test commands I threw at it. Thanks!

[jdblischak]

I went through the steps in the Basic usage page in both Ubuntu 22.04 (via WSL) and Git Bash. My observations:

• I confirmed the error with pixi shell
• I confirmed that pixi run bash.exe is a good substitute
• I noticed that the step pixi add python was noticeably slower in Git Bash compared to Ubuntu (despite running on the same hardware)

[wolfv]

@jdblischak thanks! About your last point - I think that might be related to the Windows file system just being slower? Although I am not sure how that maps to WSL.

[jdblischak]

I think that might be related to the Windows file system just being slower?

That is also my guess. My experience is that any code that touches the file system is noticeably slower on Windows. Just wanted to report to note that Windows users can't expect the same amazing speeds from pixi as those on a Unix file system (though of course pixi is still much faster than alternatives like conda on Windows, so they should still switch 🙂)

Although I am not sure how that maps to WSL.

That's the beauty of WSL. For the most part it behaves like you are running your code directly on Ubuntu, so pixi is super fast

[tony-p]

I believe windows defender might play a role in the speed as well as it wants to scan everything that is downloaded. Could be that WSL is able to sidestep Windows defender.

[W1M0R]

When I run pixi shell-hook --shell bash in a Git bash terminal on Windows, I get the following output (redacted for simplicity):

❯ pixi shell-hook --shell bash
export PATH="/c/Users/user2/myproj/.pixi/envs/default;/c/Users/user2/myproj/.pixi/envs/default/Library/mingw-w64/bin;/c/Users/user2/myproj/.pixi/envs/default/Library/usr/bin"

The PATH is exported incorrectly and needs to look like this for it to work in Git Bash:

export PATH="/c/Users/user2/myproj/.pixi/envs/default:/c/Users/user2/myproj/.pixi/envs/default/Library/mingw-w64/bin:/c/Users/user2/myproj/.pixi/envs/default/Library/usr/bin"

In short, the PATH separator must be corrected from ; to :.

Git Bash comes with a utility called cygpath, that can translate Windows path lists to the correct format:

❯ cygpath -u -p "C:\Users\user2\myproj\.pixi\envs\default;C:\Users\user2\myproj\.pixi\envs\blabla"
/c/Users/user2/myproj/.pixi/envs/default:/c/Users/user2/myproj/.pixi/envs/blabla

The cygpath utility can also translate the other way around:

❯ cygpath -w -p "/c/Users/user2/myproj/.pixi/envs/default:/c/Users/user2/myproj/.pixi/envs/blabla"
C:\Users\user2\myproj\.pixi\envs\default;C:\Users\user2\myproj\.pixi\envs\blabla

Perhaps pixi shell-hook --shell bash should detect if the cygpath.exe executable is in the path, and if so, then use it to normalize the PATH variable first.

Here is one method that implements this suggestion.

I also found the following related content:

1. feat: add shell-hook command #672

2. pixi/src/cli/shell_hook.rs

   Lines 73 to 79 in b7d3816

   	let result = activator
   	.activation(ActivationVariables {
   	conda_prefix,
   	path,
   	path_modification_behavior: PathModificationBehavior::default(),
   	})
   	.into_diagnostic()?;

That path_modification_behavior argument sounds promising.

A good enough solution might not even need to call into cygpath: just replace all ; with : in the PATH environment variable.

A workaround is as follows:

❯  eval "$(pixi shell-hook --shell bash | sed 's/^export [Pp][Aa][Tt][Hh]=/export PATH=/I; s/;/:/g')"
❯  echo $PATH
/c/Users/user2/myproj/.pixi/envs/default:/c/Users/user2/myproj/.pixi/envs/default/Library/mingw-w64/bin:/c/Users/user2/myproj/.pixi/envs/default/Library/usr/bin

[traversaro]

If you need to use Git Bash with pixi shell, a (definitely non perfect) workaround is the one that I explain in #514 (comment) .

[traversaro]

Follow up from #514 (comment) . If I run pixi shell-hook --shell path, the PATH is not correctly set for the reason specified by @W1M0R in #417 (comment) . fyi @ruben-arts

[maphew]

I believe windows defender might play a role in the speed as well as it wants to scan everything that is downloaded. Could be that WSL is able to sidestep Windows defender.

Perhaps try exclude the pixi folders. Powershell as admin:

#show existing exclusions
Get-MpPreference | Select-Object -ExpandProperty ExclusionPath

# add new ones
Add-MpPreference -ExclusionPath "D:\apps\pixi\bin"

# remove
Remove-MpPreference -ExclusionPath "C:\path\to\directory"

This can be overriden by group policy from the domain admin. There's no error when adding/removing in this case, so always finish with 'show existing' to see what took hold.

If you're on Win 11 try setting up a Dev Drive. I've done this at home and it improves things that use thousands of files (which is most any cross-platform project that includes linux).