Global and User config, CLI config

[sneakers-the-rat]

This PR ports some stuff i have worked on in linkml over to miniscope-io.

Specifically we

• Adds a configurable user_dir source of config - currently there is a place to set base_dir but no way to get config from that directory, but now one can define global config there too.
• Adds other sources of config because why the hell not - currently one can use .env file, but this adds the ability to use (in order of priority, high to low)...
  • mio_config.yaml in current directory
  • pyproject.toml - the [tool.miniscope_io.config] table
  • mio_config.yaml in a custom user directory
  • mio_config.yaml in a fixed global directory
• Adds cli commands to
  • create/set a user directory
  • show user/global configs
  • show locations of user and global config files

This also improves testing for configs, making fixtures to set each of the types of settings sources.

I know i have been like maniacal about config on this project, but i swear it's not just a pointless yak shave: as i said before, configuration is going to be the main point of interaction that people have with miniscope-io since it's an SDK not a full-blown GUI app, it might get bundled in with other programs, and it's the way that we're exposing as how to control the operation of the program (somewhat tautologically...). So it needs to be tight and evolvable.

This sets us up to make the configuration of devices more straightforward, where we might have something like mio device {device_type} create to create a default configuration for that device into {user_dir}/devices so that they can then customize it. being able to have flexible configuration from the system level down to individual projects (i.e. global config vs. the directory-specific configs) then we make it possible to bundle device configs along with experimental data, so one could just cd to a different directory and automatically use the configs for the project in that directory.

---

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

[coveralls]

Pull Request Test Coverage Report for Build 12246079711

Details

• 132 of 144 (91.67%) changed or added relevant lines in 5 files are covered.
• 1 unchanged line in 1 file lost coverage.
• Overall coverage increased (+1.0%) to 79.112%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
miniscope_io/cli/main.py	0	2	0.0%
miniscope_io/models/mixins.py	5	7	71.43%
miniscope_io/cli/config.py	61	69	88.41%

Files with Coverage Reduction	New Missed Lines	%
miniscope_io/models/mixins.py	1	89.17%

Totals
Change from base Build 12243905522:	1.0%
Covered Lines:	1337
Relevant Lines:	1690

---

💛 - Coveralls

[sneakers-the-rat]

thoughts on this? i am finding myself wanting to use some of these fixtures in #76

[t-sasatani]

Looks very helpful! I was always confused around this.

[t-sasatani]

Yes, making this explicit helps a lot.

[t-sasatani]

It is also related to my comments in #76, but I'm not sure which is easier between these two (though it wouldn't hurt to have these two work nicely). I feel that using text editors could be easier than using CLI for our target users (~undefined), but I am unsure.

[sneakers-the-rat]

totally ya. after seeing you working with the cli setting config values i think that would be really nice to have, and that should also edit the relevant files, so they should be made to be equivalent imo if we do set config values from the cli - i.e. editing from cli should change the value in the config files as if one were to edit it with a text editor

[t-sasatani]

This looks very helpful.

[sneakers-the-rat]

well i sorta merged these backwards and made this much harder for myself.... my bad

[sneakers-the-rat]

I think that having a separate devices configs directory is probably more complex than we want. having a single flat id-based system where the user can structure it into whatever they want within configs is probably easier than having to keep track of where files are stored. gonna remove that part (it's not used anyway in this PR)

[sneakers-the-rat]

Had to change some minor behavior here - now we no longer explicitly propagate log levels down from the base level value to level_file and level_stdout - the init_logger value handles that. This is because when multiple config sources are read, then the model instance from the highest priority source will fill those values in from the defaults, and then they override explicitly set values in lower priority sources. This way makes the config model a bit more explicit representation of the configs with less magic, which is always good. i checked that the only place those values were read was within the init_logger anyway, so should be function-neutral change.

also updated the test for setting log levels from being just via .env to all modes of config, since we have those fixtures now.

[sneakers-the-rat]

added some tests and we should be good to go