Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

adding oncoEnrichR to Galaxy #6

Open
bgruening opened this issue Aug 24, 2021 · 14 comments
Open

adding oncoEnrichR to Galaxy #6

bgruening opened this issue Aug 24, 2021 · 14 comments

Comments

@bgruening
Copy link

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
Copy link
Owner

sigven commented Aug 24, 2021

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
Copy link
Author

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
Copy link
Owner

sigven commented Aug 24, 2021

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
Copy link

@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
Copy link
Author

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
Copy link

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
Copy link
Author

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
Copy link
Author

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

@sveinugu
Copy link

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
Copy link
Author

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
Copy link
Author

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

@bgruening
Copy link
Author

bioconda/bioconda-recipes#30292

Maybe someone could look over the metadata.

@sigven
Copy link
Owner

sigven commented Sep 5, 2021

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
Copy link

sveinugu commented Sep 5, 2021

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants