chore: Rethink code flow for partial specification of CLI options #421

Activity

1. tstirrat15 commented on Sep 19, 2024

   

   tstirrat15

   on Sep 19, 2024

   ContributorAuthor

   More actions

   This was the context that led to #417:

   $ zed version --no-verify-ca --log-level trace
   2:32PM DBG configured logging async=false format=auto log_level=trace provider=zerolog
   client: zed v0.21.1
   2:33PM TRC token={"APIToken":"[...]","CACert":null,"Endpoint":"some.domain.here:443","Insecure":false,"Name":"thing","NoVerifyCA":false}
   
   $ zed schema read --log-level trace --no-verify-ca --endpoint some.domain.here:443 --token some_token
   2:43PM DBG configured logging async=false format=auto log_level=trace provider=zerolog
   2:43PM TRC token={"APIToken":"[...]","CACert":null,"Endpoint":"some.domain.here:443","Insecure":null,"Name":"env","NoVerifyCA":null}
   

   Someone was attempting to provide --no-verify-ca with their context and it wasn't being respected.
2. vroldanbet commented on Sep 20, 2024

   

   vroldanbet

   on Sep 20, 2024

   Contributor

   More actions

   The behavior until now has been roughly CLI overrides values otherwise provided by context, except some flags were being ignored as input for the override, which led to opening #417, which then introduced #418.

   Since that has been the contract in place, I think we should honor it. Now, is the current behavior "surprising", "unexpected" or difficult to reason about? I do understand the alternative scenario where the developer wants to get in control of the inputs, and does not expect the context to be used at all.
3. linear

   added

   area/CLIAffects the command lineAffects the command line

   on Jan 7, 2025
4. jzelinskie

   added

   Zed

   on Jan 3, 2026