feat(cli): add bulk extension enable/disable

[rwmyers]

Summary

I would like to have the ability to select the extensions that are used in one command rather than run numerous commands to enable / disable multiple extensions at once. This is because I frequently have subsets of commands in my user setup that differ (changing as many as 2-3 per time).

I propose updating the enable and disable commands to accept bulk operations (and in a subsequent PR provide a select dialog option):

gemini extensions enable [names..] [--all]
gemini extensions disable [names..] [--all]

Details

Why is this needed?
This makes it far easier to instantly swap between sets of extensions in the same environment.

For larger code bases, such as large operating system projects (think something like Android), it's easier to have specialized extension packs per area or large subsystem such that you do not context flood the system. While plenty of tools exist to create these extensions, they're a bit of a pain to turn on and off. This command accelerates that process significantly.

Related Issues

#24658

How to Validate

1. Run gemini extensions to see the new command.
2. Run gemini extensions enable ext-a ext-b (with extensions available to select) to enable multiple extensions.
3. Run gemini extensions disable ext-a ext-b (with extensions available to select) to disable multiple extensions.
4. Run variants of the enable and disable command with --all, or by naming specific extensions to enable or disable subsets.
5. Run the new unit tests.
6. Run variants when in workspace scope.
7. Validate things are selected appropriately when in CLI.

Pre-Merge Checklist

• Updated relevant documentation and README (if needed)
• Added/updated tests (if needed)
• Noted breaking changes (if any)
• Validated on required platforms/methods:
  • MacOS
    • npm run
    • npx
    • Docker
    • Podman
    • Seatbelt
  • Windows
    • npm run
    • npx
    • Docker
  • Linux
    • npm run
    • npx
    • Docker

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request introduces a new 'extensions select' command to the Gemini CLI, designed to streamline the management of multiple extensions. By providing a bulk selection mechanism, users can now easily switch between different extension configurations without needing to run individual enable/disable commands, improving workflow efficiency for complex development environments.

Highlights

• New CLI Command: Added the 'gemini extensions select' command to allow bulk enabling or disabling of extensions.
• Interactive and Non-Interactive Modes: The command supports an interactive picker, as well as direct arguments like --all, --none, or specific extension names.
• Scope Support: Added support for applying changes to either 'user' or 'workspace' scopes.
• Documentation and Testing: Updated CLI and extension reference documentation and added comprehensive unit tests for the new command.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request introduces the gemini extensions select command, which provides an interactive picker or CLI arguments to enable and disable extensions. The changes include comprehensive documentation updates and unit tests. Feedback suggests improving the implementation by replacing direct process.exit(1) calls with exitCli(1) to ensure proper cleanup, batching MCP server enablement calls outside the loop to optimize I/O, and logging full error objects in catch blocks for better observability.

[jackwotherspoon]

I think gemini extensions enable command can be passed multiple extension names to enable multiple at once... if it doesn't we should support it. Does that resolve the use-case here?

Not sure adding a new gemini extensions command makes sense here...

Adding another command adds confusion to users, when to use select vs enable/disable commands?

I could see a world where gemini extensions enable without an extension name passed opens up the interactive picker for users to choose which extensions to enable. But I think we should think about whether adding a new command makes sense vs leveraging our existing ones.

[rwmyers]

Thanks for the feedback. If we call enable with a set of items, that wouldn't strictly disable the others, right? If we had a chain of disable --all then the set that we'd like to enable, that would work though. WDYT? And if we added an interactive mode to enable, two questions: 1) would we want to do so for disable and 2) would it function as an overall selection picker? (I'd prefer so)

[jackwotherspoon]

If we call enable with a set of items, that wouldn't strictly disable the others, right?

Correct, the gemini extensions enable extension1 extension2 should purely set extension1 and extension2 to enabled. It should not change the others to disabled, just enable the passed extensions.

If we added an interactive mode to enable, two questions: 1) would we want to do so for disable and 2) would it function as an overall selection picker? (I'd prefer so)

Yes my quick thought was you would have gemini extensions enable and gemini extensions disable open the same selection picker when no extension names are passed to it.

@rwmyers I think this work is probably best split into two PRs.

1. Add functionality for enable/disable to pass multiple extension names in given command. This is a quick unblocker.
   i.e. gemini extensions enable ext1 ext2
2. Add the interactive picker when no arguments are passed to enable/disable commands. This probably requires a more detailed review to make sure folks on the team are aligned.

Let me know if that makes sense. 😄

[rwmyers]

Sounds great. And to confirm, would we want an --all for both disable and enable? That would make it really easy to chain the two commands?

I can raise the two PRs in that order.

[rwmyers]

Relatedly, I was thinking it'd also be super useful to have the same functionality within the CL. I think those are separate CLs as well. If you agree, I'm happy to expand the filed issue to include them (I have a version locally I was playing with, but was waiting to raise that until this was resolved)

[rwmyers]

@jackwotherspoon I've amended this PR request to instead expand enable and disable. Thanks!

[gemini-cli]

Hi there! Thank you for your interest in contributing to Gemini CLI.

To ensure we maintain high code quality and focus on our prioritized roadmap, we have updated our contribution policy (see Discussion #17383).

We only guarantee review and consideration of pull requests for issues that are explicitly labeled as 'help wanted'. All other community pull requests are subject to closure after 14 days if they do not align with our current focus areas. For this reason, we strongly recommend that contributors only submit pull requests against issues explicitly labeled as 'help-wanted'.

This pull request is being closed as it has been open for 14 days without a 'help wanted' designation. We encourage you to find and contribute to existing 'help wanted' issues in our backlog! Thank you for your understanding and for being part of our community!