December 1st, 2019: Buffalo no longer supports GOPATH. Go Modules are now required.

[markbates]

At the beginning of the year I opened proposal #1545 to drop support for dep, I believe the best course of action since then is to only support Go Modules.

In order to support modules, non-modules, dep and other 3rd party package management tools, there is an ever growing set of branching logic to be found across all of the Buffalo eco-system. This leads to bugs, maintenance issues, etc...

One of the biggest problems that has been unleashed on the Go community is "Semantic Import Versioning". This requires that packages that are v2+ have that as part of their import path. So, for example, Plush should be imported as github.com/gobuffalo/plush/v3 if it were using modules, but it isn't.

Currently none of the Buffalo packages that are at v2+ or higher are currently unable to add module support as it is currently nearly impossible to support modules, non-modules, and dep at the same because of this semantic import versioning.

Since Go Modules are what we, as a community, will be using the more we move forward, I propose we stop fighting the good fight to support everyone and require that GO111MODULE=on be used for all of the Buffalo packages.

I believe the timing for this should be done after Go 1.13 is released, so probably in the fall of 2019.

This won't be without pain, unfortunately though, we are currently in a lot of pain, trapped in a world between all of these different ways of managing packages. At some point a decision needs to be made, and I think, unfortunately, this maybe the only sane path going forward.

This is a proposal, and as such, I welcome community input on this difficult topic.

[dankinder]

I think it's a great thing that you guys have tried hard so far to be backward-compatible with deprecated dependency tools and want to be sensitive to that 👍But for several reasons I think it does make sense to support only modules:

• Staying compatible is painful, as noted by @markbates -- this is true even for users like myself, the documentation is confusing in some places because the go tool semantics are a bit different with modules, plus the bugs that come up from the current complexity
• Converting a project to modules from anything else is very easy
• Unlike a typical libraries, the method of specifying dependencies makes a huge difference for buffalo
• Buffalo is not even V1 yet, so people should not be shocked at such a change

Perhaps this can be done in such a way that the buffalo binary pre-modules-required still works?

[markbates]

https://blog.gobuffalo.io/the-road-to-1-0-requiring-modules-5672c6b015e5