cmd/cue: get go panics #668
Comments
|
Welcome to the CUE project, @nwidger! You have, unfortunately, hit a bit of a rough edge. And there is some history associated with The short version however is:
Which brings us on to the specifics of your case. As you are the author of this module, I will assume you actually want to provide CUE definitions alongside your Go code, so read on. If you truly intended to work with your module as a dependency, per your example above, see the heading "Using Providing CUE definitions alongside your Go codeAs you are the author of this module, you probably want to have the CUE definitions exist alongside your Go code. In which case you want to do something slightly different to the steps about (we should improve the docs here). For the record I'm using Looking at your project: The first thing to say is that your module is not tidy: I'd suggest that for release versions it should be, otherwise users of your module will find "extra" dependencies added to their For what follows, I've run The next thing to note is that not all of your packages compile: This might well not be a problem in practice, but I point it out because it's a factor that is contributing to the behaviour you are seeing. Moving on to Notice however we still get a panic. That's because of a bug described in #621 which means that error messages encountered by The invalid package in this case is the So what needs to be done here:
We are addressing the first of these two points for the next release because a number of people are being caught by this bug. We might also include a fix for the second point. In the interim, you can run With the first of those two bugs fixed, there is actually yet another bug that your example trips over that I'm still in the process of debugging. This error will also be fixed as part of the next release. So unfortunately for now I can't even provide you with a work around. Using
|
|
@myitcv Thank you so much for the very detailed reply! I feel a little sheepish as while I'm grateful for your very helpful reply, to be honest I never had any real intention to use CUE with my That being said, thank you for pointing out the issues in my package. That package is basically "done" as it has essentially served it's purpose (getting data out of an old issue tracker and into a new one) and hasn't been worked on in a number of years. It seems the It looks like CUE still panics even with the Anyway, I'm happy to try running any other experiments or to try out any fixes that might eventually surface. Just please know that I'm only playing around and not trying to get any real work done with CUE. :) |
Very kind of you to raise this issue. A fix for #621 is going to land shortly, but we are going to leave solving this issue until a later commit. Reason being, we need to slightly rework the way in which Go standard library packages are handled by The bug you are ultimately running into here is that With a fix for #648 we can address this trivially. |
'cue get go' loads interface types from cmd/cue/cmd/interfaces during initialisation. Go types that satisfy these interface types are then used as special cases for the target CUE definition types - see the complete logic in (*extractor).altType. Given the nature of 'cue get go', it is assumed that the command is run in the context of a Go module. That is to say, 'go env GOMOD' will be non-empty. (It doesn't seem worth adding GOPATH support given that modules will be GA in Go 1.16) Currently, 'cue get go' assumes that the package cuelang.org/go/cmd/cue/cmd/interfaces will be available. That is to say, either cuelang.org/go is the main module or, more likely, that cuelang.org/go is a module dependency of the main module. However, this is an unnecessary restriction and one that is potentially incorrect. After all, the user is using a specific version of cmd/cue - loading a different version of cuelang.org/go seems likely to lead to version-skew related problems. This change switches cmd/cue to instead load cuelang.org/go/cmd/cue/cmd/interfaces via a simple embedding of the GoFiles in that package. As part of the same change we surface all loading and type checking errors for either the embedded cuelang.org/go/cmd/cue/cmd/interfaces or the arguments to 'cue get go'. With thanks to @verdverm and @NicolasRouquette for the analysis and suggestions that went into this fix. Drops GOPATH support. Fixes #621 Fixes #668 Change-Id: I630e2cb167c05d63186aa356eaf70a58749b61c5
'cue get go' loads interface types from cmd/cue/cmd/interfaces during initialisation. Go types that satisfy these interface types are then used as special cases for the target CUE definition types - see the complete logic in (*extractor).altType. Given the nature of 'cue get go', it is assumed that the command is run in the context of a Go module. That is to say, 'go env GOMOD' will be non-empty. (It doesn't seem worth adding GOPATH support given that modules will be GA in Go 1.16) Currently, 'cue get go' assumes that the package cuelang.org/go/cmd/cue/cmd/interfaces will be available. That is to say, either cuelang.org/go is the main module or, more likely, that cuelang.org/go is a module dependency of the main module. However, this is an unnecessary restriction and one that is potentially incorrect. After all, the user is using a specific version of cmd/cue - loading a different version of cuelang.org/go seems likely to lead to version-skew related problems. This change switches cmd/cue to instead load cuelang.org/go/cmd/cue/cmd/interfaces via a simple embedding of the GoFiles in that package. As part of the same change we surface all loading and type checking errors for either the embedded cuelang.org/go/cmd/cue/cmd/interfaces or the arguments to 'cue get go'. With thanks to @verdverm and @NicolasRouquette for the analysis and suggestions that went into this fix. Drops GOPATH support. Fixes #621 Fixes #668 Change-Id: I630e2cb167c05d63186aa356eaf70a58749b61c5
|
I think I'm seeing the same issue with |
|
Note to self: another good test case here is goreleaser/goreleaser#2065 |
|
I believe I'm seeing the same issue with |
|
This issue has been migrated to cue-lang/cue#668. For more details about CUE's migration to a new home, please see cue-lang/cue#1078. |
What version of CUE are you using (
cue version)?I can also reproduce the issue building from source using
masterat 9c5489f.Does this issue reproduce with the latest release?
Yes
What did you do?
I am a complete CUE newbie. I listened to the recent Go Time podcast about CUE and thought I would try seeing whether
cue getcould generate stubs from one of my own Go packages. I barely know what I'm doing, I've scanned some of the CUE documentation but otherwise have never used CUE before. It might be that I'm doing something wrong, but I figured havingcuepanic with a nil pointer dereference wasn't expected.What did you expect to see?
Successfully generate cue files based on the Go packages in
github.com/nwidger/lighthouse/....What did you see instead?
From what I can tell,
extractPkgget passed anil*packages.Package, perhaps related to thenet/httppackage. Despitecueexploding, I do see that it generates some files:However,
github.com/nwidger/lighthousecontains a number of sub-packages, so it looks likecueblows up before it gets to generating .cue files for them.Please let me know if I can provide any other information!
The text was updated successfully, but these errors were encountered: