Shorthand URL syntax for 3rd-party templates on GitHub

[msgilligan]

Description

It would be nice if there where some kind of short-hand syntax for referencing templates in GitHub projects, so users could do something like:

limactl start github:nixos-lima/nixos-lima

where:
github:nixos-lima/nixos-lima ->
https://raw.githubusercontent.com/nixos-lima/nixos-lima/master/templates/default.yaml

The details of the github: URL could be fairly simple or have features (like branch/tag/hash specifiers) similar to schemes in other projects. For example:

• Nix flake references
• NPM

[afbjorklund]

I did this for the GUI

Well partially, at least

if (url.startsWith("https://github.com")) {
        // Get the "raw" YAML, and not the prettified HTTP
        url = url.replace("github.com", "raw.githubusercontent.com");
        url = url.replace("blob/", "");
}

Not the shorthand

[jandubois]

I like the shorthand, as long as it allows appending a non-default template name as well, e.g. github:org/repo/path/template.lima.

We probably should then add a corresponding scheme for gitlab, for vendor neutrality.

But this makes our current template URLs even more grating because they are not RFC3986 compliant: When a URL path component starts with // it MUST be followed by an authority¹. So our template URLs should have been either template:default or template:///default to show the absence of an authority segment.

So if we add github:org/repo/... URLs, then we should also support template:name URLs (and maybe add a warning for the old format?)

Footnotes

1. When authority is present, the path must either be empty or begin with a slash ("/") character. When authority is not present, the path cannot begin with two slash characters ("//"). ↩

[afbjorklund]

I'm fine with renaming from template:// to template:, the "scheme" was always a bit confusing

[jandubois]

I've added a URL scheme plugin system in #3937 and the PR summary has a sample implementation of a github: scheme.

The PR needs some error handling improvements, and the github: scheme should eventually be builtin, but you can experiment with it to figure out what the desired semantics should be for the new scheme.