Forced errors dependency

[gorilla]

Forced errors dependency

[elithrar]

There are no plans to remove it. I’m curious as to why it’s a problem: it is a lightweight dependency, and no different from importing gorilla/securecookie.

…

On Sat, Aug 12, 2017 at 6:33 AM gopherfortress ***@***.***> wrote: Hello, I noticed that gorilla/csrf is using github.com/pkg/errors which while I believe it is an excellent package, it forces an unnecessary dependency on projects that want to use gorilla/csrf without pkg/errors. Are there any plans to remove this dependency? Thanks — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#69>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABIcCStW1yfEWqOblcchi4fTPG3t6gfks5sXamWgaJpZM4O1akS> .

[gopherfortress]

Hey thanks for replying. It's not so much a problem per se but as I said before, it forces projects (or libraries) that want to use gorilla/csrf to bring along an extra dependency, lightweight or not. I call it "extra" because it is not fundamental to gorilla/csrf as is gorilla/securecookie.

If we assume a project that depends on 10 small and good packages like gorilla/csrf and each of them brings along a extra lightweight dependency then the project now has 20+ dependencies out of the blue.

I believe It is a good practice to keep libraries as self contained and lean as possible especially one as important to the ecosystem as gorilla/csrf.

[elithrar]

Sure, but conversely, using a well-known and highly-used ( http://godoc.org/github.com/pkg/errors?importers) package that simplifies error handling makes sense to me. Eschewing dependencies for the sake of having "less" dependencies doesn't make a heap of sense. Remove dependencies when they pose a risk (maintenance burden, security, bloat) to your project, not because they are a dependency themselves.

…

On Sat, Aug 12, 2017 at 8:45 AM gopherfortress ***@***.***> wrote: Hey thanks for replying. It's not so much a problem per se but as I said before, it forces projects (or libraries) that want to use gorilla/csrf to bring along an extra dependency, lightweight or not. I call it "extra" because it is not fundamental to gorilla/csrf as is gorilla/securecookie. If we assume a project that depends on 10 small and good packages like gorilla/csrf and each of them brings along a extra lightweight dependency then the project now has 20+ dependencies out of the blue. I believe It is a good practice to keep libraries as self contained and lean as possible especially one as important to the ecosystem <https://godoc.org/github.com/gorilla/csrf?importers> as gorilla/csrf. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#69 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABIcIGwx7cWiqqbwf5qIaKsitYXPdcuks5sXciggaJpZM4O1akS> .

[gopherfortress]

There is no doubt that pkg/errors is an awesome package and pretty convenient but gorilla/csrf can easily do without it. It can't do without gorilla/securecookie though. That's the key difference.

I believe that If we do not try to minimize our dependencies we might eventually end up other like other language ecosystems where it is the norm for each library to bring along sneaky small dependencies and the end project accumulating dozens, or even hundreds of dependencies. Some codebases can go as far as to copy small dependencies to keep the dependency tree at a minimum. Or to reference the Go proverb: "A little copying is better than a little dependency." This practice is even more important for libraries that can be imported by other libraries before they end up in a project.

Anyways, you made it clear that there are no plans to remove the dependency and it seems we have a different philosophy on the subject so I believe there is nothing else to discuss. Thanks for listening.