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


#1

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:

...
plugs:
  conda-user-dir:
    interface: personal-files
    write: 
     - $HOME/.conda
     - $HOME/.condarc
     - $HOME/.bashrc

apps:
  conda:
    command-chain:
      - check-connect.sh
    adapter: full
    environment: 
      HOME: /home/$LOGNAME
    command: bin/conda
    plugs:
      - network
      - home
      - conda-user-dir

#2

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.


#3

@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?


#4

@pedronis - ping


#5

I don’t follow this line of reasoning completely. Conceptually there is still a separation. Could you expand what you mean/are thinking here. Is there an issue that activate itself cannot be confined? or can it?


#6

conda is a tool for managing and ‘activating’ shell environments (which can be thought of as workspaces). The tool itself could be confined (ie, downloading/updating/managing the environments) but the use of those environments necessarily must be unconfined (all the ‘activate’ step does is set shell environment PATH/etc to point to one of the downloaded environments).

Eg:

  1. use conda to download (curated/safely built) environments (eg, python2 and python3) to the users HOME (could be confined)
  2. use conda to activate the environment (eg, python2; due to how the shell and conda operate, cannot be confined at this time due to ‘3’)
  3. use the activated environment (eg, run ‘python’; cannot be confined until a future where prompting work is far enough along (and ‘2’ becomes a confined subshell))

My point was that because of ‘3’ and its impact on ‘2’, there really isn’t a point to perform strict confinement at this time since the end result is to run the downloaded environment unconfined. Plus, strict confinement breaks the documented user experience for conda activate (unless you use a confined subshell, which breaks use of the activated environment).


#7

@pedronis - if you have a moment, can you review this based on my answer to your question? Thanks!


#8

@pedronis - I believe I answered your question. Can you review?


#9

It seems ATM both conda and snapd would not be up to isolate the downloading/setting up of an environment, vs using/activating it. That would be the ideal scenario.

That relates to the long term idea of making classic, or subsets of classic more like an interface vs a full snap confinement mode. There’s also interesting questions when one command leads to very different functionality that could use different levels of isolation.

Given what is currently available it seems classic makes sense.


#10

The requirements are understood. The publisher was vetted at the Snapcraft Summit. Granting use of classic. This is now live.