Default Package Settings#10033
Conversation
|
This implementation now feels a lot closer, though it isn't all the way there. However, I'm hesitant to move much further until I get a little feedback to make sure this is going in the right direction. So I'm tentatively marking this as ready, though it still does need a little work. Also, a draft proposal is now available. |
owenv
left a comment
There was a problem hiding this comment.
At first glance what's here seems reasonable, though it would be nice to have some tests which run builds end to end. I think the per-setting append vs override behavior is likely to be confusing in practice, but that's more of an evolution question than an implementation one.
|
@owenv thanks so much for looking! I'm also considering just a straight replacement. Any target settings are a complete overwrite, so defaults would only apply to targets that have no settings specified. Is that more appealing to you? |
|
Very much appreciate your feedback here @owenv. I'm going to move this back into draft form because it definitely not done yet given the direction I think we're going. |
I'm working on a concept that would allow a top-level package structure to define default settings that would apply to all targets if that target does not itself include a setting that takes precedence.
This will require an evolution proposal and I intend on producing one if I can figure out the implementation and it makes sense to try. I'm opening up this PR to get some early feedback. I really do not know what I am doing here...
Motivation:
I find it both common and cumbersome to define settings that apply to all targets. I'm hoping to clean that up.
Modifications:
New public facing properties to set defaults in a manifest.
The logic to actually apply the defaults is fairly subtle in some cases and some more thinking (and testing) is definitely required.
Result:
You'll be able to define default settings in manifests and have those apply to targets.