| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| conda [2024/06/06 08:11] – jansen | conda [2025/01/27 15:47] (current) – [Disk usage] jansen |
|---|
| Now that you have the ''conda'' package manager available, you can use it to complete the setup. | Now that you have the ''conda'' package manager available, you can use it to complete the setup. |
| One bit of setup that ''conda'' insists on, is to add some initialization code to the login environment, so conda will always be active (''conda init bash'' or ''conda init tcsh''). However, see "pitfalls" section below. | One bit of setup that ''conda'' insists on, is to add some initialization code to the login environment, so conda will always be active (''conda init bash'' or ''conda init tcsh''). However, see "pitfalls" section below. |
| | |
| | Note that with the system default version of conda, this init step is not necessary! |
| |
| Other bits of setup can be done through the ''conda config'' commands, see ''conda config --help'' for details. It is also possible to edit the ''$HOME/.condarc'' directly if you know what settings you want (eg by looking them up online). | Other bits of setup can be done through the ''conda config'' commands, see ''conda config --help'' for details. It is also possible to edit the ''$HOME/.condarc'' directly if you know what settings you want (eg by looking them up online). |
| If unsure what packages are available, use ''conda search packagename'' to search for any matching names (wildcards allowed, should be enclosed in quotes). To list installed packages, use ''conda list''. | If unsure what packages are available, use ''conda search packagename'' to search for any matching names (wildcards allowed, should be enclosed in quotes). To list installed packages, use ''conda list''. |
| ===== Pitfalls ===== | ===== Pitfalls ===== |
| | ==== Interference with system python environments ==== |
| As you can see above, the default behaviour when installing conda or running ''conda init'' is, to add some code to your .bashrc or .tcshrc to activate conda on every shell and in every window you open. That may sound like a nice feature, until you realize, that a custom version of python with a custom set of packages may wreak havoc on any environment that relies on the system default version. And there is a lot of software that happens to be written in python, or linked with it, including big parts of the Gnome and Cinnamon desktop applications. So, if you happen to set up a non-standard version of python as default, it might not be possible for you to log in in these desktop environments any more. Or even worse, if you need to install non-standard versions of gcc or its libraries, you might not be able to run a big part of the system software any more. | As you can see above, the default behaviour when installing conda or running ''conda init'' is, to add some code to your .bashrc or .tcshrc to activate conda on every shell and in every window you open. That may sound like a nice feature, until you realize, that a custom version of python with a custom set of packages may wreak havoc on any environment that relies on the system default version. And there is a lot of software that happens to be written in python, or linked with it, including big parts of the Gnome and Cinnamon desktop applications. So, if you happen to set up a non-standard version of python as default, it might not be possible for you to log in in these desktop environments any more. Or even worse, if you need to install non-standard versions of gcc or its libraries, you might not be able to run a big part of the system software any more. |
| | |
| |
| ==== Solutions to these pitfalls ==== | ==== Solutions to these pitfalls ==== |
| |
| |
| | ==== Disk usage ==== |
| | Conda environments can be big. No wonder, since they can contain a full python install, libraries, compilers and many other tools. And as with most programs, conda defaults to store all of this in your $HOME since that is the one place that is known to exist on any UNIX system. |
| |
| | So, you will want to change this location to something with more space, e.g. a local ''/data1'' or ''/data2'' disk. |
| | This can be done in ''.condarc'' by settings ''envs_dirs'' and ''pkgs_dirs'' to a chosen location. If you don't have a ''.condarc'' yet, create one with a text editor and add something like: |
| |
| | auto_activate_base: false |
| | envs_dirs: |
| | - /data2/yourname/conda/envs |
| | pkgs_dirs: |
| | - /data2/yourname/conda/pkgs |
| | |
| | Additional tip: having the environments locally on your workstation has advantages and disadvantages. One advantage is, that with the same setup, you can have a different instance of an environment on another machine, which is convenient if that other machine is not running the same Linux version as your desktop (eg compute nodes and vdesk). |
| | Disadvantage: if you occasionally use another desktop, you will not see your environments. In that case, use ''/net/computername/data2'' in stead of ''/data2''. in the configuration. |
| | |
| | If you are making this change when you already have some conda environments (in $HOME/.conda), you can move them to the new location. And just to be sure, in case there are already hard-coded path names in the environment, make a symbolic link. So, using the example .condarc shown above: |
| | mv .conda /data2/yourname/conda |
| | ln -s /data2/yourname/conda ~/.conda |
| | |
