dafdc1070b
## Description Ref: https://github.com/cosmos/cosmos-sdk/issues/11917 The noun should be one which conveys the notion of a *core instruction*. Other names for this type I've considered: - Instruction - Behavior - Specification - [Config](https://github.com/cosmos/cosmos-sdk/issues/11917#issuecomment-1135086189) (probably the most straighforward) - Trait --- ### Author Checklist *All items are required. Please add a note to the item if the item is not applicable and please add links to any relevant follow up issues.* I have... - [x] included the correct [type prefix](https://github.com/commitizen/conventional-commit-types/blob/v3.0.0/index.json) in the PR title - [x] added `!` to the type prefix if API or client breaking change - [x] targeted the correct branch (see [PR Targeting](https://github.com/cosmos/cosmos-sdk/blob/main/CONTRIBUTING.md#pr-targeting)) - [x] provided a link to the relevant issue or specification - [x] followed the guidelines for [building modules](https://github.com/cosmos/cosmos-sdk/blob/main/docs/building-modules) - [x] included the necessary unit and integration [tests](https://github.com/cosmos/cosmos-sdk/blob/main/CONTRIBUTING.md#testing) - [x] added a changelog entry to `CHANGELOG.md` - [x] included comments for [documenting Go code](https://blog.golang.org/godoc) - [x] updated the relevant documentation or specification - [x] reviewed "Files changed" and left comments if necessary - [x] confirmed all CI checks have passed ### Reviewers Checklist *All items are required. Please add a note if the item is not applicable and please add your handle next to the items reviewed if you only reviewed selected items.* I have... - [ ] confirmed the correct [type prefix](https://github.com/commitizen/conventional-commit-types/blob/v3.0.0/index.json) in the PR title - [ ] confirmed `!` in the type prefix if API or client breaking change - [ ] confirmed all author checklist items have been addressed - [ ] reviewed state machine logic - [ ] reviewed API design and naming - [ ] reviewed documentation is accurate - [ ] reviewed tests and test coverage - [ ] manually tested (if applicable) |
||
|---|---|---|
| .. | ||
| internal | ||
| testdata | ||
| Makefile | ||
| README.md | ||
| build.go | ||
| config.go | ||
| container.go | ||
| container_test.go | ||
| debug.go | ||
| errors.go | ||
| go.mod | ||
| go.sum | ||
| group.go | ||
| location.go | ||
| module_dep.go | ||
| module_key.go | ||
| one_per_module.go | ||
| provider_desc.go | ||
| provider_desc_test.go | ||
| resolver.go | ||
| simple.go | ||
| struct_args.go | ||
| supply.go | ||
README.md
Cosmos SDK Dependency Injection container Module
Overview
TODO
Usage
TODO
Debugging
Issues with resolving dependencies in the container can be done with logs
and Graphviz renderings of the container tree. By default, whenever there is an error, logs will
be printed to stderr and a rendering of the dependency graph in Graphviz DOT format will be saved to
debug_container.dot.
Here is an example Graphviz rendering of a successful build of a dependency graph:
Rectangles represent functions, ovals represent types, rounded rectangles represent modules and the single hexagon
represents the function which called Build. Black-colored shapes mark functions and types that were called/resolved
without an error. Gray-colored nodes mark functions and types that could have been called/resolved in the container but
were left unused.
Here is an example Graphviz rendering of a dependency graph build which failed:
Graphviz DOT files can be converted into SVG's for viewing in a web browser using the dot command-line tool, ex:
> dot -Tsvg debug_container.dot > debug_container.svg
Many other tools including some IDEs support working with DOT files.