Strictly limit default dependencies to stdlib

[meatballhat]

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.

• [x] #1892

[bartekpacia]

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.

[meatballhat]

@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 😁

[bartekpacia]

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

[meatballhat]

I also love go.mod files with no dependencies! Please let's keep talking about this 🙇🏼

[dearchap]

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

[meatballhat]

@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.

[hay-kot]

Strolling through v3 issues trying to find a spot to help. Looking at #1971 - looks like this can be closed? Since it was decided it's not worth the effort to vendor/rewrite a testing library the work here is complete.

Anyone opposed?

[asahasrabuddhe]

I agree with @hay-kot. Closing the issue now.