install azd and extensions all in one

[therealjohn]

We currently have to document a getting started like:

• install azd
• run azd ext install ...

Can we streamline this with a single way to get both for new users?
Can we have options to install other extensions? All extensions?

[rajeshkamal5050]

Day-0 (first install):

Add --install-extensions flag to the existing install scripts. After installing azd core, the script calls azd extension install for each requested extension. If needed, extenssion/partner teams can wrap this into their own branded install URL.

   # Combined install
   curl -fsSL https://aka.ms/install-azd.sh | bash -s -- \
     --install-extensions azure.ai.agents,azure.ai.models

Why this works for Day-0:

It's a one-time setup — the user just wants to get going. They shouldn't need to know azd core vs. extensions are separate things. The extension framework already handles OS/arch/checksums, so the install script just calls azd extension install after the core install.

Day-N (updates):

No changes — core updates via azd update, extensions update via azd extension upgrade. They release independently, they update independently.

Why Day-N stays separate:

Extensions exist because they are decoupled, different teams, different cadences, different release cycles. Merging updates would either couple those cadences or require coordinating across independent registries. Both add complexity for no user benefit. We also don't want extensions in package managers (brew, choco, winget) — that is a per-extension per-platform maintenance burden that doesn't scale.

@danieljurek @wbreza @kristenwomack @hemarina thoughts?

[hemarina]

I agree that core and extensions should release separately.

Install scripts: Adding --install-extensions to the install scripts makes sense for the piped-script scenario (curl | bash). For users who installed via brew, winget, or choco, we should document the chained command (e.g., choco install azd && azd extension install ) in the README once extensions are GA.

azd init: If users start from a template with azd init, requiredVersions.extensions in azure.yaml triggers auto-install of required extensions in init.go. Running azd up/provision commands won't triggered extension installation based on azure.yaml, we might want to consider supporting that in future.

azd updates: We may add a flag like --extension to update azd version + any installed extension version. Or we separate extension from azd updates and don't check extension.

[danieljurek]

azd isn't immediately available in the user's PATH after install in many cases... you need a new command line session and/or to update PATH in the user's current session. But we know the user's intended install location in the context of the script so I think installing an extension by invoking $INSTALL_PATH/azd extension install $EXTENSION should be doable in both install-azd.sh and install-azd.ps1

For package managers like choco, winget, and brew, there's not an obvious solution here to have the user specify extensions at install time unless we were to package the extensions up and release to those package managers (significantly bigger lift than current extension publishing and management)

On Windows, the $PATH story gets a little more interesting because package managers don't update the current session's $PATH environment variable. The user usually has to start a new command line session to get the updated $PATH.

Questions I have:

• Can multiple extensions be installed in a single command invocation or do we call azd extension install in a loop?
• How do we handle failures? Stop all subsequent extension installs? Keep going and tell the user some install failed?

[therealjohn]

All good suggestions, I will just add flavor to

azd init: If users start from a template with azd init, requiredVersions.extensions in azure.yaml triggers auto-install of required extensions in init.go.

In the agents extension there is a dedicated azd ai agent init command to work with manifest files, or show a specific list of templates - this is because we dont want full repositories for all templates that download READMEs, etc.

So in that happy path, users never hit this auto-install path.

[rajeshkamal5050]

@spboyer had this question - how are we handling this with brew and winget?

Core azd and extensions are two different install/upgrade paths today. This draft PR is a convenience shim on top of the script-based install (curl | bash, PS1) and it runs azd extension install after azd is set up.

Extensions are self-contained binaries managed by azd's own extension framework. Not sure we should even try to wire this into brew/winget, those package managers don't know about azd extensions and shouldn't need to.

Or should we skip this shim entirely and keep the two steps separate?

Thoughts? @therealjohn @wbreza @tg-msft @kristenwomack