-
-
Notifications
You must be signed in to change notification settings - Fork 579
Feature: Be able to set the root module/package name at app creation #1329
Comments
I'll add that I didn't actually personally come across this problem using the above steps. I had a project using |
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.
|
Thanks for a superbly quick response! That makes sense. I guess there are two points that can be addressed separately.
|
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.
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.
|
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. |
@markbates is this one covered already ? |
Yep. There’s a flag in 0.14 |
Steps to Reproduce the Problem
GO111MODULE=on buffalo new mytest
(outside ofGOPATH/src
)mytest/go.mod
starts with the linemodule mytest
go get github.com/username/mytest
(again, outside ofGOPATH/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
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 validgo.mod
), you will get:b) If
go get
is run from outside a module,go get
will return: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.
The text was updated successfully, but these errors were encountered: