galaxyproject
Planemo lint doesn't support having container and requirement together
<xml name="requirements">
<requirements>
<container type="docker">xxxxx</container>
<requirement type="package" version="3.8">python</requirement>
<requirement type="package" version="1.0.2">xxxx</requirement>
</requirements>
</xml>
Galaxy tool seems to support this kind of setting as above, but planemo lint throws an error on it.
ERROR:SCHEMASV:SCHEMAV_ELEMENT_CONTENT: Element 'requirement': This element is not expected. Expected is ( container ).
Hi @qiagu,
I think the issue here is that you need to put the <container> tag after all the <requirement> tags.
This is because the XSD schema is using sequence here
I don't know if the use of sequence is intentional or if it can be replaced by all, in any case, if you declare your XML like this, it should pass the lining:
<xml name="requirements">
<requirements>
<requirement type="package" version="3.8">python</requirement>
<requirement type="package" version="1.0.2">xxxx</requirement>
<container type="docker">xxxxx</container>
</requirements>
</xml>
@qiagu just out of interest, what should this requirement do? Or what does it do?
@bgruening well, we want conda requirements and a third-party docker image to co-exist in the tool requirements. When tool is installed in a non-container environment, conda will be picked up; docker will be in play otherwise. Does this answer your questions?
@bgruening well, we want conda requirements and a third-party docker image to co-exist in the tool
requirements. When tool is installed in a non-container environment, conda will be picked up; docker will be in play otherwise. Does this answer your questions?
Not really :(
The following will create a conda environment for you when configured in Galaxy. But it will also run the tool in Docker if configured, without specifying a Docker container. Galaxy will create it on the fly or has precreated one for you already.
<requirements>
<requirement type="package" version="3.8">python</requirement>
<requirement type="package" version="1.0.2">xxxx</requirement>
</requirements>
Ah, I should provide a little more background. In our particular use case, there is an existing published docker image (not galaxy mulled) for the software wrapped in the tool. We made conda packages based the docker image. A problem is that installation from the conda packages is not fully automated. Does it make sense now?
Yes, but why is the installation of Conda packages not fully automated and how should this work in your example if its not automated?
Good question. The scenario could be that one of the conda artifacts is not stored in galaxy default channels. In rare cases, manual configuration of conda env. is needed or preferred by galaxy admin. In this case, besides the aforementioned factor, we want to keep using the original docker image as much as possible, instead of building a new one using conda packages that are derived from the original one.
The scenario could be that one of the conda artifacts is not stored in galaxy default channels
Maybe this helps: https://planemo.readthedocs.io/en/latest/writing_how_do_i.html#test-tools-against-a-package-or-container-in-a-bioconda-pull-request
