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

Re: Refs to Conda - giving it a try after meeting Björn at a conference

Hi Matúš,

On 24.09.19 09:58, Matus Kalas wrote:
Hey all, it's super cool to see this happening!!

I'm also very strongly supporting the idea of bioconda+debian~>biology
training material(s), including the Jugend vorsicht! (Youth beware? :D)
I kind of guess that you know, but https://www.jugend-forscht.de/ are
doing good stuff. Admittedly, I have no idea about orthologous
activities in other countries, but there certainly are.

I'll be in the BioHackathon in Greater Paris as well.

Almost like a little Debian sprint :o)

We have scheduled our next for Berlin. Should we have an interim one to
speed things up?

For the ELIXIR folks: Do you think we should apply for (an)
Implementation Study|ies around these integrations? Would that make
sense, and would it have a chance to get funding? In addition to the
Tools Platform, the Training Platform might be interested. (there
could be positive implications also for training, Galaxy,
BioContainers(?), ...)

What came to mind is an auto-translation of the conda environment.yml to
different Linux distributions with the help of bio.tools.



On 2019-09-24 01:03, Steffen Möller wrote:
On 22.09.19 17:04, Andreas Tille wrote:
Hi Steffen,

On Sun, Sep 22, 2019 at 04:36:47PM +0200, Steffen Möller wrote:
Thanks for this effort.  I've seen your commits.
Thank you for preparing the udd.

The conda:channel syntax was meant to prepare for the many flavours of
conda that are out there.
I've seen this but its useless (as I explained in debian-blends).
Please do *not* only change the template since it has no effect at all.
Somehow a second commit got stuck while on the train.

The root is with conda-force. And this is also
where the Debian-Science-maintained package datamash is:
https://anaconda.org/conda-forge/datamash .
Lets see once the first datamash registry will arrive.  These should be
documented in https://wiki.debian.org/UpstreamMetadata as a valid
Registry.  Once it is documented there it will be implemented in the
code.  Everything else is error prone and does not bring us forward.
Good idea, will do that.

My preferred way to perform these additions would be by assigning a list
of Debian package names and conda recipe/package names. Then let some
bot perform the editing. The idea to  check out everything locally while
working on my laptop is nothing that I am prepared to do. But you are
right. I should stop doing this all via the salsa web interface.


Reply to: