Classic request for conda [Was: Auto connect request for conda]


conda is a cross platform package and environment management system. Environments and configuration files are stored in the user’s home directory in the .condarc file and .conda directory. The snap requires read/write access to these files as well as .bashrc so that users can install shell interactions using conda init bash. Conda environments cannot be activated unless these shell interactions are sourced, either manually or during shell startup.

The snap is currently using the personal-files interface:

    interface: personal-files
     - $HOME/.conda
     - $HOME/.condarc
     - $HOME/.bashrc

    adapter: full
      HOME: /home/$LOGNAME
    command: bin/conda
      - network
      - home
      - conda-user-dir


I spoke with conda upstream in person and use of ~/snap/conda/current/.conda* doesn’t fit their application and documentation. They are the clear owner of this directory and file and, through discussion with them, conda has a very stable config file that is unlikely to change, so there is no problem with granting write access wrt compatibility issues with conda installed via non-snap means (and potential future issues are understood by upstream).

As for .bashrc, we’ve been discussing in person alternative paths forward.


@pedronis - while this started as an auto-connection request for personal-files, I’m converting this to a request for classic after discussing with @jjhelmus. This is a (somewhat) new class of classic request. I’ll summarize the conversation I had with @jjhelmus and upstream conda, then express my thoughts.

conda is essentially an application for setting up workspaces, or in conda parlance, environments. These ‘environments’ are setup and used through user-driven commands in the user’s shell via the conda command. conda does not have any services that run in the background. Typical usage consists of running conda commands to configure the shell for conda, install binaries and other files (which build the different conda environments) from a signed repository into the conda directory (defaults to ~/.conda). Once a conda environment is setup, the user may activate the environment by running conda activate <environment>, which modifies PATH to include the binaries which comprise this specified environment. The user may then execute commands from the conda environment via this user’s shell session. Eg, the user might use conda to create a python2.7 environment and a python3.7. Neither are available in PATH until the user runs ‘conda activate’ and once that is run, they are available in that specific shell session and those binaries run unconfined.

We discussed the possibly of making conda a strict mode snap, and while this is technically possible, there isn’t a meaningful benefit for strict mode at this time because while the tool might run confined, the applications in each conda-environment should not run under conda confinement.

This is a form of installer snap which we’ve not typically allowed in the store, however I think there are some important differences that are worth considering. The tool is a command line tool meant to setup conda environments whose binaries are built in upstream-conda-owned build servers and therefore come from a curated and signed repository. The installed applications are not put in the system PATH. The installed applications are not put in the user’s PATH unless the user runs ‘conda activate’. conda has no daemons and performs no management of the device (eg, via apt/yum/…). I suspect this is a new class of classic snap that is more inline with virtualenv and friends. That said, it isn’t clear if conda could ever not be classic, but it might be possible once future prompting work is available and ‘conda activate’ runs a confined subshell rather than updating the current unconfined shell’s PATH, etc.

Upstream was vetted at the Snapcraft Summit Montreal 2019 and the requirements are understood. Since this is a new class of classic snap, @pedronis, can you weigh in?