allow import declaration to load jsonschema

[cueckoo]

Originally opened by @proppy in cuelang/cue#438

Is your feature request related to a problem? Please describe.
Currently one has to rely on cue import to bulk convert JSON schema into CUE package in order to consume them from other .cue files.

Describe the solution you'd like
Instead it would be nice to be able to import path/to/some.schema.json.

Describe alternatives you've considered
Using a dedicated cue tool (or maybe cue.mod/gen?) it ma ybe be possible convert JSON schema on the fly before importing them, but since the command line already support evaluation of JSON schema argument, it could make sense for cue to support native JSON schema import as well.

Additional context
This might be beneficial for project relying on a large corpus of existing (or third-party) schemas, who wants to validate/transform/compose them using CUE without the overhead of maintaining a separate imported copy.

[cueckoo]

Original reply by @proppy in cuelang/cue#438 (comment)

quick and dirty proof of concept: https://cue-review.googlesource.com/c/cue/+/6541

[cueckoo]

Original reply by @mpvl in cuelang/cue#438 (comment)

A few remarks:

• this will need a thorough design doc also keeping in mind other import extensions
• we should really move most if not all the json/yaml/ etc logic of loading file formats from cmd to load.
• we should not do auto detection for JSON vs JSON Schema, and relying on extensions is probably too limiting. It may make sense therefore to allow qualfiers like: import "jsonschema:foo.json".
• we should consider allowing imports relative to the root of a module, like import "/path/to/pkg". In thta case, does the format import "jsonschema:/path/to/pkg/foo.json" work? (I think so, but needs to be checked)
• we should probably keep open the possibility of bulk-loading json files. Can we think of a syntax that would be compatible with what we do now that makes sense?

[cueckoo]

Original reply by @proppy in cuelang/cue#438 (comment)

this will need a thorough design doc also keeping in mind other import extensions

Do you have a template for the project I could use?

we should really move most if not all the json/yaml/ etc logic of loading file formats from cmd to load.

Are you referring to https://github.com/cuelang/cue/blob/master/cmd/cue/cmd/import.go, I don't see much logic in there that's not specific to command line argument, are you suggestion that we generalize it so that the same parameters (interpretation/mode) can be passed in the import directive?

we should not do auto detection for JSON vs JSON Schema, and relying on extensions is probably too limiting. It may make sense therefore to allow qualfiers like: import "jsonschema:foo.json".

👍

we should consider allowing imports relative to the root of a module, like import "/path/to/pkg". In thta case, does the format import "jsonschema:/path/to/pkg/foo.json" work? (I think so, but needs to be checked)

Do you have more details on how root module relative imports work? I couldn't find them mentioned in https://cuelang.org/docs/concepts/packages/

we should probably keep open the possibility of bulk-loading json files. Can we think of a syntax that would be compatible with what we do now that makes sense?

I wonder if defining a package layout for jsonschema (and other foreign data) would make sense (similar to what's done w/ pkg and gen), a way to refer to package that are bulk imported could be thru their $id, since this is how jsonschema refer to the canonical identifier of the schema: https://json-schema.org/draft/2019-09/json-schema-core.html#rfc.section.8.2.2

[myitcv]

@proppy just skimming over this again whilst browsing through old issues, I note there is no mention here of a planned embedding proposal that effectively supersedes this issue in that it would be far more powerful. The proposal is yet to be written, but it will be analogous to the //go:embed style of embedding but likely using attributes, and as a result hopefully more generally useful because it could be used to embed anything: JSON schema, JSON, Yaml, any file as a string, a "file system" map etc. I will link that proposal when it gets posted.

[myitcv]

I'm going to close this issue in favour of #2031. We are just about to publish a proposal for the embed part of that issue, along with an experimental implementation. As you will see from #2031, we explored the prospect of extending imports to support more than just CUE, but the approach using embed ended up being cleaner, more easily suited to different use cases, and very much in-line with existing support for multiple file types and interpretations.