wire
wire copied to clipboard
google
wire: make wire package publicly import-able
Other static analysis tools might want to get access to the Wire provider graph for visualization, navigation, etc. The package is currently internal so that the API can be iterated on quickly, but once it's baked, it would be good to allow others to use it.
What about moving Wire to its own repo so that it can be used (both as a package and as a command) with projects other than Go Cloud? Separate FR?
Wire can already be used independently of any other parts of Go Cloud (see #230 where a similar request was made). This issue is purely about making wire/internal/wire (the Wire code generator and analysis) accessible to tooling.
Sg. #230 seems to address the library use case.
re: the command use case, go get github.com/google/go-cloud/wire/cmd/wire still pulls in all of go-cloud.
#273 would cover both.
go get github.com/google/go-cloud/wire/cmd/wire will download all of Go Cloud's source, but it will not pull in all of its dependencies, which is order of magnitudes larger.
(continuing discussion from #59).
I'm not sure I'm convinced that this is a good idea. It exposes a much wider API surface for wire with no clear use case.
I can imagine wanting to add things like .dot visualization (#42), etc. -- but can't we accept those as feature requests/contributions for wire itself?
We could. I'm just imagining a long tail of feature requests for different aspects of the data, and think it would be better for Wire to export the data in a useful format rather than trying to build and maintain all of possible uses of it.
I hear you, but IMHO it's premature to try to expose a "useful format" without knowing what the use cases are or how the data will be used. We can start with a small API surface (basically, just the command line); if a long tail of feature requests comes along, we can always add a new way to expose internals later. It might be a public import for the library, or it might be a .csv output from the command line, or ...?
IMHO we should remove this API surface before Beta; we can always add it later if there is demand.
@zombiezen @shantuo
Why? It's in an internal directory. Removing it would cause code and test restructuring for little gain AFAICT
Ah, you are right -- this bug is about changing it so that the API is public, not the other way around. Removing from Beta....