PR #8118 - adding to_dict to the dependency manager and an embedded loading of dependency resolution options from galaxy.yml - was really quite poorly thought through.
Certain options could be embedded - but only the resolvers and the actual dictified representation of the DependencyManager couldn't be actually embedded properly in the app config - but this is exactly what I wanted to do on the Pulsar side and it would make no sense to have the exact same options in both apps and configured differently.
So now the actual dictified representation of the whole DependencyManager can be directly embedded in galaxy.yml as the ``dependency_resolution:`` parameter. All the parameters can still be configured at the top level of the YAML file but with 'dependency' in the config option name (some prefixes, some suffixes, etc... a hodgepodge that has grown organically). Give the messiness of the existing options might be better to encourage using ``dependency_resolution:`` in the future.
This is (so far a subset of) the tool utilities from galaxy-lib. galaxy-lib mocked out a fake galaxy.tools to allow these to all exist below the galaxy.tools - but this was a terrible hack - in order for the new packages to be true subsets of Galaxy they need to be refactored into a new package that doesn't depend on models, SA, galaxy.jobs, etc...
[x] galaxy.tools.deps -> galaxy.tool_util.deps
[x] galaxy.tools.loader -> galaxy.tool_util.loader
[x] galaxy.tools.cwl -> galaxy.tool_util.cwl
[x] galaxy.tools.loader -> galaxy.tool_util.loader
[x] galaxy.tools.fetcher -> galaxy.tool_util.fetcher
[x] galaxy.tools.locations -> galaxy.tool_util.locations
[x] galaxy.tools.parser -> galaxy.tool_util.parser
- Construct a DependencyManager according to Galaxy's configuration before Galaxy starts to allow auto installation of Conda.
- Add script for managing tool dependencies outside of a Galaxy environment.
- Refactor to allow this to be done without duplicating logic related to defaults, configuration handling, etc....
Implements #3426.
Dannon Baker