New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
x/tools/go/packages: add support for new package overlays #29047
Comments
Thanks for opening the issue :) For those wanting a link to the CL above, it's https://golang.org/cl/151999. The current CL currently extends For example, I'd like to be able to add some Go files to directories that have a special non-Go file. So if I do But of course that would hard-code I know that's perhaps asking for too much, but I want to clarify that the current approach won't quite cut it for some use cases :) |
I have thought about this use case. The trouble with the callback based overlays is it does not work with an external driver. If you look at the work that Marwan did on a caching version of the go list driver, there is no way to have that separate process cope with a function based overlay in a way that is even slightly efficient, which is why we chose a pure data model that can be handed across a process boundary. For the moment, you can call Load twice, once in Files mode, and then again in Syntax mode with the constructed overlay. |
Thanks for the reply - that indeed does work OK when it comes to adding or changing Go files within existing Go packages. But as far as I know, that can't be used to construct new Go packages easily. For example, suppose my special file per package is called I also just realised that it's not possible to list non-package directories with |
Also, I do realise that my talking of "Go packages" as "directories" is quite particular to |
@mvdan I'm not sure that go list will be able list non-package directories, so I don't know if this sort of thing will be supported first-class. So solving your problem might require traversing all the relevant directories to find the .bar files and constructing an overlay based on that. I know that's not satisfying, but I don't see a way around it. To make things worse: as you mentioned, it's not clear how we'd make something like this work with alternate build systems |
Thanks - I agree this is an awkward use case :) Manually traversing directories can be a tricky solution though, as it essentially means I need to reimplement It's completely fair if this is out of the scope of So I should really be filing an issue against |
I suspect such an issue would be denied on the assumption that it is the go tools job to deal with go code, so returning information about directories that have no go code is out of scope. |
I suspect such an issue would be declined too, which is part of the reason why I'm approaching it from the perspective of overlays creating new packages :) We are indeed forcing users to add Perhaps the solution would be a Go library similar to the older https://github.com/kisielk/gotool, but where you'd be able to configure things such as whether a directory should be a package or not. That would still require me to copy some code from |
Creating the doc.go is easy enough to write a small tool for, it does not need to be a manual step, just build a doc.go for any directory that has a .bar file and no .go files before doing any list queries. |
Correct. We're hacking our way around these problems with overlays, so I'm moderately happy with the situation. If I come up with a specific proposal for go/packages to improve our use case, I'll file a separate issue. |
Several other programming languages solve this by having a specific file that can list the files that belong to a package. We already have |
Closing this issue because new packages overlays are supported and support for overlays will be on a solid foundation with Go 1.16. |
As of cl/151999 we support adding new files in the overlay.
It would be nice if we could use this for the very first file in a package as well, for which go list is going to fundamentally fail.
The text was updated successfully, but these errors were encountered: