search

instructlab / dev-docs

Developer documents for the InstructLab organization
Apache License 2.0
4 stars 32 forks source link

introduce additional_arguments in config.yaml #111

Open cdoern opened 4 months ago

cdoern commented 4 months ago

This dev-doc introduces ilab-config-structure.md a document meant to discuss how we deal with nested classes in the config. Additionally this document discusses implicit vs explicit arguments that have been previously added in different ways in key ilab commands.

additional_arguments allows ilab to implicitly support more complex flags from the libraries it calls without adding them directly to the config.

cdoern commented 4 months ago

@leseb

I don't think we should "hide" any options. If we do, how will users discover them?

We have had a few conversations in the past week about the ever increasing complexity of the libraries in instructlab. Its not realistic to expect every option added in the libraries to match 1:1 with cfg options and flags in instructlab, but ilab should also be able to support them all one way or another.

If we are operating under the assumption ilab is the main point of entry into the libraries, it should support all the complex options the libraries have to offer. However, having these all spelled out in the config is pretty bad UX. This would allow us to choose which ones the user would most commonly need to edit while also supporting the more complicated ones, just implicitly.

leseb commented 4 months ago

@leseb

I don't think we should "hide" any options. If we do, how will users discover them?

We have had a few conversations in the past week about the ever increasing complexity of the libraries in instructlab. Its not realistic to expect every option added in the libraries to match 1:1 with cfg options and flags in instructlab, but ilab should also be able to support them all one way or another.

If we are operating under the assumption ilab is the main point of entry into the libraries, it should support all the complex options the libraries have to offer. However, having these all spelled out in the config is pretty bad UX. This would allow us to choose which ones the user would most commonly need to edit while also supporting the more complicated ones, just implicitly.

Ok, that sounds reasonable to me then, I missed that during my initial review. Thanks for the clarification.

nathan-weinberg commented 1 month ago

@cdoern what is going on with this?