Track location updates correctly

Azure Dev CLI Install Instructions
Install scripts
MacOS/Linux

May elevate using sudo on some platforms and configurations

bash:
curl -fsSL https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/2778/uninstall-azd.sh | bash;
curl -fsSL https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/2778/install-azd.sh | bash -s -- --base-url https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/2778 --version '' --verbose --skip-verify

pwsh:
Invoke-RestMethod 'https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/2778/uninstall-azd.ps1' -OutFile uninstall-azd.ps1; ./uninstall-azd.ps1
Invoke-RestMethod 'https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/2778/install-azd.ps1' -OutFile install-azd.ps1; ./install-azd.ps1 -BaseUrl 'https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/2778' -Version '' -SkipVerify -Verbose

Windows
PowerShell install
powershell -c "Set-ExecutionPolicy Bypass Process; irm 'https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/2778/uninstall-azd.ps1' > uninstall-azd.ps1; ./uninstall-azd.ps1;"
powershell -c "Set-ExecutionPolicy Bypass Process; irm 'https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/2778/install-azd.ps1' > install-azd.ps1; ./install-azd.ps1 -BaseUrl 'https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/2778' -Version '' -SkipVerify -Verbose;"

MSI install
powershell -c "irm 'https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/2778/azd-windows-amd64.msi' -OutFile azd-windows-amd64.msi; msiexec /i azd-windows-amd64.msi /qn"

Standalone Binary

Linux -

x86_64 - https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/2778/azd-linux-amd64.tar.gz
ARM64 - https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/2778/azd-linux-arm64-beta.tar.gz

MacOS -

x86_64 - https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/2778/azd-darwin-amd64.zip
ARM64 - https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/2778/azd-darwin-arm64-beta.zip

Windows - https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/2778/azd-windows-amd64.zip

MSI

https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/2778/azd-windows-amd64.msi

Container
docker run -it azdevcliextacr.azurecr.io/azure-dev:pr-2778

Documentation

learn.microsoft.com documentation

title: Azure Developer CLI reference
description: This article explains the syntax and parameters for the various Azure Developer CLI commands.
author: alexwolfmsft
ms.author: alexwolf
ms.date: 09/22/2023
ms.service: azure-dev-cli
ms.topic: conceptual
ms.custom: devx-track-azdevcli
Azure Developer CLI reference
This article explains the syntax and parameters for the various Azure Developer CLI commands.
azd
The Azure Developer CLI (azd) is an open-source tool that helps onboard and manage your application on Azure
Options
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --docs         Opens the documentation for azd in your web browser.
  -h, --help         Gets help for azd.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

azd auth: Authenticate with Azure.
azd config: Manage azd configurations (ex: default Azure subscription, location).
azd deploy: Deploy the application's code to Azure.
azd down: Delete Azure resources for an application.
azd env: Manage environments.
azd init: Initialize a new application.
azd monitor: Monitor a deployed application. (Beta)
azd package: Packages the application's code to be deployed to Azure. (Beta)
azd pipeline: Manage and configure your deployment pipelines. (Beta)
azd provision: Provision the Azure resources for an application.
azd restore: Restores the application's dependencies. (Beta)
azd template: Find and view template details. (Beta)
azd up: Provision Azure resources, and deploy your project with a single command.
azd version: Print the version number of Azure Developer CLI.

azd auth
Authenticate with Azure.
Options
      --docs   Opens the documentation for azd auth in your web browser.
  -h, --help   Gets help for auth.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

azd auth login: Log in to Azure.
azd auth logout: Log out of Azure.
Back to top

azd auth login
Log in to Azure.
Synopsis
Log in to Azure.
When run without any arguments, log in interactively using a browser. To log in using a device code, pass
--use-device-code.
To log in as a service principal, pass --client-id and --tenant-id as well as one of: --client-secret,
--client-certificate, or --federated-credential-provider.
azd auth login [flags]

Options
      --check-status                           Checks the log-in status instead of logging in.
      --client-certificate string              The path to the client certificate for the service principal to authenticate with.
      --client-id string                       The client id for the service principal to authenticate with.
      --client-secret string                   The client secret for the service principal to authenticate with. Set to the empty string to read the value from the console.
      --docs                                   Opens the documentation for azd auth login in your web browser.
      --federated-credential-provider string   The provider to use to acquire a federated token to authenticate with.
  -h, --help                                   Gets help for login.
      --redirect-port int                      Choose the port to be used as part of the redirect URI during interactive login.
      --tenant-id string                       The tenant id or domain name to authenticate with.
      --use-device-code[=true]                 When true, log in by using a device code instead of a browser.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

azd auth: Authenticate with Azure.
Back to top

azd auth logout
Log out of Azure.
Synopsis
Log out of Azure
azd auth logout [flags]

Options
      --docs   Opens the documentation for azd auth logout in your web browser.
  -h, --help   Gets help for logout.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

azd auth: Authenticate with Azure.
Back to top

azd config
Manage azd configurations (ex: default Azure subscription, location).
Synopsis
Manage the Azure Developer CLI user configuration, which includes your default Azure subscription and location.
Available since azure-dev-cli_0.4.0-beta.1.
The easiest way to configure azd for the first time is to run azd init. The subscription and location you select will be stored in the config.json file located in the config directory. To configure azd anytime afterwards, you'll use azd config set.
The default value of the config directory is:

$HOME/.azd on Linux and macOS
%USERPROFILE%.azd on Windows

The configuration directory can be overridden by specifying a path in the AZD_CONFIG_DIR environment variable.
Options
      --docs   Opens the documentation for azd config in your web browser.
  -h, --help   Gets help for config.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

azd config get: Gets a configuration.
azd config list: Lists all configuration values.
azd config list-alpha: Display the list of available features in alpha stage.
azd config reset: Resets configuration to default.
azd config set: Sets a configuration.
azd config unset: Unsets a configuration.
Back to top

azd config get
Gets a configuration.
Synopsis
Gets a configuration in the configuration path.
The default value of the config directory is:

$HOME/.azd on Linux and macOS
%USERPROFILE%\.azd on Windows

The configuration directory can be overridden by specifying a path in the AZD_CONFIG_DIR environment variable.
azd config get <path> [flags]

Options
      --docs   Opens the documentation for azd config get in your web browser.
  -h, --help   Gets help for get.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

azd config: Manage azd configurations (ex: default Azure subscription, location).
Back to top

azd config list
Lists all configuration values.
Synopsis
Lists all configuration values in the configuration path.
The default value of the config directory is:

$HOME/.azd on Linux and macOS
%USERPROFILE%\.azd on Windows

The configuration directory can be overridden by specifying a path in the AZD_CONFIG_DIR environment variable.
azd config list [flags]

Options
      --docs   Opens the documentation for azd config list in your web browser.
  -h, --help   Gets help for list.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

azd config: Manage azd configurations (ex: default Azure subscription, location).
Back to top

azd config list-alpha
Display the list of available features in alpha stage.
azd config list-alpha [flags]

Options
      --docs   Opens the documentation for azd config list-alpha in your web browser.
  -h, --help   Gets help for list-alpha.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

azd config: Manage azd configurations (ex: default Azure subscription, location).
Back to top

azd config reset
Resets configuration to default.
Synopsis
Resets all configuration in the configuration path.
The default value of the config directory is:

$HOME/.azd on Linux and macOS
%USERPROFILE%\.azd on Windows

The configuration directory can be overridden by specifying a path in the AZD_CONFIG_DIR environment variable to the default.
azd config reset [flags]

Options
      --docs    Opens the documentation for azd config reset in your web browser.
  -f, --force   Force reset without confirmation.
  -h, --help    Gets help for reset.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

azd config: Manage azd configurations (ex: default Azure subscription, location).
Back to top

azd config set
Sets a configuration.
Synopsis
Sets a configuration in the configuration path.
The default value of the config directory is:

$HOME/.azd on Linux and macOS
%USERPROFILE%\.azd on Windows

The configuration directory can be overridden by specifying a path in the AZD_CONFIG_DIR environment variable.
azd config set <path> <value> [flags]

Examples
azd config set defaults.subscription <yourSubscriptionID>
azd config set defaults.location eastus

Options
      --docs   Opens the documentation for azd config set in your web browser.
  -h, --help   Gets help for set.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

azd config: Manage azd configurations (ex: default Azure subscription, location).
Back to top

azd config unset
Unsets a configuration.
Synopsis
Removes a configuration in the configuration path.
The default value of the config directory is:

$HOME/.azd on Linux and macOS
%USERPROFILE%\.azd on Windows

The configuration directory can be overridden by specifying a path in the AZD_CONFIG_DIR environment variable.
azd config unset <path> [flags]

Examples
azd config unset defaults.location

Options
      --docs   Opens the documentation for azd config unset in your web browser.
  -h, --help   Gets help for unset.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

azd config: Manage azd configurations (ex: default Azure subscription, location).
Back to top

azd deploy
Deploy the application's code to Azure.
azd deploy <service> [flags]

Options
      --all                   Deploys all services that are listed in azure.yaml
      --docs                  Opens the documentation for azd deploy in your web browser.
  -e, --environment string    The name of the environment to use.
      --from-package string   Deploys the application from an existing package.
  -h, --help                  Gets help for deploy.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

Back to top

azd down
Delete Azure resources for an application.
azd down [flags]

Options
      --docs                 Opens the documentation for azd down in your web browser.
  -e, --environment string   The name of the environment to use.
      --force                Does not require confirmation before it deletes resources.
  -h, --help                 Gets help for down.
      --purge                Does not require confirmation before it permanently deletes resources that are soft-deleted by default (for example, key vaults).

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

Back to top

azd env
Manage environments.
Options
      --docs   Opens the documentation for azd env in your web browser.
  -h, --help   Gets help for env.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

azd env get-values: Get all environment values.
azd env list: List environments.
azd env new: Create a new environment and set it as the default.
azd env refresh: Refresh environment settings by using information from a previous infrastructure provision.
azd env select: Set the default environment.
azd env set: Manage your environment settings.
Back to top

azd env get-values
Get all environment values.
azd env get-values [flags]

Options
      --docs                 Opens the documentation for azd env get-values in your web browser.
  -e, --environment string   The name of the environment to use.
  -h, --help                 Gets help for get-values.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

azd env: Manage environments.
Back to top

azd env list
List environments.
azd env list [flags]

Options
      --docs   Opens the documentation for azd env list in your web browser.
  -h, --help   Gets help for list.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

azd env: Manage environments.
Back to top

azd env new
Create a new environment and set it as the default.
azd env new <environment> [flags]

Options
      --docs                  Opens the documentation for azd env new in your web browser.
  -h, --help                  Gets help for new.
  -l, --location string       Azure location for the new environment
      --subscription string   Name or ID of an Azure subscription to use for the new environment

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

azd env: Manage environments.
Back to top

azd env refresh
Refresh environment settings by using information from a previous infrastructure provision.
azd env refresh <environment> [flags]

Options
      --docs                 Opens the documentation for azd env refresh in your web browser.
  -e, --environment string   The name of the environment to use.
  -h, --help                 Gets help for refresh.
      --hint string          Hint to help identify the environment to refresh

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

azd env: Manage environments.
Back to top

azd env select
Set the default environment.
azd env select <environment> [flags]

Options
      --docs   Opens the documentation for azd env select in your web browser.
  -h, --help   Gets help for select.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

azd env: Manage environments.
Back to top

azd env set
Manage your environment settings.
azd env set <key> <value> [flags]

Options
      --docs                 Opens the documentation for azd env set in your web browser.
  -e, --environment string   The name of the environment to use.
  -h, --help                 Gets help for set.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

azd env: Manage environments.
Back to top

azd init
Initialize a new application.
azd init [flags]

Options
  -b, --branch string         The template branch to initialize from. Must be used with a template argument (--template or -t).
      --docs                  Opens the documentation for azd init in your web browser.
  -e, --environment string    The name of the environment to use.
  -h, --help                  Gets help for init.
  -l, --location string       Azure location for the new environment
  -s, --subscription string   Name or ID of an Azure subscription to use for the new environment
  -t, --template string       The template to use when you initialize the project. You can use Full URI, <owner>/<repository>, or <repository> if it's part of the azure-samples organization.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

Back to top

azd monitor
Monitor a deployed application. (Beta)
azd monitor [flags]

Options
      --docs                 Opens the documentation for azd monitor in your web browser.
  -e, --environment string   The name of the environment to use.
  -h, --help                 Gets help for monitor.
      --live                 Open a browser to Application Insights Live Metrics. Live Metrics is currently not supported for Python apps.
      --logs                 Open a browser to Application Insights Logs.
      --overview             Open a browser to Application Insights Overview Dashboard.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

Back to top

azd package
Packages the application's code to be deployed to Azure. (Beta)
azd package <service> [flags]

Options
      --all                  Deploys all services that are listed in azure.yaml
      --docs                 Opens the documentation for azd package in your web browser.
  -e, --environment string   The name of the environment to use.
  -h, --help                 Gets help for package.
      --output-path string   File or folder path where the generated packages will be saved.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

Back to top

azd pipeline
Manage and configure your deployment pipelines. (Beta)
Options
      --docs   Opens the documentation for azd pipeline in your web browser.
  -h, --help   Gets help for pipeline.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

azd pipeline config: Configure your deployment pipeline to connect securely to Azure. (Beta)
Back to top

azd pipeline config
Configure your deployment pipeline to connect securely to Azure. (Beta)
azd pipeline config [flags]

Options
      --auth-type string             The authentication type used between the pipeline provider and Azure for deployment (Only valid for GitHub provider). Valid values: federated, client-credentials.
      --docs                         Opens the documentation for azd pipeline config in your web browser.
  -e, --environment string           The name of the environment to use.
  -h, --help                         Gets help for config.
      --principal-id string          The client id of the service principal to use to grant access to Azure resources as part of the pipeline.
      --principal-name string        The name of the service principal to use to grant access to Azure resources as part of the pipeline.
      --principal-role stringArray   The roles to assign to the service principal. By default the service principal will be granted the Contributor and User Access Administrator roles. (default [Contributor,User Access Administrator])
      --provider string              The pipeline provider to use (github for Github Actions and azdo for Azure Pipelines).
      --remote-name string           The name of the git remote to configure the pipeline to run on. (default "origin")

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

azd pipeline: Manage and configure your deployment pipelines. (Beta)
Back to top

azd provision
Provision the Azure resources for an application.
azd provision [flags]

Options
      --docs                 Opens the documentation for azd provision in your web browser.
  -e, --environment string   The name of the environment to use.
  -h, --help                 Gets help for provision.
      --preview              Preview changes to Azure resources.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

Back to top

azd restore
Restores the application's dependencies. (Beta)
azd restore <service> [flags]

Options
      --all                  Restores all services that are listed in azure.yaml
      --docs                 Opens the documentation for azd restore in your web browser.
  -e, --environment string   The name of the environment to use.
  -h, --help                 Gets help for restore.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

Back to top

azd template
Find and view template details. (Beta)
Options
      --docs   Opens the documentation for azd template in your web browser.
  -h, --help   Gets help for template.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

azd template list: Show list of sample azd templates. (Beta)
azd template show: Show details for a given template. (Beta)
azd template source: View and manage template sources. (Beta)
Back to top

azd template list
Show list of sample azd templates. (Beta)
azd template list [flags]

Options
      --docs            Opens the documentation for azd template list in your web browser.
  -h, --help            Gets help for list.
  -s, --source string   Filters templates by source.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

azd template: Find and view template details. (Beta)
Back to top

azd template show
Show details for a given template. (Beta)
azd template show <template> [flags]

Options
      --docs   Opens the documentation for azd template show in your web browser.
  -h, --help   Gets help for show.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

azd template: Find and view template details. (Beta)
Back to top

azd template source
View and manage template sources. (Beta)
Options
      --docs   Opens the documentation for azd template source in your web browser.
  -h, --help   Gets help for source.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

azd template: Find and view template details. (Beta)
azd template source add: Adds an azd template source at the specified key (Beta)
azd template source list: Lists the configured azd template sources. (Beta)
azd template source remove: Removes the specified azd template source (Beta)
Back to top

azd template source add
Adds an azd template source at the specified key (Beta)
azd template source add <key> [flags]

Options
      --docs              Opens the documentation for azd template source add in your web browser.
  -h, --help              Gets help for add.
  -l, --location string   Location of the template source.
  -n, --name string       Display name of the template source.
  -t, --type string       Kind of the template source.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

azd template source: View and manage template sources. (Beta)
Back to top

azd template source list
Lists the configured azd template sources. (Beta)
azd template source list [flags]

Options
      --docs   Opens the documentation for azd template source list in your web browser.
  -h, --help   Gets help for list.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

azd template source: View and manage template sources. (Beta)
Back to top

azd template source remove
Removes the specified azd template source (Beta)
azd template source remove <key> [flags]

Options
      --docs   Opens the documentation for azd template source remove in your web browser.
  -h, --help   Gets help for remove.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

azd template source: View and manage template sources. (Beta)
Back to top

azd up
Provision Azure resources, and deploy your project with a single command.
azd up [flags]

Options
      --docs                 Opens the documentation for azd up in your web browser.
  -e, --environment string   The name of the environment to use.
  -h, --help                 Gets help for up.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

Back to top

azd version
Print the version number of Azure Developer CLI.
azd version [flags]

Options
      --docs   Opens the documentation for azd version in your web browser.
  -h, --help   Gets help for version.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

Back to top

To give a bit more context on the change (and @weikanglim can correct me if I am wrong here), mostly for myself because I thought this was interesting and don't want to forget the discussion in two months.  This is fixing an issue we observed with our recorded tests where some LRO's behave in the following manner:

The initial response to the LRO status resource contains a URI that has a timestamp parameter.  When the SDK polls that LRO URI, it gets back an document that says the operation is in flight, and a new location header, with a changed value for timestamp query parameter.  We record this call.  We even noted in a helpful comment that the result could have a new location header to poll the next time:

https://github.com/Azure/azure-dev/pull/2778/files#diff-8e73573276a59988a38c1f9d76a431649cb09f7ed3f7436fdb54b57124991c51R207

The poller hits this new URI and gets another in-progress document and another new location header.  We elide this call and response from our recording, because we want to drop the intermediate request response pairs so that playback is faster.

When the operation finally completes, we note the request and response in the recording.  However, the request is for the URI that was returned by the last intermediate poll, and this URI does not match the Location header from the first recording (because the values of the query parameter changed each call).  That means on playback, after we replay the recording from (1), the poller will hit the URI returned by the location header, and we have no recording of that.

This change addresses the issue by hacking the recording such that the location header we recorded in (1) is updated when (3) happens, to point to the final URI.  From the point of the recording, it looks like the operation had completed by the time we first check it and everything works.
I think this is a wonderful fix for the issue.
Thanks to both @weikanglim and @vhvb1989 for a detailed internal discussion on the issue and for their detailed explanation of the underlying issue.  I get to learn something new every day!


Rewrite protomodelgen to remove logics from templates

Pull Request Test Coverage Report for Build 360669169

322 of 360 (89.44%)  changed or added relevant lines in 1 file are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage increased (+1.6%) to 88.098%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

gqlgenplugin/protomodelgen/plugin.go
322
360
89.44%

Files with Coverage Reduction
New Missed Lines
%

gqlgenplugin/protomodelgen/plugin.go
1
90.33%

Totals

Change from base Build 356908049:
1.6%

Covered Lines:
1288

Relevant Lines:
1462

💛  - Coveralls


Release 2023-07-31

:tada: This PR is included in version 1.19.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


"Show next change" doesnt unfold folded code

VS Code Version: v1.63.0
OS Version: 5.15.5-arch1-1

Steps to Reproduce:

With a VCS enabled (eg in a git repo)
Make a change in any function
Fold that function
Run "Show next change"

Expected: The function body is unfolded, document in scrolled and the change is visible.
Current: Document scrolls, but the change is not visible (because the function is folded).
PS. Intellij does it the right way ;)

This is happening because the logic to automatically unfold is currently based on the cursor, and the "show next change" function doesn't move the cursor. It scrolls but the cursor remains where it was.
The "go to next change" function does work properly. It moves the cursor to the next change and that location is unfolded automatically if it was collapsed.
The easiest fix would be to change the "show next change" function to move the cursor as well as popping up a description of the change. Does anyone see a reason not to do that? A harder fix would be to add an editor level internal function "expandIfCollapsed(position)", have it call into the folding model, and invoke it from the "show next change" code. Maybe there's another choice too. Martin?

As are reference, "Go to Next Problem" works as expected (unfolds the destination).

This action comes from is dirty diff decoration.

I agree with @PieterBranderhorst suggestion that Show next change should set the cursor as well, like other 'Next' commands.

There are two commands. Show next change shows the quick diff. Go to next change does the same and moves the cursor:

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.
Happy Coding!


feat(forge/create): opts for specifying gas price and priority fee

Motivation
Currently there is no way to specify gas prices when deploying contract with forge create nor does cast send supports --create. Adding --gas-price and --priority-fee option to forge create which users can use to specify the gas prices. Can be relevant when deploying on mainnet and want control over the cost.
Closes https://github.com/gakonst/foundry/issues/836

Solution
Adding the options and setting the gas price and priority fee before sending the deploy tx.

Do we also need the value argument ?

Do we also need the value argument ?

Can add that yeah, could be useful


fix: session replay respect feature flag variants

:bulb: Motivation and Context
JS PR https://github.com/PostHog/posthog-js/pull/1040/
:green_heart: How did you test it?
:pencil: Checklist

[x] I reviewed the submitted code.
[x] I added tests to verify the changes.
[ ] I updated the docs if needed.
[x] No breaking change or entry added to the changelog.

@pauldambra would you mind taking a look? since I will need to implement this across SDKs

@ioannisj @pauldambra done, please double check after changes, I will do Android next (Monday)


IE analysis package fails

Only when changing the "maximize" argument to False (which is the default value) it worked.

Did you update the monitoring binaries to the latest version? (As outlined when starting a recent version of Cuckoo - by running ./utils/community.py -wafb monitor).

My fault, thanks :)


Update tute 04 to MLJ 0.17 (julia 1.6)

Codecov Report

Merging #29 (2832df7) into dev (3fc1834) will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff          @@
##             dev     #29   +/-   ##
=====================================
  Coverage   0.00%   0.00%
=====================================
  Files          1       1
  Lines          4       4
=====================================
  Misses         4       4

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 3fc1834...2832df7. Read the comment docs.


Add explicit access token invalidation

An access token is invalidated by setting its expiration date to 1 January 1970, GMT.
Closes #40.

There is a slight feeling of this being a hack and thoughts about adding something like state to an access token: .Valid, .Invalid, .Expired

Agreed, adding state would certainly be less hack.

However, we would have to store that state and it's kind of non-spec.

Right. I think storing it internally wouldn't be a problem though because we don't differ from the spec in our external behavior.


🛠 Roadmap / To Do

This is Vapor's official to do list.
We welcome anyone and everyone to help us check off all of the items on this list. If you have any questions, don't hesitate to join us on slack.qutheory.io to ask.
To claim a to do item, create an issue for that item on the Vapor repository (the New Issue button up on the top right), assign the issue to yourself, and explain how you are going to solve it. Then, fork the repo and get started!

[ ] SSL (using OpenSSL)
[x] Validation
[ ] Cache
[x] Events
[ ] File uploads
[ ] Pass Web Frameworks Benchmark
[ ] Fluent
[x] Type-safe routing
[ ] NSURLSession wrapper
[x] Foundation free
[x] Type-safe controllers
[ ] CRON jobs
[ ] Add QA style questions to Stack Overflow under the Vapor tag
[x] Benchmark Vapor vs other frameworks
[ ] Look into combining Vapor with JS front-end frameworks
[ ] Fluent Mongo
[ ] Get the Kitura Server example working again
[ ] Add performance regression testing
[ ] Make a nice 404 page for all Vapor projects
[ ] Move the Request Date functionality into a fully Date class (to make up for lack of NSDate)
[ ] Make a Code of Conduct
[ ] Better Nginx integration + documentation
[ ] Add Zewo's MediaType to handle file types
[ ] Add CircleCI Support
[ ] Update Docs for Vapor 0.5
[ ] 100% Test coverage
[ ] 100% Documentation coverage
[ ] Websockets

We'll need to include Foundation to be able to wrap NSURLSession.

Yeah, Foundation Free is an old one. Hopefully as the Swift 3 release comes closer we can start using Foundation more reliably.

@tannernelson What do you mean by Add CircleCI support? Do mean moving the testing from Travis to CircleCI? Reason for asking is that I use CircleCI at work and I know it pretty well. What are you looking for?

@mpclarkson Yep that's exactly it... Travis is painfully slow and CircleCI’s FAQs seem to indicate they'll set us up for free with linux/mac since we're open source

Yes they do... they also provide 3 containers for open source projects so if you can run the tests in parallel, with some config. I'll have a go at this over the weekend... really want to get involved again but the last few weeks have been hell at work so I haven't had any time.

We have Circle CI available. Just need to get the .yml setup.

@tannernelson I'm working on the circle.yml now.

Support for the Jade templating language would also be wicked.

Also a Markdown renderer would be 👍

Plans for Content Negotiation?

Easier to manage these as separate issues. Let's do this in the future.


<2.2.3> 'Some Errors' while updating Thumbnail

