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:
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?
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?
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:
use conda to download (curated/safely built) environments (eg, python2 and python3) to the users HOME (could be confined)
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’)
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).
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.
As a newcomer to snaps this is a pretty terrible experience. Looking for the correct way to install conda on ubuntu 18.04; and I see that snap has a simple updating installer. Great!
But your install pages are only glossy ads; there is no room for useful comments, like “this snap does not work.” Instead we need to dig into dev forums to find out that, alas, “this snap does not work.”.
“This app install experience does not work.”
So for the beta install (I only see beta and edge, even though this forum mentions classic, I don’t get that option), what is the recommended way to incorporate ~/snap/conda/1/.bashrc ?
I had conda installed and was running into this. I uninstalled and then reinstalled by running the following: snap install --classic --edge conda but conda init bash still fails to actually set things up so that I can activate conda environments.
$ conda init bash
no change /snap/conda/current/condabin/conda
no change /snap/conda/current/bin/conda
no change /snap/conda/current/bin/conda-env
no change /snap/conda/current/bin/activate
no change /snap/conda/current/bin/deactivate
no change /snap/conda/current/etc/profile.d/conda.sh
no change /snap/conda/current/etc/fish/conf.d/conda.fish
no change /snap/conda/current/shell/condabin/Conda.psm1
no change /snap/conda/current/shell/condabin/conda-hook.ps1
no change /snap/conda/current/lib/python3.7/site-packages/xonsh/conda.xsh
no change /snap/conda/current/etc/profile.d/conda.csh
no change /home/myusername/snap/conda/1/.bashrc
No action taken.
when I try to activate something, I get this:
$ conda activate
CommandNotFoundError: Your shell has not been properly configured to use 'conda activate'.
To initialize your shell, run
$ conda init <SHELL_NAME>
Currently supported shells are:
- bash
- fish
- tcsh
- xonsh
- zsh
- powershell
See 'conda init --help' for more information and options.
IMPORTANT: You may need to close and restart your shell after running 'conda init'.
The error you’re seeing here seems to imply that the conda snap needs to look at /home/.../.bashrd and not /home/.../snap/conda/1/.bashrc. I think a new forum topic on this is warranted, the original discussion here is about granting classic confinement to conda, not necessarily for bugs/support with the conda snap.
@jjhelmus you could modify your snap to try to get the user’s real $HOME via something like:
I have not had the time to update this snap since the classic confinement request was granted. I do not foresee having time to do this in the near future. Given the less the poor experience this snap provides to the users I am looking to remove the beta and edge releases.
The miniconda installers already provide a method for users to install conda on any Linux system. I like the idea of a conda snap but do not have the time to maintain it.
