Add FragPipe

[reid-wagner]

Re-creating #759

This PR adds a wrapper for the FragPipe tool suite.

A handful of default FragPipe workflows are provided for the user, while more may be added in the future. Most FragPipe parameters are duplicated in the Galaxy tool, many of which are optional to allow the workflow defaults to be used.

Some components have not yet been implemented due to license restrictions (DIA-NN & MSBooster). Other parameters need further work and testing before implementation, and will default to the workflow defaults. The workflow, along with the log file and some other FragPipe outputs are optionally selected as Galaxy outputs.

License keys are hard-coded into the tool, and a required select option and text warnings are in place to ensure a user understands the licenses, as has been discussed with the developers.

[bgruening]

You can now see the planemo error reports at this page: https://github.com/galaxyproteomics/tools-galaxyp/actions/runs/9046215197?pr=761 scroll down.

Seems like the mv command has nothing to move. How do you run the tests locally?

[reid-wagner]

Yes - it looks like libz is a dependency that might need to be added: libz.so.1: cannot open shared object file. It was already present on our system so I didn't catch it.

When I try to add it to the recipe with <requirement type="package" version="1.2.13">zlib</requirement>, the FragPipe package doesn't seem to be installed correctly (i.e. can't find fragpipe binary on path), so I haven't figured that out.

I'll add zlib to the bioconda recipe anyways, but I was hope to get it working here to verify that's all we need. I'm trying to run tests with planemo test --engine docker_galaxy --no_cache_galaxy, but I'm having separate issues there too. I am able to run this manually on our university Galaxy instance.

[bgruening]

When I try to add it to the recipe with <requirement type="package" version="1.2.13">zlib</requirement>, the FragPipe package doesn't seem to be installed correctly (i.e. can't find fragpipe binary on path), so I haven't figured that out.

In those cases its probably the wrong, incompatible zlib version. Try on your commandline conda create -n foo --dry-run fragpipe=x.x.x zlib=y.y.y you will see that the solver will bail out maybe and then you can play around with the version until it works.

But you are correct, fixing the conda recipe is the correct thing to do.

I'll add zlib to the bioconda recipe anyways, but I was hope to get it working here to verify that's all we need. I'm trying to run tests with planemo test --engine docker_galaxy --no_cache_galaxy, but I'm having separate issues there too. I am able to run this manually on our university Galaxy instance.

Oh I see, this is wrong :)

Just do planemo test --biocontainers this will run your tests using a container (that is created if needed). And it is exactly what is running here on CI.

[reid-wagner]

you can play around with the version until it works

This sort-of how I came to zlib=1.2.13. I built the fragpipe recipe with an unpinned zlib dependency and used the resulting zlib version. Creating a new environment with zlib and fragpipe as separate dependencies also resolved to 1.2.13. I'm wondering if there's a way to find logs of the mulled environment creation?

Oh I see, this is wrong :)

Okay, thanks for the advice! I'm just getting started with planemo test so I have a lot to learn.

[reid-wagner]

@bgruening Is there a way to force builds to use a biocontainer with a more recent build of the fragpipe bioconda package? I fixed the zlib issue in the recipe, since I had trouble with it here, but I think it's still using the older version.

[reid-wagner]

@bgruening Is there a way to force builds to use a biocontainer with a more recent build of the fragpipe bioconda package? I fixed the zlib issue in the recipe, since I had trouble with it here, but I think it's still using the older version.

Apologies - I didn't sufficiently fix the dependency. And it is using the most recent biocontainer.

[bgruening]

Are you saying the _3 container here: https://quay.io/repository/biocontainers/fragpipe?tab=tags&tag=latest is not working?

[bgruening]

Are you saying the _3 container here: https://quay.io/repository/biocontainers/fragpipe?tab=tags&tag=latest is not working?

[reid-wagner]

It's not, but I made an obvious mistake with the dependencies so I'm working to fix that in the recipe now.

Never mind, the dependency fix was fine.

[reid-wagner]

This is ready for review now.

There actually was an issue with the biocontainer - it seems like ldconfig is not appropriately setting the library path in the container. I worked around this by adding /usr/local/lib to LD_LIBRARY_PATH in the recipe.

[bernt-matthias]

Some initial thoughts .... maybe we can sit together these days and see if we can simplify the configfile generation or just go through step by step... But not sure when.

[bernt-matthias]

Does having a single section make sense here?

[reid-wagner]

A little confused on this point. Would it be to remove the "no" and "default" options? The "yes"/"no" distinction allows us to set the param that enables this in FragPipe. The "default" is usually a bit redundant but the argument could be that if a user is re-running a shared job, they might not know the workflow default and could use that option to revert to it.

[bernt-matthias]

default / no / yes is fine for me. was just wondering if a single section inside a conditional is helpful.

but fine with me.

[bernt-matthias]

Looks very good to me. Any comments @bgruening ?

[reid-wagner]

@bernt-matthias Thanks for the review!

[bgruening]

Awesome! Thanks @reid-wagner and @bernt-matthias

[reid-wagner]

Thank you @bgruening and @bernt-matthias!