Galaxy: Read only attribute for dependency_resolvers_conf.xml

Created on 11 Feb 2019  路  5Comments  路  Source: galaxyproject/galaxy

As part of galaxyproject/usegalaxy-playbook#118 we'll have a dependency_resolvers_conf.xml like:

<dependency_resolvers>
    <conda prefix="/cvmfs/usegalaxy.galaxyproject.org/dependencies/conda" />
    <conda />
</dependency_resolvers>

For this to work properly, we need some sort of "read only" attribute (on the suggestion of @jmchilton):

    <conda prefix="/cvmfs/usegalaxy.galaxyproject.org/dependencies/conda" readonly="true" />

This would indicate to Galaxy (or Pulsar/whoever) not to attempt installation using that dependency but instead skip to the next resolver e.g. when installing tools locally.

aretool-dependencies kinenhancement

Most helpful comment

I see, no, it'd still attempt installation if you don't uncheck the mark. I wonder if from the UI perspective it wouldn't make more more sense to just allow admins to select the actual resolver to use ? If you're using the API you can already do something like:

requests.post(galaxy_url + "/api/tools/" + tool_id + "/dependencies", {'key': API_KEY, 'resolver_type': 'build_mulled_singularity'})

But yeah, that flag seems useful, I can add it.

All 5 comments

We've got a auto_install flag for all container resolvers, would that fit the bill ?

It's close, but it doesn't handle the case of installing dependencies during tool installation, does it?

I see, no, it'd still attempt installation if you don't uncheck the mark. I wonder if from the UI perspective it wouldn't make more more sense to just allow admins to select the actual resolver to use ? If you're using the API you can already do something like:

requests.post(galaxy_url + "/api/tools/" + tool_id + "/dependencies", {'key': API_KEY, 'resolver_type': 'build_mulled_singularity'})

But yeah, that flag seems useful, I can add it.

From an API perspective I think it makes a lot of sense to allow specifying a particular resolver (don't they need IDs and not just types then - because we are entering a world of multiple conda resolvers per config?), but from an UI perspective - I think this is a detail we want to hide from 95% of deployers. Ideally admins have somehow decided they want packages or containers and all the rest of the details are as simple and hidden as possible? It seems weird for me to have this opinion - but we used to expose so many details during tool install and I don't think we want to?

@jmchilton We already hide by default the dependency installation options, so we can add the resolver selection there too.

Was this page helpful?
0 / 5 - 0 ratings