Strictly limit default dependencies to stdlib

Question

Strictly limit default dependencies to stdlib

Opened this issue a month ago · 6 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.

#1892

Answer 1 · 2024-05-01T11:56:49.000Z

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.

Answer 2 · 2024-05-04T13:10:42.000Z

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

Answer 3 · 2024-05-04T13:24:07.000Z

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

Answer 4 · 2024-05-04T13:39:29.000Z

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

Answer 5 · 2024-05-05T00:38:50.000Z

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

Answer 6 · 2024-05-05T01:29:52.000Z

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