General issues with converting from conda to pixi

vigneshmanick commented 6 months ago

Hello Pixi devs,

I have listed some issues that i have faced when testing moving to pixi from conda.

Installation

In corporate environments the $HOME folder is not necessarily in the local machine but rather another mounted NFS drive which is usually restricted in space and also slow. For development in such environments the tools are installed in another folder that is available in the local machine. (e.g /scr/).
Same applies for the PIXI_CACHE_DIR folder. This should also not default to $HOME.
Changing the installation locaion via the PIXI_HOME env variable is supported, but this information is not readily apparent in the documentation.

Suggestions:
1. Provide CLI argument that allows setting the install location and the cache folder.
2. Pixi info should print out these locations also

Post installation changes

The update to the PATH variable should be changed since it has consequences on pixi global install <tool>. If a tools is already available on the machine and if pixi global install is done for the same, then it doesn't work because of how the variable is set currently. Example export PATH=$PATH:/scratch/user/tools/pixi/bin. Since the pixi values are appended to the PATH the tools from pixi are masked by the tools in OS. Conda prepends to PATH.

Suggestion: It should be changed to export PATH=/scratch/user/tools/pixi/bin:$PATH
The pixi activation is added to bash_profile and not .bashrc, this will result in non login shells not having pixi avaialble. Generally bash_profile will already source the bashrc file in one form or other (see sampel below). Conda updates the .bashrc file if i am not mistaken.
```
# Either sth like this

if [[ $- == *i* ]]; then . ~/.bashrc; fi

# or like this

if [ -r ~/.bashrc ]; then
    source ~/.bashrc
fi
```
Suggestion: Add the changes similar to conda to .bashrc instead of in the bash_profile which will make it avialable for both login and non login shells.
The auto complete magic echo 'eval "$(pixi completion --shell bash)"' >> ~/.bashrc is appended to the end of the .bashrc file. This is fine for cases where the file doesn't contain conda activation block but for cases where a conda activation block is present, the modifications should be above this section since conda recommends it's data should be at the end of the file.

Suggestion:

It would be preferable if pixi related changes are made above the following lines to reduce friction in moving from conda
```
# >>> conda initialize >>>
# !! Contents within this block are managed by 'conda init' !!
```
Maybe instead of putting the values (e.g cache, pixi_home etc.) in the bashrc, add these directly the the global pixi configuration?. This will help in all the global settings to be consolidated to a single file and also easier to modify. Correct me if i am wronng, currently the global configuration file should be created manually?
Conda offers a command to clean the cache and other temporary data, pixi should offer something similar (e.g pixi clean cache)

Converting `environment.yml` to pixi environment

Issues i faced when importing an existing conda env into pixi project via pixi init --import environment.yml

On my work linux machine i got the following error.
```
× The current system has a mismatching virtual package. The project requires '__linux' to be at least version '5.10' but the system has version
│ '3.10.0'
```
I searched the issues and found that the following needs to be set which is not readily apparent in the documentation.
```
[system-requirements]
linux="3.10.0'"
```
For why the version in my case is a lower value, we use RHEL-7.9 and this is generally the standard in HPC, Uni / Research / enterprise setting. Soon this will be EOL and upgrade most probably will be to RHEL-8.9 which has the version RHEL 8.9 | 4.18.0-513.5.1.el8_9 .

I don't fully understand why the __linux version should be that high since the conda packages are built usually via the conda compiler tools and manylinux image which has very low os requirements (think it's using the centos7 image). Atleast none of the packages that i use have the high OS version as shown in the error by PIXI.

Suggestion: It would be good if the above error is removed and the required block directly added to the pixi.toml

Dependencies

I use a mix of both conda and pypi dependencies and and the pip config does not use the pypi registry but a custom self hosted registry e.g global.index-url='https://nexus.somename.net/repository/pypi/simple'

Some other dependencies are downloaded from custom registries that are specified using the --extra-index-url option in pip. For example the vtk package has an osmesa variant for windows is available only via kitware registry and can be installed via pip using the following requirements.txt.

