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:
https://know.anaconda.com/TOS.html
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:
https://github.com/conda/conda/issues/1235
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.
Bye,
Tony.
--
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: