[cli] Add mio config list

[sneakers-the-rat]

Re: #88 (comment)

how does this look

---

📚 Documentation preview 📚: https://miniscope-io--93.org.readthedocs.build/en/93/

[t-sasatani]

Nice!

[sneakers-the-rat]

i'll do mio config show {id} tomorrow so you can then take a look at them

and then maybe we want like mio config path {id} to output the path so you can do something like subl "$(mio config path my-config)" to open it in a text editor

[coveralls]

coverage: 79.597% (+0.4%) from 79.231%
when pulling 82530ca on cli-config-list
into adfa79e on main.

[t-sasatani]

I think it's already satisfactory for addressing #88 , though I would want to hear from others how it feels to navigate through this. And yeah, the intended interaction for changing configs was another part I wasn't sure about, so an interface for grabbing paths would be excellent.

[MarcelMB]

Thanks, Jonny for creating this.

Just for my understanding: Why is there a stream-buffer-header ID and a wireless-200px ID.

So it's not like streaming with a buffer-header file with the wireless MS is going to be one ID? For example, each pixel size on the image sensor will have a different ID? and will be combined with the wireless-XXpx file?

So I think what I am saying is I am not sure if it would be intuitive to know which configuration to use.

[sneakers-the-rat]

So see the second column, which says what kind of model it is. currently that's just the name of the class, but in the future once we have done more work to link e.g. each of the other cli commands to a given config model (the mio stream capture command takes a StreamDevConfig object) then we can refine the interface in a few ways:

• column for showing which commands each config can be used with, e.g. like mio config list --with-commands or something.
• parameter for showing/sorting configs like mio config list --type StreamDevConfig / mio config list --sort mio_model
• --list parameter for each of the other commands that lists configs that have a matching model type. e.g. mio stream capture --list would show you a table of just the stream dev configs you have.
• ... and so on, since we are linking config, code, metadata then we can refine the interface using all that information.

this is just the first draft of a "list all configs" command. so there are tons of other things we will want here too! this is an example of making small iterable PRs - initial functionality with clear points where we can expand in the future

the idea behind the design of this id, mio_model, version header thing coupled to the pydantic models is to have a uniform interface across API, cli, configs, and within the package. Since this is an SDK and we expect a lot of different pieces to need to work together in development, and also we expect users to need to have a durable, versionable, publishable description of their experiments, this package needs a lot of configuration. On two extremes, we can either have gigantic config files that jam everything into a humongous model (this is sort of how kilosort is/was designed, a single huge configuration blob gets passed around the whole program), or have to constantly juggle a bunch of different configs and variables.

I agree it's sort of annoying to need to have both the StreamDevConfig and the BufferHeaderFormat (usually the header format is just supplied by default), but this id and model system embedded in the configs lets us resolve that. They are actually coupled right? like the format of header data should be properly considered part of the device configuration. Say we had a field header_format in StreamDevConfig that needs a BufferHeaderFormat. We can specify that by reference everywhere in the same way without needing to juggle paths.

mode	`id`/`mio_model`	previously
config	header_format: wireless-header-format	header_format: linked_list: 0 frame_num: 1 # ... etc, literally in the config file or header_format: ./buffer_header_format.yaml
cli	# use the format specified in the config mio stream capture wireless-200px # override values in the config mio stream capture wireless-200px \ --with header_format=wireless-header-format	# to use the default configs from a non-git, non-development install mio stream capture ../venv/lib/site-packages/mio/config/wireless_200px.yaml \ --header-format ../venv/lib/site-packages/mio/config/wireless_200px.yaml
code	# load the config StreamDevConfig.from_id('wireless-200px') # to specify the header config StreamDevConfig(header_format='wireless-header-format')	from mio import CONFIG_DIR # load the config StreamDevConfig.from_yaml(CONFIG_DIR / "wireless_200px.yaml") # specify header config StreamDevConfig( header_format=BufferHeaderFormat.from_yaml( CONFIG_DIR / "wireless_header_format.yaml" ) )

So that's what we're working towards, where we can break apart, recombine, etc. different configs together both provided by the package, within an experiment, across a user's machine, or included in some downstream package that bundles us.

Hopefully that help explains why we would be seeing all configs and why that's a good thing - we want to be able to have a bunch of different types of configs for different models: those are all the configs and their ids you can use anywhere, in different cli commands, within config files, etc. And yes we will certainly continue to refine this interface and make use of that information to be able to filter and sort and show what you need to know, this isn't the final PR of the CLI. We will need to draw the line somewhere on this package to keep it functional for development and use in downstream packages, but doesn't try to bundle a ton of GUI and other stuff that we want to purposely keep separate to maintain modularity, but the CLI should be good.