Re: How to direct users to packages in Debian Med Re: Please do not do heavy changes on metapackages without discussion (Was: [Git][blends-team/med][master] Update bio - substituted (most) recommendations with suggestions)
On Wed, Jun 24, 2020 at 09:37:53PM +0200, Steffen Möller wrote:
>
> On 24.06.20 20:53, Andreas Tille wrote:
> > > you are right. I should not have done that. Sorry.
> > No problem - Git enabled an easy revert.
> Keep that patch :o)
I'd like to repeat: Use that *Branch*: demote-recommends It
was created exactly for that purpose.
> > Yes. It might be that its a rare case that a user wants the whole task
> > med-bio. I'd love to keep it basically untouched at least for the
> > moment. Simply create one or more new tasks and once these are properly
> > designed we can strip down med-bio.
> I like our tasks. And Bio-Linux has proven that a task list makes sense
> also when interpreted as an instruction for installation. But that is all a
> bit "yesterdayish". We are so much more connected now, so much more
> "built on demand" cloud/docker-wise - minimal latency is what we
> should promote.
Sure. But here every user has different needs and will create specific
docker images. Biolinux is the perfect example why med-bio and
med-bio-dev make sense as they are.
> > > My expectation is that our users are after on or two use cases/workflows
> > > that will vertically install all the required tools. They don't install
> > > five different workflows for RNA-seq analyses but decide for one (or
> > > two). We have no means to express "please make a pick among those
> > > packages that are equal", though.
> > So any workflow should have its own dependencies. A user who wants to
> > work with exactly one workflow will not install med-bio.
> Right. And even larger core facilities will only have a few workflows
> that they run all the time.
So they install the workflows as needed. That's fine.
> > > So, the bio-task list I suggest not to install anything.
> > But why? If a user does not want to install anything just not
> > installing med-bio is the easiest thing to do. I do not see any sense
> > in providing a metapackage that does nothing.
> You can install the suggested, still. So, nothing is taken away from anyone.
We are addressing the "normal" user who wants defaults. Demoting
everything from Recommends to Suggests is removing the last tiny bits of
differentiation we had before where we had some Suggests for good
reasons.
> The metapackage for bio should be substituted
I'm not yet convinced that a **substitution** is needed. If its not
right for you just ignore it. We possibly need more practical
**additions** and (as I really like to repeat) MAINTAIN THESE (which is
not the case currently)! So before we have sensible and maintained
additions please do not touch what works.
> with a guide tool to install
> the right set of packages and maybe run tests with a local setup.
Fine. Start writing this and lets see how it works in comparison
what we have.
> I would not mind to blend (pun intended) a bit of education with such a
> tool.
Perfect. Blend everything in a sandbox without touching production
stuff first. Than see what works better.
> > > And likely
> > > neither the bio-dev task list. And then we need something expressing
> > > (partial) functional equivalence to support a user-driven selection.
> > Please do so in med-bio-X1, med-bio-X2, etc. and maintain these tasks
> > afterwards. I consider all bio-something (something != dev) as not
> > properly maintained. We have added lots of packages that most probably
> > need to go into those tasks but I can not do this.
> Every workflow should represent itself as a regular package with its
> own set of dependencies to be functional. So, in my model, the number
> of packages you need for every workflow is - one. A bit tricky is the
> selection of optional packages that come with extra functionality - just
> think about what bcbio can all do. But - this can be described formally,
> too.
As far as I understand a workflow is a normal package with dependency
but not a metapackage. You started to break metapackages for no good
reason since these are just something else.
> What is missing is something like a equivalence-relationship to suggest
> that packages could be used exchangeably. That will need to be somewhat
> fuzzy, but I have little doubt that this can be achieved in a
> straight-forward manner from what we already have. And then we have
> your med-bio-X1, ..., -Xn clusters and their formal description with it.
>
> I did something like it a llloooonnngggg time ago
> (https://doi.org/10.1093/bioinformatics/15.3.219
> <https://doi.org/10.1093/bioinformatics/15.3.219>) and so have others
> somewhat similarly before me
> (https://doi.org/10.1016/0300-9084(96)84761-4) and after me (all the
> semantics folks and the latest effort I am aware of is by Mr bio.tools
> himself https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6378944/).
I think all this goes beyond what a simple metapackage is doing:
Defining a set of dependencies to help in *certain* (but not all user
applications).
> >
> > > My
> > > hunch is, and I think also the somewhat unspoken idea from the last
> > > sprints, that the EDAM ontology directs us towards it. For the moment,
> > > that annotation is too sparse and not detailed enough - but ... to
> > > describe a few tens of packages properly from where we then derive
> > > installation directions - that sounds doable. I imagine to derive the
> > > kind of lists you are vaguely describing in an automated manner from the
> > > UDD (which you had engineered to parse the d/u/edam annotation already).
> > If we could define criteria to auto-generate sensible tasks from UDD
> > by using EDAM ontology I'd be super happy since this would solve the
> > maintenance task.
>
> Great. Am swamped now but later this years we should have something.
> Let us also think about how to distinguish tasks that make users happy
> when installing all the packages in there (and dependencies with it)
> from tasks that make users happy by just installing one package in there.
Yes. Lets discuss whenever the time for discussion might be. But
lets discuss before implementing any changes.
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: