You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Nov 18, 2021. It is now read-only.
Splitting out a separate issue for the rename of get go to import go from #621 (comment)
Other points to consider:
whether cue import go should adopt go test-like behaviour of making progress where it can. For example, if you run cue import go ./... and one package in the set that is matched by ./... fails to type check, then we should generate definitions for those packages that do type check rather than failing the entire process
cue get go has a --local flag. In a world of modules this flag is, I think, redundant. Because if you were to run cue import go on a main module package, it would be strange for it to be placed within the cue.mod/ hierarchy. It only makes sense for such definitions to be generated alongside the Go code from which they were generated
cue import go should run with GOFLAGS=-mod=readonly to enforce that all dependencies are available
Fix the redundant walking of target package directories for .cue files (happens as part of the walk of the directories containing CompiledGoFiles)
Fix the fact that generated code should be placed in the cue.mod/gen hierarchy, not the cue.mod/pkg as it is today
The text was updated successfully, but these errors were encountered:
Splitting out a separate issue for the rename of
get go
toimport go
from #621 (comment)Other points to consider:
cue import go
should adoptgo test
-like behaviour of making progress where it can. For example, if you runcue import go ./...
and one package in the set that is matched by./...
fails to type check, then we should generate definitions for those packages that do type check rather than failing the entire processcue get go
has a--local
flag. In a world of modules this flag is, I think, redundant. Because if you were to runcue import go
on a main module package, it would be strange for it to be placed within thecue.mod/
hierarchy. It only makes sense for such definitions to be generated alongside the Go code from which they were generatedcue import go
should run withGOFLAGS=-mod=readonly
to enforce that all dependencies are available.cue
files (happens as part of the walk of the directories containingCompiledGoFiles
)cue.mod/gen
hierarchy, not thecue.mod/pkg
as it is todayThe text was updated successfully, but these errors were encountered: