Strictly limit default dependencies to stdlib
meatballhat opened this issue · comments
The runtime dependencies for core library usage should be strictly limited to the Go standard library ("stdlib"). This does not apply to the test dependencies.
I very much applaud this issue. I love when modules come with no dependencies:)
BTW, does this also apply to testify?
Here's an interesting blogpost I read some time ago – The Cult of Go Test.
@bartekpacia Yay I'm glad you like! I generally agree with that blog post!
As for testify, I think I'm ambivalent. Since Go treats testing dependencies as a separate group, we're protected from leaking such dependencies into production builds. I have not rigorously tested these assumptions 😬.
All of this being said, I'm not interested in introducing any more testing dependencies right now, nor do I see cases where the testify/suite capabilities would be significantly better than table-driven tests. Sticking to testify/assert and `testify/require' is my preference right now 👍🏼
WDYT? I'm happy to talk more about the tradeoffs 😁
Since there's more important work to do, and this doesn't affect any of our users, but only our codebase, I think it's OK to not act upon it at all right now.
I'd prefer to use pure Go test instead of testify/assert and testify/require, but then it's my small preference vs your preference, so no good reason for any change :P
I just love go.mod files with no dependencies :P
I also love go.mod files with no dependencies! Please let's keep talking about this 🙇🏼
Whats the problem. I dont see any direct dependencies at all. The indirect dependencies are all because of docs generation. I'm fine with what we have
@dearchap Yes, I think we're already at the point where the only build-time and runtime dependencies are from the Go standard library 👍🏼.
There are a few dependencies that will become part of the go.mod resolution because they are used in tests and examples, and the test dependency on github.com/stretchr/testify. I think that the value of eliminating these remaining go.mod resolution-time and test-specific dependencies is significantly lower than eliminating build dependencies, but there's still potential value there.