Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Strictly limit default dependencies to stdlib #1890

Open
1 task done
Tracked by #833
meatballhat opened this issue Apr 28, 2024 · 6 comments
Open
1 task done
Tracked by #833

Strictly limit default dependencies to stdlib #1890

meatballhat opened this issue Apr 28, 2024 · 6 comments
Labels
area/v3 relates to / is being considered for v3
Milestone

Comments

@meatballhat
Copy link
Member

meatballhat commented Apr 28, 2024

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.

@meatballhat meatballhat changed the title strictly limit default dependencies to stdlib 1 Strictly limit default dependencies to stdlib Apr 28, 2024
@meatballhat meatballhat added this to the Release 3.x milestone Apr 28, 2024
@meatballhat meatballhat added the area/v3 relates to / is being considered for v3 label Apr 28, 2024
@bartekpacia
Copy link
Contributor

bartekpacia commented May 1, 2024

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
Copy link
Member Author

@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
Copy link
Contributor

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
Copy link
Member Author

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

@dearchap
Copy link
Contributor

dearchap commented May 5, 2024

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
Copy link
Member Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/v3 relates to / is being considered for v3
Projects
None yet
Development

No branches or pull requests

3 participants