-
-
Notifications
You must be signed in to change notification settings - Fork 378
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add the ability to override app configurations at the command line #1542
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well timed; this is meeting my needs of creating specific projects in CI.
briefcase create linux AppImage \
--config 'template="../../"' \
--config 'requires=["toga-gtk==0.3.1", "PyGobject<3.46.0"]'
I guess I hadn't considered this before but...apparently attributes can have spaces.
briefcase package -C '"zzz template"={"asdf"=42}'
I gave up trying to get a newline character in to the value for -C
....but that shouldn't matter since you can pass multiple values for -C
.
👍🏼
src/briefcase/commands/base.py
Outdated
except ValueError: | ||
raise BriefcaseCommandError( | ||
f"Unable to parse configuration override {value}" | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think Rich's stacktrace handles this regardless but can you raise from the ValueError
?
except ValueError: | |
raise BriefcaseCommandError( | |
f"Unable to parse configuration override {value}" | |
) | |
except ValueError as e: | |
raise BriefcaseCommandError( | |
f"Unable to parse configuration override {value}" | |
) from e |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That should be unnecessary: exceptions raised within an except block are automatically chained unless you say from None
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Might as well be explicit.
src/briefcase/commands/base.py
Outdated
dest="config_overrides", | ||
action="append", | ||
metavar="KEY=VALUE", | ||
help="Override the value of the app configuration item KEY with VALUE.", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nitpick: no period at the end to match the other options (although, I also shouldn't have added one to -v
...)
help="Override the value of the app configuration item KEY with VALUE.", | |
help="Override the value of the app configuration item KEY with VALUE", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Interesting - the very next option defined (--verbosity
) did have a period. I've corrected both.
src/briefcase/commands/run.py
Outdated
@@ -248,6 +248,7 @@ def __call__( | |||
no_update: bool = False, | |||
test_mode: bool = False, | |||
passthrough: list[str] | None = None, | |||
config_overrides: list[str] | None = None, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
needs to be passed to finalize()
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, but not any more with the revised approach that I've implemented.
src/briefcase/commands/update.py
Outdated
@@ -68,6 +68,7 @@ def __call__( | |||
update_resources: bool = False, | |||
update_support: bool = False, | |||
test_mode: bool = False, | |||
config_overrides: list[str] | None = None, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
needs to be passed to finalize()
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Again, Yes, but not any more with the revised approach that I've implemented.
@rmartin16: I'm guessing from your comments that you didn't intend to approve this yet? |
src/briefcase/commands/base.py
Outdated
for value in config_overrides: | ||
try: | ||
overrides.update(tomllib.loads(value)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can't see any mention of multi-level config values, like --config 'linux.requires=...'
, which is valid TOML.
I think this code might actually work with that as long as you only had one of them. But then if you added --config linux.something_else=...
, the second linux
would overwrite the first instead of merging with it.
We don't necessarily need to support that syntax in this PR, but if we don't support it, we should at least display a useful error when the user tries to use it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good call. Right now, it's probably easier to reject multi-level keys completely. We can always add them later if there's a reasonable use case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually - in the process of looking at this, it occurred to me that this approach avoids validation of any provided value (e.g., you could specify an invalid version number)... and when I went looking to see how I could do validation, I found a much cleaner way to handle the overrides, in a way that both validates and avoids the issue @rmartin16 found with not passing the overrides to some commands.
I meant to....but selecting "comment" instead probably would have been a better choice perhaps. I was mostly trying to communicate "don't feel required to send this back to me with changes". |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
updating status to comment
I've updated the PR so that any command-line overrides go through the same validation process as if they were specified in pyproject.toml. This ends up being a lot less invasive on commands, in addition to the validation benefit. I've also beefed up the validation that is done on the keys, ensuring that deep keys are rejected. |
@rmartin16: FYI, if you want to cancel an approval, you have to choose "Dismiss review" under "Changes approved" at the bottom of the page. |
Adds a
-C
/--config
option that allows a user to override the value of a setting at the command line.e.g.:
would generate an app using the values in the pyproject.toml, except for using a different template.
This is primarily useful for internal testing setups, such as generating a test app inside a template repository, or running CI for the Apple support package in CI. However, it could also be useful to pass in other values, such as a version number.
It's likely only of any practical use in the
create
command, but it's been implemented in all "app facing" commands in case it might be useful.Fixes #1115.
/cc @rmartin16
PR Checklist: