Specify target types from command-line (configs)

Ideas from @brentyi

In terms of choosing between datasets if we assume every dataset type needs different fields seems like there are two options:

(1) Just storing every possible parameter, and adding a field for selecting between the config types

This looks kind of dumb, but it’s at least reasonably clear what’s happening?

@dataclasses.dataclass
class VanillaDataloaderConfig:
    # The chosen dataset config.
    selected_dataset_type: Literal["blender", "friends", "mipnerf360", "record3d"] = "blender"

    # Configs for each dataset type. Only one will be used.
    dataset_config: Dict[str, DatasetConfig] = {
        "blender": BlenderDatasetConfig(),
        "friends": FriendsDatasetConfig(),
        "mipnerf360": MipNerf360DatasetConfig(),
        "record3d": Record3DDatasetConfig(),
    }
    ...

and then you could access the chosen dataset config in code via dataloader_config.dataset_config[dataloader_config.selected_dataset_type] ; I haven’t checked, but I think this should all work in the current version of dcargs

(2) the less redundant alternative is creating subcommands by annotating dataset_config with a Union. this might be cleaner in the code, but worried subcommands might be slightly more confusing in the CLI? Needs a bit of work on my end, but the annotation change would look roughly like:

class VanillaDataloaderConfig(InstantiateConfig):
     """Configuration for dataloader instantiation"""
     _target: Type = VanillaDataloader
-    train_dataset: DatasetConfig = BlenderDatasetConfig()
+    train_dataset: Union[
+        BlenderDatasetConfig,
+        FriendsDatasetConfig,
+        MipNerf360DatasetConfig,
+        Record3DDatasetConfig,
+    ] = BlenderDatasetConfig()

and then usage might look like: python scripts/run_train.py {non-dataset arguments} blender-dataset {dataset arguments}

For option (2), if you do python scripts/run_train.py --help all of the dataset config parameters will disappear. instead, there’ll be a list of subcommands at the bottom of the helptext

[ethanweber]

I think I like (2) the most since it’s fairly intuitive if one were to add a dataparser.

• (1) is also good, but (2) is seems like the cleaner & consistent option.
• (3) is neat but probably harder to figure out and easy to have a name conflict.

[brentyi]

oops i just did it