[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: don't copy from there Re: conda

On 24/05/2020 12:33, Rebecca N. Palmer wrote:
Note that we probably can't use code from this package to improve ours: I can't find any packaging code in the conda source on GitHub (BSD-3 licensed), and repo.anaconda.com has legal restrictions, including on redistribution:

Hi, Rebecca.

I'm not arguing against Debian-Med (re)packaging "conda", just bringing to everyone's attention that the Anaconda .deb repo exists. I routinely use "Miniconda" to bootstrap Bioconda. I also use with the wrapper that I posted here to avoid conflicts with the APT-managed system packages.

The Anaconda .deb installs "conda" in /opt/conda, which is where it should go. It does not put things in /usr/local where they are likely to be referenced by the system python/python3 etc. causing conflicts. I install into /opt/bioconda[23] and put the wrappers in /usr/local/bin.

However, end users of conda are probably planning to use it to install packages from there (its default repo), so would be subject to these restrictions anyway.  Hence, for such users, this is not a reason to avoid _using_ this conda .deb.

Yes, installing from the .deb is a lot more convenient than bootrapping "conda" using Minicona. That was the main reason to suggest Debian-Med packaging "conda".

Discussion in the conda bug tracker, mentioning both this repo and the possibility of adding conda to Debian itself:

I read the discussion there before posting my message to Steffen on the list. There are some very ill-informed comments in the discussion. In particular, installing packages into /usr/local causes many problems because, as I mentioned, the system-managed python* pick up packages in /usr/local as well as the system-managed libraries. Using "bioconda" with my wrappers avoids the "conda" envs conflicting with the system, but allows the envs to see the system-managed packages themselves.

In my experience, it is difficult to avoid people creating per-user installations of *conda or R for that matter, in their home directories resulting in ridiculous levels of file duplication and ill-configured instances leading to different problems for different users. I use a root-installed shared instance to avoid that and a wrapper to avoid the shared instance conflicting with any of the system-managed packages.

An Anaconda or Debian-Med .deb package is a very effective way to get control back into a 'democratised' software environment where users can customise their own view without causing problems for anyone else on the system, while still maintaining a well-managed core "conda" system.



Minke Informatics Limited, Registered in Scotland - Company No. SC419028
Registered Office: 3 Donview, Bridge of Alford, AB33 8QJ, Scotland (UK)
tel. +44(0)19755 63548                    http://minke-informatics.co.uk
mob. +44(0)7985 078324        mailto:tony.travis@minke-informatics.co.uk

Reply to: