go mod tidy
go run main.go
go get cuelang.org/go@v0.11.0
go mod tidy
go run main.go
-- main.go --
package main
import (
"fmt"
"cuelang.org/go/cue/load"
)
func main() {
insts := load.Instances([]string{"."}, &load.Config{
Dir: "myproject.cue",
})
fmt.Println(insts[0].Err)
}
-- go.mod --
module test
require cuelang.org/go v0.7.0
-- cue.mod/module.cue --
module: "foo.test/main"
language: version: "v0.9.0"
-- myproject.cue/main.cue --
package main
hello: "world"
The output of this is as follows:
> go mod tidy
> go run main.go
[stdout]
<nil>
> go get cuelang.org/go@v0.11.0
> go mod tidy
> go run main.go
[stdout]
read $WORK/myproject.cue: is a directory
It seems like the new CUE_EXPERIMENT=modules mode in cue/load regressed in this scenario. I think the new code is buggy; there is no particular reason why we shouldn't support CUE packages in directories named whatever.cue. And in fact, such modules and directories already exist out in the wild, such as https://github.com/tmm1/taxes.cue, which is how I found this regression. Some people like calling their projects after the language, and some of those use dots as a separator.
The output of this is as follows:
It seems like the new
CUE_EXPERIMENT=modules
mode in cue/load regressed in this scenario. I think the new code is buggy; there is no particular reason why we shouldn't support CUE packages in directories namedwhatever.cue
. And in fact, such modules and directories already exist out in the wild, such as https://github.com/tmm1/taxes.cue, which is how I found this regression. Some people like calling their projects after the language, and some of those use dots as a separator.