Rationale for "std" implicit import and a CUE dialect

[verdverm]

I'm curious as to the rationale behind https://github.com/acorn-io/acorn/blob/main/pkg/appdefinition/std.cue and the subsequent CUE dialect is created?

This means acorn is not CUE, yet it retains the .cue extension. This, I suspect, will be confusing to users who know CUE, but also means that cue cannot be used (reliably) with acorn (cue?) files. This is a non-starter for a lot of people already.

There is a related discussion about CUE dialects and fracturing the ecosystem: cue-lang/cue#350

CUE Slack thread going on now: https://cuelang.slack.com/archives/CLT3ULF6C/p1659539370425999

Acron looks like a highly desirable project, are you open to using CUE as the input?

[ibuildthecloud]

We want a restricted subset of CUE. The biggest point of feedback for early users of Acorn was the difficulty of learning and understanding CUE. We have no use case for modules, schema and a lot of the unique features of CUE.

We purposely removed all user facing references to cue and have internally referred to the syntax as Acorn Markup Language. The file you are referring to is internal but I'll gladly rename it.

We didn't feel right leveraging so much of CUE and not giving credit to CUE so we wanted to make it clear this was a derivative of CUE to give credit to the CUE authors. You are absolutely right that what Acorn is using is not CUE.

[verdverm]

Modules and shemas are what we have with Helm and really want more generally in DevOps as we look to escape YamHell. They will bring a whole new level of reuse and sanity to the field. It's surprising to see you say they are not needed.

What's the acorn equivalent of a helm chart or terraform module?

[sheng-liang]

Acorn is our answer to Helm Charts. We've been working with Helm Chats for many years and have had our share of struggles. We wanted to create an alternative way to package apps for Kubenetes which led us to creating Acorn.

[verdverm]

I'm not seeing anything about how I can import and use community created modules. The original reply seems to imply that import like capabilities, or the lack of, is an intentional design decision.

We have no use case for modules

This is the use-case we have in devops, where CUE can become the language of the field due to its ability to support modules and the data codecs all of our other tools consume.

Are you referring to Acorn "is the answer" to Helm's text/templating Yaml? I'm referring to the ability of the community to create an ecosystem of reusable and shareable modules. This isn't limited to Helm, but is prevalent in most devops tools [helm, terraform, ansible, et al]

[sheng-liang]

We have no use case for modules in CUE because Acorn itself is the module for building applications. Every Acorn image is described by an Acornfile, which is expressed in a markup language derived from CUE. Acornfile is like Dockerfile. It's always self-contained. There's no need for an Acornfile to import another Acornfile.

[vincent99]

Yes, the things we've omitted like schemas, modules, imports, etc ARE very much intentional design decisions. Using cue as a pseudo-programming language and ultra clever reuse is not a goal; eliminating the need for that sort of thing is.

Nobody is importing or reusing or sharing parts of Helm charts, they're all snowflakes that are 90% templating boilerplate following some common patterns but implemented in slightly different ways. That's part of what we're trying to address.

• The unit of sharing is the published Acorn for an app. You can compose an app out of other acorns. e.g. if your app needs a database, your app can deploy and consume the mariadb acorn. If in production want that database to be backed by RDS, you can override the entire binding to point the rest of your app to that instead of deploying mariadb.
• There are mechanisms to provide reasonable defaults so that a user can run that app without combing through an endless values.yaml
• And standardized mechanisms to bind in overrides without defining the minutiae of every possible k8s parameter as 1300 lines of 100+ inputs.
• Chart authors have to do that because the underlying system is arbitrary string templating that hopefully produces YAML at the end. Helm doesn't know anything about what e.g. a volume is or where one is defined or used in the chart. Each chart author either decides for you (and you can't override it), or they make up a dozen variables to control every aspect the volume (but there's no standardization to those variables).
• Acorn knows what a volume is, where they're used in the Acornfile. So the app author can just declare the list of volumes it needs with 0 configuration or templating or input params, and there is a first-class mechanism for the user to configure that volume if they need to.