Allow enterprises to skip upgrade checks and messages

[gpeal]

This is a feature primarily for enterprises who centrally manage Codex updates.

[joshka-oai]

nit: It could be worth phrasing this in the positive (check_upgrades_on_startup) rather than the negative (skip...). But not a big deal either way.

Does this need a command line option as well as a config option? (A reasonable use case for this is automated scripts running codex where you don't want the update code to be triggered, but where you also don't want to have to modify the config.

[gpeal]

nit: It could be worth phrasing this in the positive (check_upgrades_on_startup) rather than the negative (skip...). But not a big deal either way.

Does this need a command line option as well as a config option? (A reasonable use case for this is automated scripts running codex where you don't want the update code to be triggered, but where you also don't want to have to modify the config.

Usually, I would phrase things in the positive direction but it makes it makes it harder to deduce whether we check for updates by default. The negative also allows the CLI arg (which is a good idea) to be a flag rather than k/v.

[gpeal]

nit: It could be worth phrasing this in the positive (check_upgrades_on_startup) rather than the negative (skip...). But not a big deal either way.
Does this need a command line option as well as a config option? (A reasonable use case for this is automated scripts running codex where you don't want the update code to be triggered, but where you also don't want to have to modify the config.

Usually, I would phrase things in the positive direction but it makes it makes it harder to deduce whether we check for updates by default. The negative also allows the CLI arg (which is a good idea) to be a flag rather than k/v.

@joshka-oai Actually, do you think -c skip_upgrade_check=true is sufficient? I'm not sure we want to get in the habit of adding a flag for every config.toml option.

[joshka-oai]

@joshka-oai Actually, do you think -c skip_upgrade_check=true is sufficient? I'm not sure we want to get in the habit of adding a flag for every config.toml option.

Yes - that's perfect. I forgot we could do that. No need for an actual flag when we can pass config directly.

[joshka-oai]

Usually, I would phrase things in the positive direction but it makes it makes it harder to deduce whether we check for updates by default. The negative also allows the CLI arg (which is a good idea) to be a flag rather than k/v.

In the cli flags we get to specify what the defaults are. Clap shows these in the help text. There's also an approach for true-false params that maps --no-key and --key to true/false.

In the config, we don't currently publish a json schema, but doing so would allow us to have that loaded and show what the default values are in editors that support using this for validating and documenting TOML (e.g. VSCode).

[gpeal]

Usually, I would phrase things in the positive direction but it makes it makes it harder to deduce whether we check for updates by default. The negative also allows the CLI arg (which is a good idea) to be a flag rather than k/v.

In the cli flags we get to specify what the defaults are. Clap shows these in the help text. There's also an approach for true-false params that maps --no-key and --key to true/false.

In the config, we don't currently publish a json schema, but doing so would allow us to have that loaded and show what the default values are in editors that support using this for validating and documenting TOML (e.g. VSCode).

I'm sure we can set the defaults but if one were to just see the config name, you'd then have to go read the docs or the source to know whether or not you (an average person) should enable it. With the naming in this direction, it makes it clear that "this is a thing you should opt-in to for this specific behavior".

Your perspective is valid though and I don't actually feel strongly because I typically default to positive naming. Wdyt?

[joshka-oai]

Your perspective is valid though and I don't actually feel strongly because I typically default to positive naming. Wdyt?

I'm fine with either way - I'm just 51:49 for using a positive name for this. That is to say. No need to change unless you feel strongly about it also. I can't think of a good reason this would ever bite us.

[etraut-openai]

I ran into this naming issue for the animation feature flag that I recently added. I chose animations (with a default of true) rather than no_animations or disable_animations. I don't have a strong opinion here, but I have a slight preference for positive flag names. Let's pick a rule and then apply it uniformly for all new feature flags.

[gverma-openai]

naming nit: check_for_update_on_startup (update instead of upgrade as it's clearer IMO and also consistent the description, also singular feels cleaner but feel free to use plural).