feat(goose-cli): add feature to disable update

[kskarthik]

Summary

Added a feature to the goose-cli crate to disable the update command.

Usecase: I have packaged goose for openSUSE Tumbleweed & i had to patch the build to disable update.

This feature comes handy instead of patching the code & quiet helpful for other distro package maintainers as well 🙂

Type of Change

• Feature
• Bug fix
• Refactor / Code quality
• Performance improvement
• Documentation
• Tests
• Security fix
• Build / Release
• Other (specify below)

AI Assistance

• This PR was created or reviewed with AI assistance

Testing

Tested manually

Screenshots/Demos (for UX changes)

Before:

$: goose update
WINDIR: <not set>
OSTYPE: linux
uname -s: Linux
uname -m: x86_64
PWD: /home/sai/my/code/goose-src
Detected OS: linux with ARCH x86_64
...

After:

$: cargo build --package goose-cli --features disable-update

$: goose update
Error: This command is disabled

[kskarthik]

@michaelneale Sorry, I messed up the merging stuff in previous PR #5846

This is a fresh attempt :)

[kskarthik]

Hi, Just a reminder please review this PR :)

[kskarthik]

Hy! @alexhancock || @michaelneale please review this tiny patch 😅

[michaelneale]

looks good - just wanted to know it leaves it as auto update by default? then lets get it in

[alexhancock]

Hi. Can you explain more about the reason for wanting this? As an implementation it looks OK to me but I am more curious about the motivation in general

[kskarthik]

@alexhancock As i explained in the summary, It makes it easy to disable the CLI update sub command during the compile time (opt-in) for the distro package maintainers, instead of maintaining a patch manually & avoids duplication of work across distros.

[alexhancock]

I saw that, but I was wondering why it's helpful to have a feature that disables this manner of updating goose.

Could we make it so if goose is installed from a package repo, users could still update the goose update way or via the package repo and get the new version from the right source either way? I worry just disabling it presents a frustrating UX to run goose update only to see that the command is disabled without explanation for why, or what to do to update.

[michaelneale]

@alexhancock it is very common in distributions of linux or other tightly packaged things to only have one wya to upgrade vs each tool doing their own, so I think this is a valid thing as it allows the goose binaries (which are nicely monolithic) to be packaged neatly in distros and not break signatures/security stance etc.

If someone installs it via a packaged way, it is fine to expect that to upgrade (you often get that with language runtimes) and user is always free to have their ownb user-land type version of it if they want (node/python have layers of things like that) so no surprise there.

[michaelneale]

I think worth it to be distro packaging friendly.

[kskarthik]

@alexhancock eg: deno cli also provides such a flag https://github.com/denoland/deno/blob/ee7c483df4bdc271edd0264c66246cc3297c6351/cli/Cargo.toml#L44

[kskarthik]

@michaelneale @alexhancock Hope i have resolved all your queries. Good to merge !? 😃