Feature: Be able to set the root module/package name at app creation

[aidansteele]

Steps to Reproduce the Problem

• Use v0.13.0-beta.2
• Run GO111MODULE=on buffalo new mytest (outside of GOPATH/src)
• Observe that mytest/go.mod starts with the line module mytest
• Push this project to github.com/username/mytest
• Run go get github.com/username/mytest (again, outside of GOPATH/src)

Expected Behavior

A newly generated Buffalo project with module support would be go gettable. This would necessitate changing line 81 of the following code:

buffalo/meta/app.go

Lines 79 to 83 in e56fdc3

	if modsOn {
	if !strings.HasPrefix(pwd, filepath.Join(envy.GoPath(), "src")) {
	pp = name.String()
	}
	}

This assumes the module name is the name of the directory/buffalo app.

Actual Behavior

a) If go get is run from inside a module (i.e. inside a directory that has a valid go.mod), you will get:

go: github.com/username/mytest@v0.0.0-20180927111533-e1d3d2568b3b: parsing go.mod: unexpected module path "mytest"

b) If go get is run from outside a module, go get will return:

package mytest/actions: unrecognized import path "mytest/actions" (import path does not begin with hostname)

Additional

Thank you so much for such a wonderful piece of software. Buffalo is the number one reason why I use Golang, it's truly great.

[aidansteele]

I'll add that I didn't actually personally come across this problem using the above steps. I had a project using dep and Buffalo v0.12.6. I changed to modules and used a fully qualified module name. This would fail to compile because the buffalo_build_main.go file generated by buffalo build would assume that my app's import path was just mytest - rather than the full URL. This caused the build to fail.

[markbates]

If it’s outside the GOPATH we don’t have a way of knowing where you’re going to push the app, ie github, GitLab, etc... that’s why outside of the GOPATH you get just a name. Inside the GOPATH you should get a fully qualified package path. I’m open for PRs on this, but I couldn’t think of a way to do that outside the GOPATH. The fix is to change the module name. Thanks.

…

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

On Sep 27, 2018, 7:31 AM -0400, Aidan Steele ***@***.***>, wrote: I'll add that I didn't actually personally come across this problem using the above steps. I had a project using dep and Buffalo v0.12.6. I changed to modules and used a fully qualified module name. This would fail to compile because the buffalo_build_main.go file generated by buffalo build would assume that my app's import path was just mytest - rather than the full URL. This caused the build to fail. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[aidansteele]

^{Thanks for a superbly quick response!}

That makes sense. I guess there are two points that can be addressed separately.

buffalo new

As you said, there's no way to know where the app will be pushed. There are two ways we could approach this.

a) We could add an additional flag, e.g. buffalo new myapp --module github.com/username/myapp

b) The restriction name argument in buffalo new [name] could be relaxed from matching [a-Z0-9-_] to allowing a fully qualified module name. This could be the user's way of indicating that they're making a module.

buffalo build

Right now the name is determined like this:

buffalo/meta/app.go

Lines 79 to 83 in e56fdc3

	if modsOn {
	if !strings.HasPrefix(pwd, filepath.Join(envy.GoPath(), "src")) {
	pp = name.String()
	}
	}

We could instead first look for the presence of a go.mod file in the working directory and read the module name from there.

I'd be happy to make a PR (or PRs) for any of the above approaches, or adjust them according to your input.

[markbates]

I was thinking a flag to change the mod name is the easiet, and probably cleanest solution. Keep it falling back to what it is now, but if someone passes the flag, use that. I would love a PR. :) Thanks.

…

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

On Sep 27, 2018, 7:54 AM -0400, Aidan Steele ***@***.***>, wrote: Thanks for a superbly quick response! That makes sense. I guess there are two points that can be addressed separately. buffalo new As you said, there's no way to know where the app will be pushed. There are two ways we could approach this. a) We could add an additional flag, e.g. buffalo new myapp --module github.com/username/myapp b) The restriction name argument in buffalo new [name] could be relaxed from matching [a-Z0-9-_] to allowing a fully qualified module name. This could be the user's way of indicating that they're making a module. buffalo build Right now the name is determined like this: https://github.com/gobuffalo/buffalo/blob/e56fdc3d27814d2009f003885ea7169e1628da55/meta/app.go#L79-L83 We could instead first look for the presence of a go.mod file in the working directory and read the module name from there. I'd be happy to make a PR (or PRs) for any of the above approaches, or adjust them according to your input. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[rxx]

I was stuck with some strange issues with go modules, so I switched back to dep. After upgrade from buffalo 0.13-beta1 to stable 0.13 it can't find some modules. buffalo upgradex fails also. With dep everythings looks just ok

[paganotoni]

@markbates is this one covered already ?

[markbates]

Yep. There’s a flag in 0.14