-i https://gitlab.kitware.com/api/v4/projects/13/packages/pypi/simple
vtk-osmesa

how do i specify for example, global.index-url='https://nexus.somename.net/repository/pypi/simple' and --extra-index-url in the dependencies in pixi?

Connectivity issues

During installation i got the following error, i realized that this was due to the drive that had the cache folder running full.
```
x failed to read 'paths.json'
`-> EOF while parsing a value at line 1 column 0
```
Suggestion: The error above could include the diskspace information too?
The most important of all, to connect to internet the machines use proxy and also a custom ca-certificate. This is configured on per application basis and for conda this is defined in the .condarc file via the proxy and via conda config --set ssl_verify <pathToYourFile>.crt settings.

Users have no possiblity to update these settings globally since admin/root rights are generally not provided for these machines. As of now, pixi install works only when i am not in the office network/machines that have custom certificates already added to the root certificate store. The errors for this case have been detailed in https://github.com/prefix-dev/pixi/issues/1035.

Suggestion: It would be good if pixi also would provide similar setting for proxy and custom ca certifacte
On another machine the anaconda.org was part of no_proxy env variable and due to that the install failed with cannot resolved url.

Suggestion: Check and warn the users if they have set the these and other required urls no_proxy .

Thanks for your awesome tool and your quick response. If i have made any mistakes feel free to correct me.

Update: 29.03.2024 updated description with further points Update: 31.03.2024 Added suggestion for cleaning up cache

ruben-arts commented 6 months ago

Thank you @vigneshmanick, this is really useful information, I'll take a more in depth look later and probably move some items into issues or PR's!

vigneshmanick commented 6 months ago

@ruben-arts thanks for the response, i have some further points regarding the issue. Would you prefer that i update the issue description here or create another ?

tdejager commented 6 months ago

Please update it here, I don't think we've gotten around creating individual issues out of them yet :) Thanks for all the testing!

vigneshmanick commented 6 months ago

Have updated the description and might add more points as and when i face them.

james-vincent commented 6 months ago

The ability to add [system-requirements] from the pixi command line would be very useful. As far as I can tell it must be manually added to pixi.toml. This makes automation clunky. Everything else can be added with pixi - except this.

j-bac commented 5 months ago

Talking about requirements.txt, it would be useful to be able to pixi add requirements.txt or pixi init --import requirements.txt

kxmh42 commented 1 month ago

I have a problem related to this issue: PATH is modified by the Pixi install script only in .bashrc, and in most systems .bashrc is configured not to work in non-interactive shells, which means I can't execute remote commands such as ssh myhost pixi global add blabla, as they are executed in non-interactive shells.

kxmh42 commented 1 month ago

I investigated it a bit more, and it turns out that it is annoyingly non-obvious how to properly add something to PATH so that it works in all typical circumstances. Basically we want the PATH to be updated in both interactive and non-interactive shells, we should add the appropriate commands:

in bash: to the beginning of .bashrc (before the check if shell is interactive, which is usually at the top of the file)
in tcsh: to the beginning of .tcshrc (before the check if shell is interactive, which is usually at the top of the file)
in zsh: to .zshenv (which is always executed, unlike .zshrc, which is only executed by interactive shells)

In other shells, such as fish and xonsh, the rc files are always executed, so appropriate commands can probably be added to the end of the rc file.

However, the problem with adding it to PATH at the beginning of .bashrc/.tshrc is that the PATH might be modified later in the file. With Pixi added to PATH at the end of the file, we can ensure it is listed first. So it's a matter of weighing pros and cons of each solution.

vigneshmanick commented 1 month ago

for bash you could use $BASH_ENV to set values for non-interactive shells. I don't think it's a good idea to put any values before the check for interactive/non interactive is done. Generally all values in bashrc are set after this check and pixi is no exception here.

kxmh42 commented 1 month ago

I agree, however it would be better for the Pixi installer to update .zshenv instead of .zshrc, to make Pixi available for non-interactive shells.

prefix-dev / pixi