search

bazelbuild / rules_go

Go rules for Bazel
Apache License 2.0
1.37k stars 650 forks source link

nogo: idiomatic way to provide configuration file #1867

Open justinsb opened 5 years ago

justinsb commented 5 years ago

I'm playing with using nogo to write a simple spell checker. However, I'm trying to provide a custom per-project dictionary as a file, and I can't figure out how to pass it. My analyzer executes in a sandbox, so I can't just naively walk the directory tree. I can't figure out how to pass a data parameter to nogo, particularly because I want to scope it to one analyzer (that will eventually live in a different repo).

What is the right way to do this?

jayconrod commented 5 years ago

cc @stjj89

I haven't tried to do this, but I think the right API for this data attribute on the go_tool_library rule. go_tool_library does have a data attribute, but I'm not sure we're making those files visible when nogo runs. Have you tried it? Is it not visible in the sandbox, e.g., with filepath.Walk?

If data files are not visible, it's probably a bug we should fix.

justinsb commented 5 years ago

Thanks! I agree that should data should work for a file in the same project (and I can try it out to be sure), but the issue is that I want to put my spell-checker in a shared "tools" repo, and then the custom dictionary lives in each project (and in each project I have a reference to the tools repo). I think there's no way for go_tool_library rule to reference the custom.dict in the consuming project? I guess I could require the consuming projects to create a rule that binds the go_tool_project to their custom_dict?

jayconrod commented 5 years ago

Ah, ok. We don't really have a facility for doing that now.

golang.org/x/tools/go/analysis, on which nogo is based, lets Analyzers define a Flags. That would probably be the right place to tell the analyzer where its configuration file is. nogo doesn't currently do anything with that, but we should probably expose an args attribute on the nogo rule which would allow flags to be set, and a data attribute that would make configuration files available (you'd be able to get their location with $(location //:file) in args).