Evaluate Cue as an additional configuration/data language

[bep]

See:

• https://github.com/cuelang/cue/blob/master/doc/tutorial/basics/Readme.md
• https://www.youtube.com/watch?v=b3fhA12KS48

I have looked at this briefly before, but when it popped up in my Twitter stream today, I spent some time watching the above video and testing it out -- and I'm really impressed.

This is not about replacing TOML etc., but having proper schema/type validation will obviously help there, as well.

Cue is written in Go and embeds nicely, and would be a great fit for Hugo. It's another Google project, and I predict its success to do something with the YAML madness of Kubernetes etc. -- so there will (if not already) be VS Code highlighters, completion etc.

Note that this isn't something that I plan on doing "today", but I highly recommend to browse the docs above.

/cc @regisphilibert and gang

[regisphilibert]

This looks promising. I watched the video and followed the tutorial and it seems it could work as _content.cue for #6310 (Fields Comprehension)

[bep]

There is also this playground:

https://blog.myitcv.io/gopherjs_examples_sites/cueplayground/

[stale]

This issue has been automatically marked as stale because it has not had recent activity. The resources of the Hugo team are limited, and so we are asking for your help.
If this is a bug and you can still reproduce this error on the master branch, please reply with all of the information you have about it in order to keep the issue open.
If this is a feature request, and you feel that it is still relevant and valuable, please tell us why.
This issue will automatically be closed in the near future if no further activity occurs. Thank you for all your contributions.

[marshall007]

@bep @regisphilibert I think this would be of immense value. We have a ton of use cases where we maintain a normalized representation of data because its easier for folks to work with, but a lot of preprocessing/denormalization is required to combine those data files into something useful for rendering.

You can do all of that in partials with return statements, but Go templates are just not very expressive for this task and even relatively simple operations are a nightmare.

I threw together the following example based on the discography example from the Hugo docs.

Playground: https://cuelang.org/play/?id=GAKmcXEsttt#cue@export@yaml

This is not only much easier to write, but also makes it possible to create and leverage your own helper utilities for processing data. I'm frankly blown away with what you can do just with the standard library.

import (
    "list"
    "strings"
    "strconv"
    "text/template"
)


// would presumably be injected as a global
// consider `#site.Data` here a reference to `site.Data`
#site: Data: {
    artists: {
        jacopastorius: {
            name: "Jaco Pastorius",
            discography: [
              "1974 - Modern American Music … Period! The Criteria Sessions",
              "1974 - Jaco",
              "1976 - Jaco Pastorius",
              "1981 - Word of Mouth",
              "1981 - The Birthday Concert (released in 1995)",
              "1982 - Twins I & II (released in 1999)",
              "1983 - Invitation",
              "1986 - Broadway Blues (released in 1998)",
              "1986 - Honestly Solo Live (released in 1990)",
              "1986 - Live In Italy (released in 1991)",
              "1986 - Heavy'n Jazz (released in 1992)",
              "1991 - Live In New York City, Volumes 1-7.",
              "1999 - Rare Collection (compilation)",
              "2003 - Punk Jazz: The Jaco Pastorius Anthology (compilation)",
              "2007 - The Essential Jaco Pastorius (compilation)",
            ]
        }
    }
}

let #description = """
{{ .name }} released his first album in {{ .career.start }}
and his most recent in {{ .career.end }}.
"""

// this is what we are exporting
artists: {
    for key, Artist in #site.Data.artists {
        let _data = {
            name: Artist.name,
            albums: [
                for i, A in Artist.discography {
                    let parts = strings.Split(A, " - "),
                  
                    year: strconv.Atoi(parts[0]),
                    title: parts[1],
                }
            ],
            career: {
                let _years = [for i, A in albums {A.year}],
                
                start: list.Min(_years),
                end: list.Max(_years)
            }
        }
        
        (key): _data & {
            description: template.Execute(#description, _data)
        }
    }
}

YAML Output

artists:
  jacopastorius:
    name: Jaco Pastorius
    albums:
      - year: 1974
        title: Modern American Music … Period! The Criteria Sessions
      - year: 1974
        title: Jaco
      - year: 1976
        title: Jaco Pastorius
      - year: 1981
        title: Word of Mouth
      - year: 1981
        title: The Birthday Concert (released in 1995)
      - year: 1982
        title: Twins I & II (released in 1999)
      - year: 1983
        title: Invitation
      - year: 1986
        title: Broadway Blues (released in 1998)
      - year: 1986
        title: Honestly Solo Live (released in 1990)
      - year: 1986
        title: Live In Italy (released in 1991)
      - year: 1986
        title: Heavy'n Jazz (released in 1992)
      - year: 1991
        title: Live In New York City, Volumes 1-7.
      - year: 1999
        title: Rare Collection (compilation)
      - year: 2003
        title: 'Punk Jazz: The Jaco Pastorius Anthology (compilation)'
      - year: 2007
        title: The Essential Jaco Pastorius (compilation)
    description: |-
      Jaco Pastorius released his first album in 1974
      and his most recent in 2007.
    career:
      start: 1974
      end: 2007

I didn't even touch on validation, which is also an incredible value add for projects that maintain large data sets.

CUE even supports generating OpenAPI schema definitions, which would be very useful for API documentation projects: https://pkg.go.dev/cuelang.org/go/encoding/openapi.

[marshall007]

I think a good proof of concept would be to evaluate all *.cue files in the data directory as if they were files of any other supported format. The only difference is that they would be evaluated with some global context object that at minimum contains site .Params and .Data.

I'm out next week but I will try to take a stab at this after I get back.

[regisphilibert]

but Go templates are just not very expressive for this task and even relatively simple operations are a nightmare.

That is a subjective statement :) I'm more fluent in Go Template than Go, and I suspect it's the case of many Hugo users. Even though I must admit building complex data with Go Template might not be as straight forward as in Go, it would still be a learning curve for me and many users.

That being said, I'm all for this feature, as we need more some sort of dynamic way to pass configuration settings, and I'll be willing to learn whatever language is used here. But if it's easier to allow config file to point to returning partials, I'll be happy as well.

[davidsneighbour]

--All-- many of the links above lead to dead pages. The project itself has been "archived by the owner". Just saying.

[marshall007]

@davidsneighbour the CUE project was just moved to a different organization. It is very much alive and well:

https://github.com/cue-lang/cue
https://cuelang.org/
https://cuetorials.com/

[davidsneighbour]

Ah, I could have checked that :)