Giters

cep21 / circuit

An efficient and feature complete Hystrix like Go implementation of the circuit breaker pattern.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Circuit module requires competing libraries for benchmark

benjigoldberg opened this issue · comments

commented

Hi @cep21 -- thank you for building this awesome library!

I was hoping we could restructure the v3 module to have the benchmark -- and its dependencies -- in a different module.

This is important, because it means that downstream applications end up with every one of the competing libraries in our go.sum:

$ go mod graph

...
github.com/cep21/circuit/v3@v3.1.0 github.com/afex/hystrix-go@v0.0.0-20180502004556-fa1af6a1f4f5
github.com/cep21/circuit/v3@v3.1.0 github.com/iand/circuit@v0.0.0-20171204111915-2e03e581ff44
github.com/cep21/circuit/v3@v3.1.0 github.com/rubyist/circuitbreaker@v2.2.1+incompatible
github.com/cep21/circuit/v3@v3.1.0 github.com/sony/gobreaker@v0.4.1
...

It would also be nice if other modules, such as gopher-js, were optional.

commented

It would also be nice if other modules, such as gopher-js, were optional

The circuit library itself has no dependencies: only the tests and benchmarks.

This is important, because it means that downstream applications end up with every one of the competing libraries in our go.sum

This is a common complaint with go modules. You will see this for unit tests: for example unit test dependencies will appear in the go.sum. The go team doesn't see this as a real concern.

The go team draws a distinction between the dependencies listed in the go.mod and the ones listed in the go.sum. Generally, there's no priority to shrink the size of go.sum in any way since it won't

  • Get compiled into the final library
  • Won't cause other libraries to fail to compile due to the semver promise.

One side affect of all this is that you can run your dependencies tests and benchmarks, to validate date for yourself. This is part of the -all flag for go test. This would be more difficult if test and benchmark dependencies were a different module.

When I last experimented with making benchmarks their own module it became difficult to ensure benchmark code was run against the currently checked out cep21/circuit code. Maybe if you submit a pull request I can look at it and verify things look and run ok, but the general consensus for Go and modules is

  • go.sum will grow and there's nothing you can do about it
  • Having many go.mod files in a single git repository will sometimes lead to surprising behavior.
commented

Thanks for the response @cep21 that was very educational for me. I appreciate you taking the time to explain this 👍

commented

@benjigoldberg I'll also add I don't totally agree with the Go team about this and hate that it makes the modules "appear" ugly, adding test and benchmark dependencies in the "production" code part. Similar to how you saw. Their main retort is that it shouldn't matter since none of the code is actually compiled into the resultant binary.