Add support for "internal:" import scheme

[camh-]

With Go 1.16 having landed with a simple way for embedding files, the Importer should be extended to support the internal: scheme that imports from a fs.FS instance. Or perhaps something a little more generic - registering a scheme (not necessarily internal:) with a fs.FS so it is clear what application provides the files - e.g. jube://k8s/base.jsonnet would let you know it is an internal source in the jube application.

[juliaogris]

I've seen this called builtint:// in other places.

[camh-]

builtin:// would work too except it is hard to type ;-) (I mistyped it as buildin, and I'm pretty sure I've done builtint too like you have). For that reason alone, I think I'd stick with internal://.

I'm thinking perhaps internal://app/path/to/file, where app is specified as part of registering the fs.FS. This would allow an app to be extended to support another app's internal jsonnet stuff by registering a second fs.FS with that app's name, and existing jsonnet scripts that rely on that can continue to work. This could provide a path for application evolution, forking, etc.

[camh-]

I am now wondering how to define internal paths. The paths the Importer deals with are regular file paths, and netpaths (that start with a double-slash). These are not URLs/URIs, so internal:// feel wrong to use. For instance, the Importer does not support http:// or https:// paths even though it uses https internally to fetch netpaths.

The single unix spec for paths has this to say:

If a pathname begins with two successive characters, the first component following the leading characters may be interpreted in an implementation-defined manner

This means I could use //@internal or something. @ is not valid in a DNS name or hostname, and since I currently treat the first element of a netpath as a hostname/dnsname, I can overload it with invalid chars. I chose @ because it is not a shell metachar, so is easier to type on the command line.