In an XML document you can specify the XML schema location with `xsi:schemaLocation`. In a JSON document you can specify the JSON Schema location with `$schema`.
In a Cue document how do you specify the location of the Cue schema? As far as I can tell you can't.
And yes I am aware that the concept of a "document" and a "schema" are basically merged in Cue, but that doesn't mean I don't want to do this.
> CUE is most often used as a CLI, so no Go is needed
Only because that's the only way you can use it.
> Being Go, you can compile to SO or WASM
Compiling to a shared library is awkward because you then need to have the Go toolchain installed. WASM might be an option ... I couldn't find out how Go actually works in WASM though given that it needs a GC and threads, and WASM currently has neither. Do they ship their own WASM GC?
Either way, it's of no practical use since nobody has actually done that. Look at the languages supported by Jsonnet for comparison: https://jsonnet.org/ref/bindings.html
If I'm loading a config file from Python I don't want to have to mess around with `subprocess.run()` to read it. It's a solvable problem... but today, it's a bit of a turn-off.
I see you are not interested in CUE and the benefits it offers, despite being a young language without all the ecosystem yet
We subprocess.run because there are many problems better solved in CUE that make our other code so much simpler. I can't even tell you the 10s of thousands of lines I don't have to write, both python and other config languages require way more verbosity. There are upsides for the downsides to early adoption
> In a Cue document how do you specify the location of the Cue schema?
CUE has proper dependency management* so you specify the schema through dependencies and imports, like we do with most languages we use. JSON and Yaml are notable exceptions to this, and things like what XML and JSONNet do, referring to an http (or remote) location that may or may not serve the same content between requests, make for irreproducibility.
* or will soon, there will be an experimental version in the next cue release, and hof has had it for 2+ years now
> there will be an experimental version in the next cue release
Ah cool, I will check it out later then. Good to know people are working on the issue.
> CUE, running in the browser
No no. By "that" I mean "provide libraries for other languages that wrap it using WASM".
> I see you are not interested in CUE and the benefits it offers
That's a bad attitude. Would I have learnt how to use Cue and about these limitations because I wasn't interested? You just don't want to admit that these are valid concerns.
Subprocess.run is clearly not the ideal way to interface with a configuration language. You can do it if you have to. But you really shouldn't.
Imagine if the only JSON parser in the world was written in OCaml and every program that wanted to read JSON had to run some OCaml program to convert it into another format that they could load. Obviously not a good state of affairs.
I think we were probably talking past each other, my bad for continuing it
> Subprocess.run is clearly not the ideal way to interface with a configuration language.
100% agreement, but still better than the alternatives we had for addressing a complex problem.
yea, the interfaces to other languages is part of building out that ecosystem. The language is still changing a bit, but should hopefully stabilize in 0.8 or 0.9 (0.7 is going to bring significant performance improvements)
Yaml is another interesting case where there is inconsistent support and different defaults, depending on the library or tool. Config glues our world together, it's a complex mess because of where it sits. Everything we have today is cobbled together. To me, CUE offers a really great theory and foundation if we want to do something about it as an industry. Lord knows we're all suffering in YamHell
> You just don't want to admit that these are valid concerns.
I have my complaints and frustrations for sure, and I have been direct with the CUE team (in private) about some of the more sensitive issues, there are some comments on github and in public-ish documents if you're interested, mostly around the module proposal, which is in much better shape than anything written. The YT recordings are where the latest can be learned
In a Cue document how do you specify the location of the Cue schema? As far as I can tell you can't.
And yes I am aware that the concept of a "document" and a "schema" are basically merged in Cue, but that doesn't mean I don't want to do this.
> CUE is most often used as a CLI, so no Go is needed
Only because that's the only way you can use it.
> Being Go, you can compile to SO or WASM
Compiling to a shared library is awkward because you then need to have the Go toolchain installed. WASM might be an option ... I couldn't find out how Go actually works in WASM though given that it needs a GC and threads, and WASM currently has neither. Do they ship their own WASM GC?
Either way, it's of no practical use since nobody has actually done that. Look at the languages supported by Jsonnet for comparison: https://jsonnet.org/ref/bindings.html
Python, C, Rust (twice), Go (twice), Lua, Node, PHP, Ruby, Haskell.
If I'm loading a config file from Python I don't want to have to mess around with `subprocess.run()` to read it. It's a solvable problem... but today, it's a bit of a turn-off.