oncoEnrichR icon indicating copy to clipboard operation
oncoEnrichR copied to clipboard

adding oncoEnrichR to Galaxy

Open bgruening opened this issue 4 years ago • 14 comments

Hi @sigven,

I talked yesterday to Eivind and he said a Galaxy integration is planned. Do you have a timeline for that? Is any help needed? The tool looks quite cool and I think we would have many users interested in it.

Ciao, Bjoern

bgruening avatar Aug 24 '21 10:08 bgruening

Hi Bjoern,

Thanks for reaching out and offering assistance. However, a Galaxy integration is not only planned, it is in place already! So not completely sure what Eivind was thinking of in that respect. With great contributions from @sveinugu and @FBernal-oPs, we have an instance running here:

https://oncotools.elixir.no

We have packaged the oncoEnrichR R package in a Docker container, and run the main function through the Galaxy interface, works well now it seems.

We have received some good response from several users, but unfortunately not from the reviewers :(

regards, Sigve

sigven avatar Aug 24 '21 10:08 sigven

Oh I checked the Toolshed and the bioconda repo and could not find anything. But now I see that you are running a local ToolShed. Any plan to push it to the main toolshed and maybe use conda packages and Biocontainers for it? We would like to deploy it to the European Galaxy server as well.

Thanks a lot! Bjoern

bgruening avatar Aug 24 '21 11:08 bgruening

I am generally all for this initiative, but I would need someone to help out.

@sveinugu @FBernal-oPs Is this something you can help with? Or anyone else in the Oslo team capable of helping out?

kind regards, Sigve

sigven avatar Aug 24 '21 11:08 sigven

@sigven Pushing the tool wrapper (more or less) as it is to the main tool shed will not be much of a problem and definitely something we can help out with. As far as I know, registering the DockerFile as a BioContainer dependency is also relatively straightforward, although I have never done this myself. But I believe this would also not be so much work. Translating the dependency into a conda package is typically more work, especially due to the use of R, so I cannot guarantee we have the capacity to help with the last bit.

The main question is who in the team has (or should gain) the required competence to do things like this. I will forward the request to the team.

sveinugu avatar Aug 27 '21 11:08 sveinugu

Bioconda should be easier than containers imho. And you will get a container for free :)

If you can make a start, similar to https://github.com/bioconda/bioconda-recipes/blob/69afcb713dbf226657bd3fc612b5ef14a0bd7e0e/recipes/r-goalie/meta.yaml

I can take it over and make sure it gets merged.

bgruening avatar Aug 27 '21 11:08 bgruening

Bioconda should be easier than containers imho. And you will get a container for free :)

If you can make a start, similar to https://github.com/bioconda/bioconda-recipes/blob/69afcb713dbf226657bd3fc612b5ef14a0bd7e0e/recipes/r-goalie/meta.yaml

I can take it over and make sure it gets merged.

I assumed the opposite, as BioContainers support DockerFiles (which is what we have)? Why is it not like that?

sveinugu avatar Aug 27 '21 11:08 sveinugu

Dockerfiles are not good. The containers are too big and you don't gain a Singularity image from it - which we do if you stick to Bioconda --> automatic (archiving the tarball, Docker, Singularity, CVMFS deployment).

bgruening avatar Aug 27 '21 11:08 bgruening

Imho a package is better than a container. You can still get a Container from a package, but not the other way around.

bgruening avatar Aug 27 '21 11:08 bgruening

Dockerfiles are not good. The containers are too big and you don't gain a Singularity image from it - which we do if you stick to Bioconda --> automatic (archiving the tarball, Docker, Singularity, CVMFS deployment).

Everything else being equal, then having support for more package/container techs is definitely a plus. The question is, however, whether it is worth the time and effort needed to translate the existing DockerFile (https://github.com/sigven/oncoEnrichR/blob/master/docker/Dockerfile) into a Bioconda package config file (and to gain the expertise to be able do so)? If only having the dependency available as a DockerFile is hindering uptake (which I believe you are saying), then I agree we should put in the effort.

sveinugu avatar Aug 27 '21 11:08 sveinugu

Mh, it's your call :) You know my answer. With 8.000 packages in Bioconda and the entire Bioconductor stuff, I would assume its worthwhile.

bgruening avatar Aug 27 '21 12:08 bgruening

Maybe I need to add, I'm talking about the tool, not the RStudio integration, etc ...

bgruening avatar Aug 27 '21 12:08 bgruening

https://github.com/bioconda/bioconda-recipes/pull/30292

Maybe someone could look over the metadata.

bgruening avatar Aug 27 '21 15:08 bgruening

Hi, @bgruening, following up on this. Thanks for pulling this together so quickly! I just noticed one small thing in the files listed, one "summary" seem off, i.e. last line of r-oncoenrichr/_meta.yaml, should rather be "Cancer-dedicated gene set interpretation" (NOT "Assertive check functions for defensive R programming.")

sigven avatar Sep 05 '21 15:09 sigven

@bgruening Thanks for the pull request! I did not see until now that you actually did the work here, as far as I understand, while I in the meantime only managed to delegate the task internally. However, in the PR, you have first added a "_meta.yaml" file for OncoEnrichR in the first commit, and the automatic lint complains there is no "meta.yaml" file. In the second commit OncoEnrichR is deleted again, leaving only the dependencies "gganatogram" and "oncopharmadb", which has been merged. What's the story here?

sveinugu avatar Sep 05 '21 16:09 sveinugu