VS Code's appmoniker is "vscode", not "code"?

[Tyriar]

The CLI for VS Code is code/code-insiders and as a result the deb/snap/rpm packages are named code and code-insiders. The winget package should do it as well. I'd like to make this change if it sounds good.

[Tyriar]

cc @KevinLaMS

[NatoBoram]

I think code is not a good name because it's prone to conflicts. Non-Microsoft projects referencing it are using the moniker vscode. For example, Scoop and Chocolatey.

[andrewbaker-uk]

I have to agree with @NatoBoram on this. It's also known as vscode on chocolatey.

[Tyriar]

It's only known as vscode on chocolatey because it's not an official package. If it were it would be consistent with the rest of the packages and the CLI.

[NatoBoram]

It's still inherently a bad name for being so prone to conflict. For example, even code on Elementary OS changed their moniker to io.elementary.code. VSCode's repo is also vscode, obliterating your only argument.

[Tyriar]

I don't know if "vscode is used somewhere" obliterates my argument. My argument is to align it with the cli for ux/discoverability reasons:

winget install code
code

apt install code
code

I brought up when I joined the team these potential conflicts with a generic name like code and maybe changing the cli to vscode, but the decision was to keep the cli as code, so packages have inherited that.

[felipecrs]

How about to support 2 monikers?

[Tyriar]

@felipecassiors that's the preference

[denelon]

The value "code" makes sense in the "Commands" key, but we've seen more preference for "vscode" as the value for the "AppMoniker" key.

[Tyriar]

@denelon the docs say

# List of commands or aliases the user would use to run the package.

Does winget install code work/redirect to it?

[felipecrs]

No, because of multiple matches.

Maybe we should invest in winget install --comand instead, like --moniker?

[denelon]

@felipecassiors or @Tyriar if you think that feature would have merit, go ahead and create it in the cli repository. I would expect we might still have a collision between manifests of the released version and the stable version if the meta-data were similar between the two, but the results would be narrowed down.

[Tyriar]

The value "code" makes sense in the "Commands" key, but we've seen more preference for "vscode" as the value for the "AppMoniker" key.

@denelon based on this isn't not more of a preference:

Additionally, the preference of the VS Code team is to use code and code-insiders such that winget install code works and it matches the CLI, ideally with both being supported.

It's not clear what the concern about conflicts is, if an app as popular as VS Code comes around and wants to use "code" as well? Searching will still work, just install code should install vscode so it matches the experience on other platforms.

[felipecrs]

But @Tyriar, that's not how winget works. In winget world there is not unique and claimable id (different from Chocolatey, Snap, and most of the package managers). The closest thing to it is the Manifest ID, but vscode or code isn't a value that fits in it.

It's not clear what the concern about conflicts is, if an app as popular as VS Code comes around and wants to use "code" as well? Searching will still work, just install code should install vscode so it matches the experience on other platforms.

Monikers are not unique, neither claimable, if two exist, winget will narrow down both, and then you have to choose using the Manifest ID.

The bottom line is there is no way to guarantee winget install code (or vscode) will always install VS Code. But still, vscode moniker can be changed to code.

Or, as I said, what if we ask support for more than one moniker for a manifest? @denelon any opinion?

[felipecrs]

I would expect we might still have a collision between manifests of the released version and the stable version if the meta-data were similar between the two, but the results would be narrowed down.

@denelon in this case, use -e: winget install --command code -e. The Insiders version of VS Code has a different command: code-insiders.

[Tyriar]

But @Tyriar, that's not how winget works. In winget world there is not unique and claimable id (different from Chocolatey, Snap, and most of the package managers).

Ok I didn't know this, thanks.

The bottom line is there is no way to guarantee winget install code (or vscode) will always install VS Code. But still, vscode moniker can be changed to code.

This seems like a real shame. People want to use winget to automate their setup, but there's no way to guarantee that a command will not require manual intervention?

[denelon]

Now that the "import" command is available, you can use the "PackageIdentifier" which is unique to a package, and you can build a JSON file with several packages. The Version field can also be used to request a specific version.

[felipecrs]

This seems like a real shame. People want to use winget to automate their setup, but there's no way to guarantee that a command will not require manual intervention?

I meant by using the moniker. But you can do it by using the manifest id:

winget install -e Microsoft.VisualStudioCode

[Tyriar]

@felipecassiors 👍 ok great, this is what I'll recommend using in the docs then. As for the moniker, supporting both code and vscode would be best as you suggested.

[felipecrs]

@felipecassiors 👍 ok great, this is what I'll recommend using in the docs then. As for the moniker, supporting both code and vscode would be best as you suggested.

There is also a feature request accepted, that will prevent you to have to use the -e option:

microsoft/winget-cli#292 - spec

But until there, it is safer to use the -e switch (mainly if the Insiders version of VS Code is also coming).