Multiple yml flag files

Is it possible to specify a list of yaml files with defined flags?

I am looking to do something like:

  - config:guild/flags/a.yml
  - config:guild/flags/b.yml
flags-import: all

But it seems like guild currently only supports one yml file. Maybe I can do something with configs?

Guild does not support what you’re looking to do — though this is an important feature IMO that Guild should support. I’d describe this supporting multiple flags interfaces. This would also enable support for combinations of flags inputs — e.g. args, globals, params, etc.

This is a fairly involved enhancement though and I’d hate to block your use case on that big chunk of work.

A simpler change though (just thinking about this out loud) would be to support a list or a regex pattern for the config flags dest. E.g. config: flags/{a,b}.yml or something like that.

Guild does support includes and the ability to reference flag defs in config. So something like this works today:

But this requires a funny Guild-specific spelling of your config files.

Guild also supports batch files, which let you specify a set of flag values at the command line – e.g. `guild run op @flags.yml. In this cases you’d need to provide a single config file containing the set of flags from your various sources. The generation of this file would be independent of Guild however (e.g. a pre-run script).


Thank you! Your suggestion is what I currently do, but as you mention, it’s in the guild format and not a format that can easily be used by other frameworks that rely on yaml formats.

Just FYI, my use case is using guild as experiment tracker around ROS. ROS can use yaml parameter files so my ideas was to add yaml files as guild flags and then load them in ROS.

I will do this, but just wrap my ROS network in a python script and then manually convert the guild format to yaml files that can be accepted by the ROS network.

Yeah, it’s not ideal. I’m currently playing with a change that would let you specify a pattern (either glob style or regex) for the config spec, which I think would support your use case without lot of big changes to Guild.

1 Like

I’ve outlines some approaches for this here:

If you have any preferences/thoughts - please feel free to comment there. I think we can get this into the next release without too much work. The options outlined there are just spellings of basically the same functionality.