search

uber-go / fx

A dependency injection based application framework for Go.
https://uber-go.github.io/fx/
MIT License
5.68k stars 287 forks source link

Logging needs to understand dig.Out #540

Closed HelloGrayson closed 7 years ago

HelloGrayson commented 7 years ago

When Fx's output encounters a dig.Out, it should print a log line for each dependency being provided in the dig.Out.

So instead of:

[Fx] PROVIDE        zapfx.Result <= vendor/code.uber.internal/go/zapfx.git.module()

It should contain:

[Fx] PROVIDE        zap.AtomicLevel <= vendor/code.uber.internal/go/zapfx.git.module()
[Fx] PROVIDE        *zap.Logger <= vendor/code.uber.internal/go/zapfx.git.module()
[Fx] PROVIDE        *zap.SugaredLogger <= vendor/code.uber.internal/go/zapfx.git.module()
glibsm commented 7 years ago

Definitely. Shouldn't be hard to do, there are examples of that in the dig repo, such as traverseOutTypes

Do we want to explode one per line, or keep things combined:

[Fx] PROVIDE        zap.AtomicLevel, *zap.Logger, *zap.SugaredLogger <= vendor/code.uber.internal/go/zapfx.git.module()
HelloGrayson commented 7 years ago

Exploded - log lines should be line-oriented, and I want people to be able to easily scan down the column to explore what types are available.

glibsm commented 7 years ago

In order to properly implement this fxlog packages needs to know what is and what isn't In/Out objects. It's fairly trivial to duplicate that logic, but I don't think that's the best approach in the long term.

I think the right thing to do is to export the currently private isInObject and isOutObject dig functions: https://github.com/uber-go/dig/blob/master/types.go#L69

HelloGrayson commented 7 years ago

Suggest just calling it IsOut and IsIn

HelloGrayson commented 7 years ago

Resolved in #126