Export as single file

[maurerbot]

Is your feature request related to a problem? Please describe.
When organizing cue in several packages and evaluating with the cli (eval, def, etc) it would be helpful if you could provide a flag to bake out all the dependent definitions/values in the output.

Describe the solution you'd like
Let's say you have a cue project organized like this

cue.mod/
core/
  core.cue
v1/
  v1.cue
v2/
  v2.cue

//core.cue
package core

#gendef {
  prop1: string
}

// v1.cue
package v1

import "mypackage.com/core"

#v1thing: core.#gendef & {
  prop1: "v1"
  prop2: number
}

// v2.cue
package v2

import "mypackage.com/core"

#v2thing: core.#gendef & {
  prop1: "v1"
  prop2: string
}

And you evaluate v1/ with cue def ./v1 you will get exactly what is shown in the v1.cue example. With a flag it would nice to get..

// new flag option output cue
#gendef {
  prop1: string
}

#v1thing:  #gendef & {
  prop1: "v1"
  prop2: number
}

Describe alternatives you've considered
I've considered exporting the core and implementations out separately and using the -I flag to show search for the imports. This is awkward and hasn't been successful when setting the ImportPath option using the go package.

Additional Context
For our project we have tools that split into the standard "client" and "server" as well as we are starting to have api versioning.

Inheriting some shared definitions for "fail fast" client validations and deeper server side side validations is the goal

[verdverm]

How would this work if two imports have values with the same label?

import "foo.bar/a"
import "foo.bar/b"

#GeneralThing: a.#Thing | b.#Thing

github.com/rogpeppe/go-internal/txtar can be used to package multiple files into a single file, when for example you'd like to send CUE across the wire

[maurerbot]

With disjunctions I imagine the individual shapes would be inflated to their evaluated structs?

[verdverm]

What if these are simple references themselves to other imports? How far does this unwinding happen? Is the result semantically equivalent to the original in all cases?

I suspect this is fraught with edge cases and likely truly difficult to get right if not impossible.

What are the use cases? Are there viable alternative solutions?

[maurerbot]

The problem I'm suffering from is I have a cue project structured similar to the one above where I export or "build" several versions of our definitions to a new location outside a cue module (an xdg location) that a cli tool references.

The CLI can't compile cue.Values from these exports.

[verdverm]

Can you make the xdg content a directory with the CUE files / mods you need?

[maurerbot]

yes, however the context to be that dir? I would have to cwd there every time I needed to bootstrap the cuecontext

This also isn't ideal because we materialize the cue definitions from IPFS into memory and the cuecontext can't resolve any imports some of those other files may contain (which may be externally contributed [think CRDs])

[verdverm]

You should be able to use the load.Config object to control some of this.

https://pkg.go.dev/cuelang.org/[email protected]/cue/load#Config

You might be able to use the Overlay, can't recall if there are issues with mods in that case. Once Go 1.17 is out, work could potentially be done to change Overlay to the new fs.FS. See #607 for more info

[maurerbot]

this could work. when I get back to this task I'll report back

[myitcv]

@maurerbot can you provide some more details on what problem you are trying to solve here?

As @verdverm points out above, if we did implement something like this, it would need to retain some sort of namespacing to avoid conflicts:

package v1

core: #gendef {
  prop1: string
}

#v1thing: core.#gendef & {
  prop1: "v1"
  prop2: number
}

But in any case it sounds like there's a different underlying problem here. If you don't make any progress with cue/load please reply back.

Unmarking as a feature request until we get more clarity on the problem.

[myitcv]

Actually, I will also make this a discussion. We can always create specific issues off the back of any conclusions we draw.