Closed reid-wagner closed 4 months ago
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?
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.
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 findfragpipe
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 withplanemo 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.
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.
@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.
@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.
Are you saying the _3 container here: https://quay.io/repository/biocontainers/fragpipe?tab=tags&tag=latest is not working?
Are you saying the _3 container here: https://quay.io/repository/biocontainers/fragpipe?tab=tags&tag=latest is not working?
~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.
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 Thanks for the review!
Awesome! Thanks @reid-wagner and @bernt-matthias
Thank you @bgruening and @bernt-matthias!
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.