load recipes directly from SparseZoo

[bfineran]

i.e. manager = ScheduledModifierManager.from_yaml("zoo:/model/stub/path?recipe_type=<recipe-type>")

[mgoin]

haha, this explains what i discovered in the yolov5 PR. i will echo that i think this is a great idea

[markurtz]

Small complaint that I noticed afterwards

[markurtz]

I'm generally not a fan of arguments that are conditional use based on the value of another arg, can lead to unfound bugs in other pipelines since there is effectively a planned non-tested, non-supported pathway. Is there another way we can find to simplify it such that the conditional logic is handled elsewhere such as putting the zoo_recipe_type as a conditional piece of the stub?

Also, we should take in a SparseZoo Recipe object here as well. That could also be another route for supplying the zoo_recipe_type that we don't need to explicitly call out here.

[bfineran]

My original plan was to insert it in the stub with something like zoo:path/to/stub.transfer or zoo:path/to/stub?recipe_type=transfer but decided against it because it would be extra syntax for users to discover. Additionally didn't want to add extras to stubs that would cause errors if the exact same stub were to be used in a different stub accepting function (ie load_model)

Agreed that having a conditional argument based on another arg is not great.

What do you think about following a http query string-like pattern that we can parse on the SparseZoo side

my_stub = "zoo:path/to/stub?recipe_type=transfer

def parse_zoo_stub(stub) -> Tuple[str, Dict[str, str]]:
    ...

stub, params = parse_zoo_stub(my_stub). # "path/to/stub", {"recipe_type": "transfer"}

Could also structure the params dict more if we want with a StubArgs class.

[markurtz]

I do like the query string approach and definitely seems very flexible with something like a sparse_zoo_stub function. Is there any reason to not have a Recipe constructor act as the sparse_zoo_stub function or have the Recipe constructor call into the sparse_zoo_stub? I think those combined with allowing a Recipe class to be passed in would cover all basis and give us enough flexibility to document an easy flow around. Additionally can easily identify each recipe by the stub through the UI's with easy copy and paste and additionally document flows in the recipe markdowns themselves for use cases

[bfineran]

updated these changes so Managers can accept stubs or sparsezoo.objects.OptimizationRecipe objects. additionally, all logic for recipe types has been moved to SparseZoo by supporting query strings as we discussed.