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