sigven / oncoEnrichR

Explore the cancer relevance of your gene list
https://sigven.github.io/oncoEnrichR/
MIT License
49 stars 10 forks source link

adding oncoEnrichR to Galaxy #6

Open bgruening opened 3 years ago

bgruening commented 3 years ago

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

sigven commented 3 years ago

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

bgruening commented 3 years ago

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

sigven commented 3 years ago

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

sveinugu commented 3 years ago

@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.

bgruening commented 3 years ago

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.

sveinugu commented 3 years ago

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?

bgruening commented 3 years ago

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 commented 3 years ago

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

sveinugu commented 3 years ago

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.

bgruening commented 3 years ago

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 commented 3 years ago

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

bgruening commented 3 years ago

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

Maybe someone could look over the metadata.

sigven commented 3 years ago

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.")

sveinugu commented 3 years ago

@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?