tools/mpremote/config: Add environment-variable and .env-style config options. #17662
+92
−31
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
This PR factors out mpremote's configuration code into a separate file, and adds the ability to specify that configuration from two other sources: environment variables with the
MPREMOTE_
prefix, and/or a dotenv-style configuration file called.mpremote
in the user's current directory or one of its parents.My own motivation for wanting environment-variable control here is ease of automation. In heavily-scripted and especially containerized environments, environment variables are generally easier to work with than configuration files. This will help pave the way for e.g. a future CI/CD task for running the mpremote test suite.
The dotenv configuration mechanism is another common configuration method I found while researching existing python libraries for combining and dispatching to available file-based and environment-variable-based configuration methods. I ended up not finding a tool that could process the
MPREMOTE_
andMPREMOTE_CMD_
environment-variable prefixes together the way I'd have liked, but I had the dotenv-style loader working already by that point. It adds a convenient way to specify project-specific mpremote configurations to be automatically used when running mpremote in the context of that specific project.This was inspired by discussion on #17485, and also incorporates a not-entirely-trivial rebase of #9573 to include @Josverl's fixes to the current
config.py
issues on Windows.Testing
Not yet done; we're at least at "works on my machine", but I've not yet gone through testing every combinations of configuration sources across multiple applicable environments.
Part of testing this will also need to be ensuring that all available settings are tested, to make sure the testing process has been sensitive to e.g. a need to add some sort of explicit type conversion processing (to the environment-variable loading, or at the site where the relevant config item is used). Since I'll have to go through that anyway I'll also make sure all of those options have documentation.
Trade-offs and Alternatives
More opinionated philosophies like The Twelve-Factor App suggest that environment variables should be the only configuration mechanism. Some of its reasoning in favor of environment variables might be worth reading, but I don't agree with the conclusion that the current
config.py
mechanism ought to be dropped.It might still be better to drop the dotenv-style, to avoid proliferating too many ways a user could get tangled in stupid "where even is the damn config file" style headaches, and avoid an obligation to maintain support for it; though I think the usability it adds outweighs that.