Steps to reproduce
Hello,
I was playing with the YouTube.js. I found a problem with studio.setThumbnail. API call are going through correctly and response is returning 'OK' but thumbnails are not setting to the youtube video.
here's the code I used for the test
`import { readFileSync, writeFileSync, existsSync } from 'fs';
import { Innertube, UniversalCache } from 'youtubei.js';
const creds_path = './my_yt_creds.json';
const creds = existsSync(creds_path) ? JSON.parse(readFileSync(creds_path).toString()) : undefined;
(async () => {
const yt = await Innertube.create({ cache: new UniversalCache() } );
yt.session.on('auth-pending', (data: any) => {
console.info(Hello!\nOn your phone or computer, go to ${data.verification_url} and enter the code ${data.user_code});
});
yt.session.on('auth', (data: any) => {
writeFileSync(creds_path, JSON.stringify(data.credentials));
console.info('Successfully signed in!');
});
yt.session.on('update-credentials', (data: any) => {
writeFileSync(creds_path, JSON.stringify(data.credentials));
console.info('Credentials updated!', data);
});
await yt.session.signIn(creds);
// const file = readFileSync('./my_awesome_video.mp4');
// const upload = await yt.studio.upload(file.buffer, {
//   title: 'Wow!',
//   description: new Date().toString(),
//   privacy: 'UNLISTED'
// });
const thumb = readFileSync('./thumbnail.jpg');
const thumbUpload = await yt.studio.setThumbnail("DNpwu6qlrMc", new Uint8Array(thumb.buffer));
console.info('Done!');
console.info(JSON.stringify(thumbUpload));
})();
`
Failure Logs
{"success":true,"status_code":200,"data":{"responseContext":{},"overallResult":{"resultCode":"SOME_ERRORS"},"metadataUpdateVideoSupportedRenderers":{"videoListEntryRenderer":{"videoId":"DNpwu6qlrMc","title":{"title":"This is a test"},"lengthString":{"runs":[{"text":"1:30"}]},"thumbnail":{"thumbnails":[{"url":"https://i9.ytimg.com/vi/DNpwu6qlrMc/default.jpg?sqp=CMiYt5kG&rs=AOn4CLBZmxt3R5QzVy45uNIQZYJPe2AtOA","width":120,"height":90},{"url":"https://i9.ytimg.com/vi/DNpwu6qlrMc/mqdefault.jpg?sqp=CMiYt5kG&rs=AOn4CLCj4t083v3Fw1OGwckm_NV0JjLOww","width":320,"height":180},{"url":"https://i9.ytimg.com/vi/DNpwu6qlrMc/hqdefault.jpg?sqp=CMiYt5kG&rs=AOn4CLB-nN9exvZX-_7uTtI6iMRfblcP9Q","width":480,"height":360},{"url":"https://i9.ytimg.com/vi/DNpwu6qlrMc/sddefault.jpg?sqp=CMiYt5kG&rs=AOn4CLDBfMPNOANvslmbbxWVX5EmIx0Fnw","width":640,"height":480}]},"metrics":{"viewCount":"0","commentCount":"0","likesCount":"0","dislikesCount":"0","viewCountString":{"runs":[{"text":"No views"}]},"commentCountString":{"runs":[{"text":"No comments"}]},"likesCountString":{"runs":[{"text":"No likes"}]},"dislikesCountString":{"runs":[{"text":"No dislikes"}]}},"canEdit":true,"thumbnailIcons":[{"icon":{"iconType":"PRIVACY_PUBLIC"},"accessibility":{"accessibilityData":{"label":"Public"}}}],"videoDetailEndpoint":{"clickTrackingParams":"CAAQmUAiEwirlKzWmav6AhUPFLcAHS9ZAUo=","browseEndpoint":{"browseId":"FEvideo_detail","params":"6gENCgtETnB3dTZxbHJNYw%3D%3D"}},"trackingParams":"CAAQmUAiEwirlKzWmav6AhUPFLcAHS9ZAUo="}},"updatedHeader":{"creatorVideoDetailHeaderRenderer":{"videoTitle":{"runs":[{"text":"This is a test"}]},"videoThumbnail":{"thumbnails":[{"url":"https://i9.ytimg.com/vi/DNpwu6qlrMc/default.jpg?sqp=CMiYt5kG&rs=AOn4CLBZmxt3R5QzVy45uNIQZYJPe2AtOA","width":120,"height":90},{"url":"https://i9.ytimg.com/vi/DNpwu6qlrMc/mqdefault.jpg?sqp=CMiYt5kG&rs=AOn4CLCj4t083v3Fw1OGwckm_NV0JjLOww","width":320,"height":180},{"url":"https://i9.ytimg.com/vi/DNpwu6qlrMc/hqdefault.jpg?sqp=CMiYt5kG&rs=AOn4CLB-nN9exvZX-_7uTtI6iMRfblcP9Q","width":480,"height":360},{"url":"https://i9.ytimg.com/vi/DNpwu6qlrMc/sddefault.jpg?sqp=CMiYt5kG&rs=AOn4CLDBfMPNOANvslmbbxWVX5EmIx0Fnw","width":640,"height":480}]},"metrics":{"viewCount":"0","commentCount":"0","likesCount":"0","dislikesCount":"0","viewCountString":{"runs":[{"text":"No views"}]},"commentCountString":{"runs":[{"text":"No comments"}]},"likesCountString":{"runs":[{"text":"No likes"}]},"dislikesCountString":{"runs":[{"text":"No dislikes"}]}},"thumbnailIcons":[{"icon":{"iconType":"PRIVACY_PUBLIC"},"accessibility":{"accessibilityData":{"label":"Public"}}}],"playVideoEndpoint":{"clickTrackingParams":"IhMIq5Ss1pmr-gIVDxS3AB0vWQFK","watchEndpoint":{"videoId":"DNpwu6qlrMc"}},"editVideoEndpoint":{"clickTrackingParams":"IhMIq5Ss1pmr-gIVDxS3AB0vWQFK","creatorLegacyEndpoint":{"page":"METADATA_EDITOR","params":"DNpwu6qlrMc"}},"shareVideoEndpoint":{"clickTrackingParams":"IhMIq5Ss1pmr-gIVDxS3AB0vWQFK","shareVideoEndpoint":{"videoId":"DNpwu6qlrMc","videoShareUrl":"https://youtu.be/DNpwu6qlrMc","videoTitle":"This is a test"}},"playVideoLabel":{"runs":[{"text":"Play video"}]},"editVideoLabel":{"runs":[{"text":"Edit video"}]},"shareVideoLabel":{"runs":[{"text":"Share video"}]},"videoId":"DNpwu6qlrMc","playable":true}},"videoStill":{"success":false}}}

Expected behavior
studio.setThumbnail Should set the video thumbnail without any error.
Current behavior
studio.setThumbnail request is returning 'OK' response with 'Some Error'
Version
Default
Anything else?
No response
Checklist

[X] I am running the latest version.
[X] I checked the documentation and found no answer.
[X] I have searched the existing issues and made sure this is not a duplicate.
[X] I have provided sufficient information.

Sorry for the trouble. Looks like, the channel I was using wasn't verified and didn't have the custom Thumbnail enabled. It worked after verifying the channel.


minor fixes

... just typos and stuff I ran across while browsing the code ...

To me these changes look reasonable. I would suggest to merge them.


Failed to send SMS and Email  verification code.

All attemps will only result to error.

Looks like PR#1572 could fix that.


When applicant hits Submit, send auto-generated email to program admin for that program

That email shouldn't show any applicant data at all. Just say that an application was submitted at this date and time, and link the program admin to the admin page for that program.
The admin page for that program is defined in this product requirements doc.

Duplicate of #193


[AMORO-2647] fix getsnapshotdetail error when iceberg partition evolution

Why are the changes needed?

Close #2647.
Brief change log

To obtain the partition path of the native iceberg table, you need to bring the specID.

How was this patch tested?

[ ] Add some test cases that check the changes thoroughly including negative and positive cases if possible

[ ] Add screenshots for manual tests if appropriate

[ ] Run test locally before making a pull request

Documentation

Does this pull request introduce a new feature? (yes / no)
If yes, how is the feature documented? (not applicable / docs / JavaDocs / not documented)

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.huyuanfeng seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


cdylib on Windows provides only the .dll without the associated .lib import library

On Windows, runing cargo build on a cdylib crate produces only the .dll in target/{debug,release} while the associated .lib import library is missing.
However, the following files are present under target/{debug,release}/deps:

<name>-<hash>.dll
<name>-<hash>.dll.lib
<name>-<hash>.dll.exp
<name>-<hash>.pdb

The cargo and rustc versions in use are:

cargo-0.17.0-nightly (f9e5481 2017-03-03)
rustc 1.16.0 (30cf806ef 2017-03-10)

(originally opened as https://github.com/rust-lang/rust/issues/41393)

The import library is hardcoded to the name of the dll at the time of linking, so since cargo tells rustc to tell the linker to name the dll <name>-<hash>.dll, that means the import library is hardcoded to <name>-<hash>.dll. Considering the user actually wants to have <name>.dll, this is a major blocker towards being able to use cdylibs. Cargo needs to seriously rethink how it handles naming output artifacts.
cc @alexcrichton


Several authors, authors and categories profile

It is required to be able to specify several authors for the article, and also when clicking on the author, instead of filtering, receive a link to his profile.
For categories, I would also like to follow the link to the page, instead of filtering.

@mamedovramil For two of your requests there might be an easy solution available. If you do not want to filter authors or categories you might want to try and adapt the templates, especially templates/djangocms_blog/include/blog_meta.html:
{% if post.author %}

    {% trans "by" %} {% if post.author.get_full_name %}{{ post.author.get_full_name }}{% else %}{{ post.author }}{% endif %}

{% endif %}

Similarly in the same file adjust the category link:
{% if post.categories.exists %}
    {% for category in post.categories.all %}
        {% if category.slug %}

{{ category.name }}{% if not forloop.last %}, {% endif %}

        {% endif %}
    {% endfor %}
{% endif %}

The easiest way to adapt the templates is to copy them to your project into a valid template path and adjust them for your project.
While this does not provide the option for multiple authors I hope it at least solves your other issues.

@fsbraun thanks a lot, it helped! 2 of 3 questions closed.


Cannot find the scyllacloud import

I've been trying to use Scylla Cloud, but for some reason I'm not able to find the scyllacloud import.
Here's my go mod
module tempname

go 1.19

require (
	github.com/gocql/gocql v1.5.2
	github.com/scylladb/gocqlx/v2 v2.8.0
)

replace (
    github.com/gocql/gocql => github.com/scylladb/gocql v1.8.0
)

and the import:
import (
	"github.com/gocql/gocql"
	"github.com/gocql/gocql/scyllacloud"
	"github.com/scylladb/gocqlx/v2"
)

I just ran into this.
I had to change replace to:
replace github.com/gocql/gocql => github.com/scylladb/gocql v1.7.3

Then it works.

Could this be related to https://github.com/scylladb/gocql/issues/110 ?


Allow specifying dependencies for individual artifacts

This RFC proposes adding a way to specify dependencies (in a cargo manifest) that are only used for a single artifact (lib/bin/etc). This is intended to allow crate authors publishing multiple artifacts in a single crate to avoid pulling in dependencies unnecessarily, improving compile times and binary size.
Previous discussion
Rendered

@ehuss I've been reviewing @dmarcuse's efforts on this for a while now (she's a new contributor), and would like to say it's in a great state to get some official feedback. I believe you're the appropriate person here, so if you could have a look, that would be super! Thanks.

@ehuss I've been reviewing @dmarcuse's efforts on this for a while now (she's a new contributor), and would like to say it's in a great state to get some official feedback. I believe you're the appropriate person here, so if you could have a look and give any feedback, that would be much appreciated!

It would be great to have this fixed!
I'm a bit concerned about the proposed solution direction of adding separate per-target dependency tables -- as the RFC mentions, it would make it harder to get a good understanding of the different dependencies involved. Instead I would propose a new per-target features (name to be bikeshedded) key that lists the features that this target enables.
(I believe the second unresolved question would be solved with the new resolver that @ehuss is working on, starting from https://github.com/rust-lang/cargo/pull/7820.)

One of the stickler points in the past about this feature has been what to do about the crates.io index. The index is where Cargo learns dependency information for crates.io-sourced packages, and the dependencies (even optional/target-specific ones) are currently in the index. A relatively large change that this would naively require would be to update the index with all this new information. In any case I think it's important for the RFC to address the situation about the index.
I have an idea, however, which means that the index doesn't have to get updated (which is always a tricky thing to do). The main "target" that the crates.io index cares about is the library itself, not any binary, example, or test suite. The binaries and examples only come into play with cargo install. That is today that if we didn't do anything to the index, I don't believe we'd break anything currently using the index except cargo install. Typically Cargo usage would continue to work.
To fix cargo install I think we can have Cargo change how it implements cargo install. Currently it does resolution all on the index itself, but instead of that I think we can have Cargo download the crate file, read the full Cargo.toml to learn about all these new dependencies, and then proceed as usual.
Put another way, I think we can get away with not updating the index at all here and continue to function normally. In discussing this with other Cargo folks the main thing that we'd lose is a high-fidelity view into reverse dependencies because the index/crates.io would not be informed of bin-specific dependencies. We could try to fix that with extra JSON information on publish which doesn't go into the index, only crates.io's database, but it's altogether not the worst downside!

Instead I would propose a new per-target features (name to be bikeshedded) key that lists the features that this target enables.

I personally don't like the indirectness of this solution. It would be nice to allow binaries to enabled features as well, however. Like how downstream crates can.

@alexcrichton Sounds like a nice approach that doesn't lose too much in honesty. I guess it all depends how painful it would end up being to update the index, which I really don't know... but your solution as I understand is not what I'd called "hacky", at least! :-)

I'm not familiar with how the crates.io index works, but that sounds like a good workaround to me. Would it negatively impact build times when using cargo install?

One concern about not being in the index is that future changes like https://github.com/rust-lang/cargo/issues/4316 would be more difficult (not a blocker, just something to note).
It might be worth adding Swift to the "Prior Art" section, and taking a look at how they approached it.  Just a few days ago they released a new version that included essentially the same thing this RFC proposes. You can read more about it at https://github.com/apple/swift-evolution/blob/master/proposals/0226-package-manager-target-based-dep-resolution.md.   One interesting thing about their approach is that each target lists the dependencies it uses by name, but keeps the actual dependency declarations in one place.  I think that would be more similar to the idea of having a set of default features for a target that could enable optional dependencies.
I wouldn't completely dismiss the idea of using default target features instead. I think that would be substantially easier to implement, easier to integrate with tooling, would avoid the reverse-dependency problem, and be easier to document/explain.  It would also make some scenarios easier to express. For example, if you have 3 binaries that depend on clap, you would only need to list features = ["clap"] in each one, instead of the entire dependency specification (like dependencies = {clap = {version = "2.33", features=["suggestions", "color"]}}, which can be awkward to repeat and update, and maybe not even possible with the "only specified once" rule?).
It adds a level of indirection, but the simplicity seems attractive. It also can cause rebuilds of a library if you switch between different binaries with different features (not sure if there is a way to mitigate that, but with incremental should be very fast).

I agree that there's overlap with required-features, but I think this approach still has some benefits:

Conceptually, I find it easier to understand - compilation artifacts are already relatively distinct units (being compiled from different source files) and in my opinion it's more intuitive to assign dependencies to these directly rather than defining optional dependencies, features, and then required features for each artifact.
Less effort would be required by users to add dependencies to an artifact than defining new features in addition to optional dependencies
In my mind, features are generally meant to be a way to customize behavior and functionality of a crate. Using features to assign dependencies to different artifacts further overloads this functionality, and defining features that effectively serve no purpose (e.g. a feature that enables required dependencies for a bin but has zero effect on the lib) seems inefficient and more confusing.

I don't think anyone is arguing that there's overlap with required-features -- that field seems to be about a precondition for building a target, whereas this RFC is about dependencies of the target once the decision to build it has been made. Both use features, but for very different purposes.
While the bin build targets are distinct, cargo builds a single large dependency graph (with one root per target) to build all the targets for a particular build command invocation.
In the case of adding dependencies to a single build target, it is arguably a bit more work (but note that dependencies marked as optional = true implicitly introduce a feature of the same name). On the other hand, if you have a dependency like clap for more than one build target, the features approach would actually result in less work: for the second target, you just toggle on the feature rather than having to respecify the full details for the same dependency (and having to keep them in sync for the future).
It seems to me that features are already defined crate-wide, so the situation of features being defined for a lib that also influence a bin target is already happening anyway. Managing dependencies seems to me one of the primary applications of features in the first place, so reusing the same mechanism here would be sensible.
In any case, the features approach should be clearly explained in the alternatives section, with the attendant advantages and disadvantages.

it's more intuitive to assign dependencies to these directly rather than defining optional dependencies, features, and then required features for each artifact.

To be clear, I wasn't advocating doing anything with required-features.  Just adding a list of "enable these features when this target is built".

Less effort would be required by users to add dependencies to an artifact than defining new features in addition to optional dependencies

I think it will be more work if you have more than one target that wants to use the same dependency.  Although for the single-use situation it is less work, the difference is pretty small. Compare:
[dependencies]
clap = {version="2", optional=true}

[[bin]]
name = "foo"
features = ["clap"]

to:
[[bin]]
name = "foo"
[bin.dependencies]
clap = {version="2"}

Mostly a difference of one line.  I agree that conceptually it is not as straightforward in this simple case, but once you have just one more binary, it becomes worse.
And it becomes conceptually more complex for any tool that works with Cargo's dependencies. They will all need to be updated to handle target-specific dependencies, whereas with features most of them should work as-is.
It's also not clear to me what happens if multiple targets define dependencies on the same thing.  Do they have to be exactly the same?  If there are differences, how are those handled?

defining features that effectively serve no purpose … seems inefficient and more confusing.

How would it be inefficient?  I believe it would be essentially zero cost.

From my perspective, having bin targets enabling features would be something of an abuse of the purpose of features. As far as I know (and intuitively), they're meant to be externally-facing boolean parameters that change the feature set (and only as a by-product the dependencies) of a particulate crate that is getting used. Sometimes a bin target would conceptually want to enable a feature for the crate lib, because that's the nature of the binary, but sometimes it just needs a few extra dependencies. That would entail creating a dummy feature, which would itself be usable by downstream crates (not intended), and would require a dummy name which is referenced in bin.dependencies as a dependent feature. By all means, allow bin targets to depend on features, but I think the fundamental point of this RFC is to allow them to have dependencies directly, for the above reasons and because it's so much more natural and intuitive to reason about.
As for the "cost", I don't think there's anything more than the most minute cost for the more indirect feature-based approach, but I would hazard a guess that @dmarcuse meant "inefficient" in terms of characters in the Cargo.toml file or perhaps "conceptually" inefficient, akin to what I just described (correct me if I'm wrong).

Yep, @alexreg is exactly right about what I was trying to say.

I find it annoying when I run cargo build --bin foo and Cargo refuses, because I haven't enabled the required features.
To me it's an unnecessary error and artificial self-inflicted problem: Cargo knows what I mean, and could do what I mean, but refuses on principle.
So I'd like to see a more lenient handling of required-features anyway.

Cargo is somewhat undecided about what should be in scope of a single crate, and what should be a workspace.
For example, Cargo is supposed to discourage users from having both lib and bin targets in a single crate: https://github.com/rust-lang/api-guidelines/issues/167
And this feature goes in the other direction: helps having more targets in a single crate.
So maybe this feature should not exist?

It would be a clear guideline that if you have targets that need different dependencies, then they are supposed to be separate crates in a workspace.

Avoids overlap with required-features

Avoids complicating the crates index. Currently the index is super valuable for analysis of the ecosystem. It's way easier to use one git repo than to download all tarballs of all versions of all crates.

@kornelski you bring up some good points, but I disagree with your perspective that separate crates in a workspace should be used here. Using separate crates does allow you to fully separate the dependency trees in a way that's already supported by cargo, but it introduces its own complexities:

There's no way to make a symbol accessible to workspace members only, meaning there's no way to avoid publicly exporting a symbol that's needed by a binary depending on a library.
Because there are now two separate crates, the orphan rule kicks in, making it impossible to implement foreign traits for types from the library in the binary. For a specific example, I was working on a project where I had several types defined in the library, and wanted to implement postgres_types::FromSql for them in the binary, and instead had to write wrapper types and implementations, duplicating a significant chunk of the code.

How do you relax coherence across artifacts? AFAIK pub(crate) doesn't actually mean the whole crate. I struggle to export non-public stuff from lib.rs in to tests/*.
warning: function is never used: `pub_crate`
 --> src/lib.rs:1:15
  |
1 | pub(crate) fn pub_crate() {}
  |               ^^^^^^^^^
  |
  = note: `#[warn(dead_code)]` on by default

error[E0603]: function `pub_crate` is private
 --> src/main.rs:4:14
  |
4 |     mycrate::pub_crate();
  |              ^^^^^^^^^ private function
  |

Anyway, there's some consideration to opening up coherence rules to workspaces: https://github.com/rust-lang/rfcs/issues/1856 so making workspaces more crate-like may be an alternative to making crates workspace-like.

The idea is that binary artifacts would directly include the modules of the library, such that they're in the same crate when compiled. This allows you to use pub(crate) items and bypass the orphan rules since you're not using the library as a dependency, but rather using its code directly. Here's a trivial example with visibility:
// example.rs
pub(crate) fn internal_hello() -> &'static str { "hello world" }
pub fn say_hello() { println!("{}", internal_hello()); }

// lib.rs
mod example;
pub use example::*;

// bin.rs
mod example;
pub fn main() {
  let mut hello = String::from(example::internal_hello());
  hello.make_ascii_uppercase();
  println!("{}", hello);
}

It isn't possible to directly port this to a workspace without exposing implementation details (making internal_hello public), duplicating the definition, or I suppose by abusing the #[path] attribute on modules.

That's cheating :) Compiling the same file twice in different targets gives you two copies of the code, two instances of the types. It's the #[path] hack, but the path happens to be ..

Using two artifacts sharing the same modules, the code is compiled twice similarly to if I were to use the #[path] attribute in a workspace. However, the difference is that with artifacts, I can define common dependencies that are used by these shared modules, as well as a build script, profile options, and so on. All of these would need to be duplicated with a workspace, as the artifacts are now separate packages.

I guess the point I'm trying to build here is that for smaller projects where the binary is little more than a friendly wrapper around the functionality of a library, using a workspace results in a lot of duplication of effort when the desired end goal is just adding an extra dependency or two for a binary artifact, but not the main library.

As a counterpoint I have a trivial 136 line CLI wrapper for a library, in a separate crate, of the 25 lines of Cargo.toml about half of them would still be relevant if I were to integrate the binary into the same crate. Saving <10% of the total LOC for the CLI isn't a massive deal.
I was initially for this proposal, but thinking about it I would definitely not use it even if implemented. I find it very useful to be able to separately version and document the binary from the library. If you visit https://crates.io/crates/dotenv or https://docs.rs/dotenv are you going to notice that dotenv also provides a binary (maybe you'll notice it has an optional clap dependency), and if so will you have any idea what it does? If they were to thoroughly document the binary, then someone reading the documentation purely for the library could find that to be largely unnecessary.

Whatever viewpoint one takes, I don't like being stuck in a halfway house. Either we should move towards an enforced no-binaries-per-crate (away from the status quo) or improve the ergonomics for the existing situation with multiple binaries. I'm obviously favour of the latter, but the worst outcome is staying exactly as we are now.

This is also about end user experience. For example, if I am building something called cool and I have a library and binary for it, I want people to use simply like:
[dependencies]
cool = "1.0"

cargo install cool

Simple, straightforward, and awesome.
If I make the binary live in a separate crate, then the installation command changes:
cargo install cool-cli

This is not really that big of an issue, but as I said, it's all about the user experience.

Adding a comment / personal anecdote from user experience perspective.
Working on a project, I decided to start splitting it into a library and binary. I decided to try the feature flag approach as described in various places. When working on that, my editor suddenly stopped showing tooltips and even errors related to things that were behind a feature gate.
The crux of the issue there was that cargo check, and any editor integration depending on it, does not check any code that is behind a feature flag. You have to explicitly call it with cargo check --features yourfeature or cargo check --all-features in order to get any possible error messages or warnings for something behind a feature gate. Alternatively, you have to know to enable an editor setting that makes it check with all features, or similar (see e.g. https://github.com/rust-analyzer/rust-analyzer/issues/3897).
While this is certainly doable, it doesn't exactly speak ideal user experience: my editor looked fine, my cargo check looked fine, and the first time I saw an error after some edits was when I tried cargo run --features myfeature. Considering how excellent Rust is when it comes to helpful error messages, the sudden silence had me thoroughly surprised.
Native support for lib- and bin-specific dependencies could have prevented this: it could be safe for cargo check, editors and others to assume to check both targets by default, whereas apparently --features can occasionally be conflicting (even by design) and --all-features might not be usable (see e.g. https://github.com/rust-analyzer/rust-analyzer/issues/3897#issuecomment-655317883 )
The workarounds I could have are to 1) make sure code checks are run with correct parameters in my project 2) move from feature flags to a workspace split approach, essentially having two separate crates 3) go back to having a single bundle with all dependencies for simplicity in a personal project

I summarized all the above mentioned concerns with the proposal below:

If you have more than one target that wants to use the same dependency, it is more work
Tools that work with cargo dependencies need to be updated to handle this

Given below are concerns for the feature approach proposal:

More effort to define a feature and use it rather than specifying the dependency directly
Features as a concept are supposed to be externally facing booleans that provide a way to customize the behaviour and functionality of the crate
Features has poor user experience regarding IDEs and should be discouraged wherever possible

I think we all agree on the following:

No issues/problems with getting cargo (& index) to work with either of the proposals.

Some people disagree with both of these proposals because they prefer to have targets in different crates. I want to note that implementing either of these will not be stopping users from following that approach.
There is one point that has been mentioned but has not got enough attention:

The targets might want to enable some features on the lib

If you think about the scenarios where this happen, we can easily deduce that we definitely need a way to define the enabled features for targets which can be solved only the feature based proposal.
To reiterate, feature based proposal is:

Allow list of features to be specified for the target which will be enabled when that target is being built. This ties in nicely with required-features.

This definitely solves the issue this RFC is targetting, and we can always add dependencies as a better UX alternative later.

I have made an RFC with the discussion from here. https://github.com/rust-lang/rfcs/pull/3020

This definitely solves the issue this RFC is targeting, and we can always add dependencies as a better UX alternative later.

Doesn't changing the enabled features trigger a full rebuild of the lib target?

I don't see it on the RFC so I thought i will ask but does
[bin.dependencies.myproject_cli]
clap = "*"

and
[bin.dependencies.myproject_cli.clap]
version = "*"

would work ? Or maybe this syntax is induced by that of the RFC (I am not a toml expert)

I summarized all the above mentioned concerns with the proposal below:

If you have more than one target that wants to use the same dependency, it is more work

Why not use the optional syntax for this concern ?

Also, I wanted to share another use case for this i haven't saw. It would be to use only some portion of code of a package, without including his dependencies. I don't think you could to that without this rfc.

@rfcbot close
#3374 was created as an alternative to this but has since been closed.  A major problem that had that is also shared with this is that it takes an existing problem for users (feature unification) and applies it not just to the package level but to the individual build target (see https://github.com/rust-lang/rfcs/pull/3374#discussion_r1235768792).  Adding new dependencies tables would also cause a significant ecosystem churn that we need to be mindful of.
Note also that this isn't the only problem in dealing with wanting a package to scale to complex build targets needs.  We discussed this as a team.  For myself, I think we should focus more on improving the experience with workflows before we re-evaluate how much more we should do for improving complex package needs.

I'd have liked this RFC or something like it such that, if I have a binary and a library in the same crate, where the binary requires clap and the libary does not, I can (maybe with setting some configuration in the Cargo.toml or other config files) use:
cargo build --lib

to build just the library without pulling clap into the dependency tree, or
cargo build --bin <bin_name>

to build the binary with clap as a dependency.
The current required-features behavior doesn't meet that, since I have to know all the required features and explicitly provide them (which can be hard to remember and type, since there might be a bunch of them) or let cargo give me an error, copy the list of required features and then try again with those features pasted in (which takes extra steps).
With this RFC being closed, is there any path towards that behavior being possible that's being pursued?

@JarredAllen did you already read the discussion referenced in https://github.com/rust-lang/rfcs/pull/2887#issuecomment-2123012589?