Re: Request for discussion - what should bio.tools et al. do for us?
[In brief, can Debian Med members have easy write access to the metadata in bio.tools for the software they reference and we package, and can we use that to strengthen out ties ?] Le Wed, Jun 16, 2021 at 07:38:37PM +0200, Steffen Möller a écrit : > > I had joined the bio.tools folks this afternoon for a pre-meeting of an > EU project to give the registries a boost. I was asked what Debian would > want from them. Hi Steffen, I just looked for my favourite tool, LAST, in bio.tools and in Debian: https://bio.tools/last https://packages.debian.org/sid/last-align https://tracker.debian.org/pkg/last-align First, it would be great to cross-reference each other. But what is the canonical URL for our upstream/metadata files ? The sources.debian.net server allows to find it easily for the package in Sid, but during freezes there may be a more up-to-date one in experimental… https://sources.debian.org/src/last-align/sid/debian/upstream/metadata/ The Salsa URL allows to update the metadata without uploading the package (that was my original intention), but is not easily discoverable once there are packages outside Debian Med. https://salsa.debian.org/med-team/last-align/-/blob/master/debian/upstream/metadata In the past I attempted to expose the data on a server that I called "Umegaya" but I failed to maintain it in the long run. There is also the UDD if I remember well, but I can not find anymore how external people can get information from it. Once bio.tools can discover which softare that they reference is packaged by us, it would be great if they can link to us. Then, we also have the opportunity of sharing metadata. For example in LAST, it is outdated (homepage changed). Getting it fixed automatically would be a dream. On the other hand, we could imagine that if Debian Med members could easily update bio.tools metadata, maybe our routine-update script could pull it for the packages that have a Registry bio.tools entry in upstream/metadata ? Finally, having an opportunity to advertise ourselves and our specificities. At work we had a discussion on whether we can become a green campus by 2030. Electricity production on our island is close to 100% fossile fuel. I really like our effort made on packages like last-align to squeeze out computing power by having multiple cpu-optimised binaries chosen transparently. This is something other platforms do not offer. Other example, while LAST's biocontainer has the coreutils installed, other ones have only busybox. Although we do not distribute containers by ourselves, it would be good to have a place to advertise that if one uses a minimal image plus apt install our packages, they can be sure that scripts with grep -P or sort -V are not going to fail :) And of course we have our strong checks on licenses, that make us unique (and me sometimes furious in the past during NEW processings): everything we distribute is Free, while in other projects the prossibility to be forbidden to use in commercial proojects is always lurking (for instance with UCSC genome tools source files or MEME source files being included and underdocumented). Have a nice day ! -- Charles Plessy Nagahama, Yomitan, Okinawa, Japan Debian Med packaging team http://www.debian.org/devel/debian-med Tooting from work, https://mastodon.technology/@charles_plessy Tooting from home, https://framapiaf.org/@charles_plessy
Re: Request for discussion - what should bio.tools et al. do for us?
Hi Steffen, On Wed, Jun 16, 2021 at 07:38:37PM +0200, Steffen Möller wrote: > Hallo, > > I had joined the bio.tools folks this afternoon for a pre-meeting of an > EU project to give the registries a boost. I was asked what Debian would > want from them. And while I do not think that my answer was completely > off, we should possibly come up with a consensus on this list. Here my > shot, hoping to seed further discussions, not only among current > contributors to Debian Med: > > * Awareness - something better than our task lists I'd say s/better/other/ in the sense that it is more focussed on user needs. The tasks lists are fullfilling a some needs from a Debian perspective but they are weak in terms of a bioinformatican view (regarding better categorisation etc. which is probably a strength of bio.tools). I'd love to repeat that I personally do not consider this a problem of the technique behind but rather the fact that our data are pretty weakly maintained. > - of Debian as a whole > - of packages Debian offers > - for the possibiliy that > + Debian can be joined and that there is mentoring for newbies > + companies offer support for Debian/Ubuntu where this is desired > > * Guidance - something better than our Excel sheet I'd love if you would use the term "Spreadsheet" since the program you are mentioning is neither used nor needed to work with this sheet. I'm also not sure if the term "better" should be replaced by "more visible" and may be "easier to maintain". > - packages that Debian offers for particular tasks/problems/workflows > - packages that Debian misses (but conda/guix have or workflow X > depends on that is already 90% covered with Debian packages) > - pointers to new technical developments that Debian should look at > > * workflows meta-continuous integration testing > - workflows should come with examples how to run them > - Debian has reproducible builds - can we have repoducible workflow > tests > - Some distribution-independent testing environment should compare > results between conda/guix/Debian/brew... > > * Improved compatibility > - "apt-get install conda", please. We are not too far from that but > need some guidance for the last meters. When I was laying down my work on this it was just some build time tests away but I was simply lacking knowledge whether these were ignorable or not. However, I fail to see in how far bio.tools can help us getting conda packaged. > - avoid "which python installation"-hassle with /usr/bin/python* vs > conda installation shebang lines I also do not see any connection to bio.tools here - but may be I'm misleaded about their scope. Kind regards Andreas. -- http://fam-tille.de
Request for discussion - what should bio.tools et al. do for us?
Hallo, I had joined the bio.tools folks this afternoon for a pre-meeting of an EU project to give the registries a boost. I was asked what Debian would want from them. And while I do not think that my answer was completely off, we should possibly come up with a consensus on this list. Here my shot, hoping to seed further discussions, not only among current contributors to Debian Med: * Awareness - something better than our task lists - of Debian as a whole - of packages Debian offers - for the possibiliy that + Debian can be joined and that there is mentoring for newbies + companies offer support for Debian/Ubuntu where this is desired * Guidance - something better than our Excel sheet - packages that Debian offers for particular tasks/problems/workflows - packages that Debian misses (but conda/guix have or workflow X depends on that is already 90% covered with Debian packages) - pointers to new technical developments that Debian should look at * workflows meta-continuous integration testing - workflows should come with examples how to run them - Debian has reproducible builds - can we have repoducible workflow tests - Some distribution-independent testing environment should compare results between conda/guix/Debian/brew... * Improved compatibility - "apt-get install conda", please. We are not too far from that but need some guidance for the last meters. - avoid "which python installation"-hassle with /usr/bin/python* vs conda installation shebang lines Best, Steffen
