(v0.15.0) Drop dep support

[markbates]

I would like the community's input on this issue.

Currently dep doesn’t support semantic import paths, i.e. github.com/gobuffalo/plush/v3 (unless you use a physical sub-folder). So if we want to add modules support to v2+ projects like plush, pop, tags, etc… we would have to drop support dep across the entire product line or use physical sub-folders.

I'm not a fan of the physical sub-folder idea, and prefer the branch based approached to modules, i.e. a branch named /v3, /v4, etc... as laid out at https://github.com/golang/go/wiki/Modules#releasing-modules-v2-or-higher.

Modules, for better or worse, are going to be the path forward for package management. So the question I'm presenting to the community is:

Do we add modules support to /v2+ projects and drop support for dep? Or do we not add module support to those projects until dep can support it?

I am for dropping support for dep across the gobuffalo repos as it is currently the source of a lot of code branches and it is not going to be the preferred package management system going forward.

This would be a major breaking change.

Dep support will eventually be dropped. It’s a matter of when. My current time frame to drop this support would be v0.15, so anywhere from 3-4 months from now.

[pbnj]

If it’s a matter of when Dep will be dropped, then what’s the value of holding out until Dep supports Semantic Import Versioning?

[markbates]

It’s not about holding out until it does. It’s more a matter of doing it sooner or later. We’re trying to gauge how much of the community is for/against dropping dep as well as whether or not we should wait until modules is more fleshed out. This is just a proposal. I want to drop support sooner, but I want community input to determine timeframe. And should the community come yelling saying don’t drop it, we can discuss that too.

…

On Jan 20, 2019, 1:16 PM -0500, Peter Benjamin ***@***.***>, wrote: If it’s a matter of when Dep will be dropped, then what’s the value of holding out until Dep supports Semantic Import Versioning? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[dnnrly]

I don't suppose you know how many people are using dep? Might help inform the decision, just not sure where you'd get the figures from. A related question would be how many users are on Go 1.11 or later.

For my part though, I haven't used dep since modules was released and can't imagine going back.

[markbates]

These are all good questions I’m hoping to get answers for.

…

On Jan 20, 2019, 3:06 PM -0500, Pascal Dennerly ***@***.***>, wrote: I don't suppose you know how many people are using dep? Might help inform the decision, just not sure where you'd get the figures from. A related question would be how many users are on Go 1.11 or later. For my part though, I haven't used dep since modules was released and can't imagine going back. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[markbates]

Also, 1.9.7 is module aware, so this wouldn’t break non-modules Go users. Just dep users.

…

On Jan 20, 2019, 3:06 PM -0500, Pascal Dennerly ***@***.***>, wrote: I don't suppose you know how many people are using dep? Might help inform the decision, just not sure where you'd get the figures from. A related question would be how many users are on Go 1.11 or later. For my part though, I haven't used dep since modules was released and can't imagine going back. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[theckman]

Not sure if this helps but I was just given push permissions to the dep repo, and will try to work on getting golang/dep#1963 (minimal module awareness) in ASAP.

I think you know my opinion on modules, so I'll refrain from raising them again. 😄

[markbates]

@theckman thanks, please keep us updated.

[pbnj]

@markbates - what's the feasibility of supporting Go Modules by default and keeping the flag option --with-dep for users who want to continue using Dep moving forward?

[markbates]

We already do that, the problems are that it’s a completely different way of work, and it causes a lot of code branch to manage dep in all the places we have to deal with management of those things. Generating new projects, building projects, resources, etc... those code branches are a source of a lot of bugs, and maintenance. I’m not proposing people can’t use dep, but they would just have to deal with it manually, Buffalo would no longer manage those things automatically, like we do today. Removing dep support is just as much about cleaner, simpler code on the buffalo side, as it saying modules are the built in package management solution in Go, so we can work with those natively vs a third party package management solution. If we keep supporting dep, it wouldn’t be unreasonable for people to want support for another 3rd party tool. Removing native dep support doesn’t stop people from still using dep. nor does it stop us from finding a way to let people plug in their own package management solution, perhaps through a config or something else. I’m not opposed to that at all.

…

----------- Mark Bates

On Jan 23, 2019, 3:44 PM -0500, Peter Benjamin ***@***.***>, wrote: @markbates - what's the feasibility of supporting Go Modules by default and having the flag option --with-dep for users who want to continue using Dep moving forward? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[jeremychase]

@markbates Dropping dep support for Buffalo needs to happen at some point but the module system is still immature in the general Go ecosystem. As a case in point my project relies on go-swagger to parse Buffalo source for automated api documentation. Unfortunately, go-swagger still has some difficulty parsing Go code that uses modules.

I have a feeling that this is just one of many issues people will encounter in the transition from dep to modules.

[markbates]

@jeremychase there are a lot of those problems that need to be addressed. Again, the time frame for this is, probably, at least 6 months away. I'm just trying to get it out there, figure out where those pains are, etc...

This is all super awesome feedback.

[abergmeier]

I think you should look at how many problems are still standing once 1.12 comes out. Am all for adopting https://godoc.org/golang.org/x/tools/go/packages and making Module support happening ASAP.