Roger Peppe

According to a [reply to the above-mentioned issue](https://gitlab.com/gitlab-org/container-registry/-/issues/1203#note_1789458417), the fix should be released with GitLab 16.10, due out 2024-03-21.

@ckkcsg Thanks for the report. Here's a self-contained example of how to do what you want. Use the [testscript command](https://pkg.go.dev/github.com/rogpeppe/go-internal/cmd/testscript) to run this example. I'm going to repurpose this issue...

Specific docs suggestions: - better docs for `load.Config` fields: it's not clear that `ModuleRoot` is a directory rather than a module path; it's not clear that overlay paths cannot be...

It looks like this is probably because `cuelang.org/go/cue/load.matchFile` opens the file, reads its imports, then closes it again. It should probably do something different for non-regular files.

With the `-e` flag, is there any way of referencing the top level object currently?

> A number of users of the Go API expect `cue/load.Instances()` to behave like `cmd/cue` does There's a good reason for that. The doc comment for `load.Instances` says: ``` //...

It looks like it might have something to do with test files. When I remove all the `_test.go` files, it doesn't give an error. An easy (but unfortunately large and...

FWIW I just confirmed that the packages don't match. I just added this code under the `*Named` branch of `Checker.identical0`: ``` if x.obj.name == y.obj.name && x.obj.pkg.path == y.obj.pkg.path {...

One other important piece of info: the final line printed is: ``` rf: errors found after script ``` implying that type checking did succeed initially, but failed after making the...

Having said that, when I tried the `ex` on multiple packages, I got a similar error from `rf` before it executed the script, so it's not _just_ to do with...