-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Read only attribute for dependency_resolvers_conf.xml #7348
Comments
We've got a |
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:
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. |
As part of galaxyproject/usegalaxy-playbook#118 we'll have a
dependency_resolvers_conf.xml
like:For this to work properly, we need some sort of "read only" attribute (on the suggestion of @jmchilton):
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.
The text was updated successfully, but these errors were encountered: