Decide how to set the `publisher` field for extensions

jennybc commented 2 weeks ago

I'm talking about this, e.g.:

A possibly incomplete list of technical implications:

An extension can register a URI handler, which is something I'm implementing for positron-r, starting with #5231. An extension can only handle URIs addressed to it, which means they must start like so:

{product-name}://{publisher}.{extension.name}

In #5231, I've made positron the publisher of positron-r. That's not written in stone, but I'm quite sure it should not be vscode. For "normal" (meaning: not built-in) extensions, this really is a publisher in the marketplace sense and, when such a URI is activated, it leads to activation and/or installation of said extension.
If we offer a way for folks to launch Positron without any non-built-in extensions, similar to --disable-extensions, you could imagine the publisher field possibly being relevant.
Unknown unknowns: what happens if we switch all of "our" (for some definition of "our", see below) extensions to have positron or posit as the publisher? Literally, what happens with our tests?

More questions:

What should the publisher be? positron? posit?
- The Shiny-related extensions are published by Posit in both the VS Code Marketplace and in the OpenVSX Registry, so I suspect it would be confusing to use posit for extensions, like positron-r, that are built-in.
Which extensions should we change publisher for? The positron-* extensions seem like a clear yes, although positron-python is a special duck. Anything else?

Docs on publishing, which include a wee bit on the significance of the publisher field (though not much relevant to our case):

jennybc commented 2 weeks ago

jmcphers commented 1 week ago

Triage:

we can use posit for extensions we publish to the Marketplace and positron for extensions that are built-in (positron-r, positron-python, etc.)

posit-dev / positron