Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/go: proposal add project config to go.mod #42343

Open
distinctdan opened this issue Nov 2, 2020 · 9 comments
Open

cmd/go: proposal add project config to go.mod #42343

distinctdan opened this issue Nov 2, 2020 · 9 comments
Labels
Projects
Milestone

Comments

@distinctdan
Copy link

@distinctdan distinctdan commented Nov 2, 2020

The way things are today, go relies on environment variables for things like build architecture and os, as well as resolving private repos. This isn't good because they live outside of source control, so the build breaks when someone else clones the repo and tries to run go get or go build.

Instead, what about making these settings live in go.mod, similar to how node has a package.json? It might look like

env (
    GOOS linux
    GOPRIVATE github.com/myOrganization
)

My goal is to ensure it builds the same way every time for everyone that clones the repo, without them having to do any manual environment config.

@gopherbot gopherbot added this to the Proposal milestone Nov 2, 2020
@gopherbot gopherbot added the Proposal label Nov 2, 2020
@bcmills
Copy link
Member

@bcmills bcmills commented Nov 2, 2020

See previously #39005 (CC @dominikh @mvdan @jayconrod @matloob)

@bcmills
Copy link
Member

@bcmills bcmills commented Nov 2, 2020

See also #33985.

@mvdan
Copy link
Member

@mvdan mvdan commented Nov 2, 2020

Note that #39005 was not about altering the default build behavior, though. It was simply about listing the "build configurations" which are well supported by a module. This distinction makes me worry about this proposal.

@distinctdan
Copy link
Author

@distinctdan distinctdan commented Nov 2, 2020

Hmm, I hadn't considered different build configs. That is definitely a useful feature though. For security, I'm not experienced enough with Go to know all the options, but I'm thinking of just setting build options, not necessarily going as far as allowing shell scripts. Perhaps something like, where you have different available configs for the build:

buildConfig (
    default (
        Output myApp
        GOOS linux
        GOPRIVATE github.com/myOrganization
    )
    windows (
        Output myApp.exe
        GOOS windows
        // Inherits GOPRIVATE value from default
    )
)
@mvdan
Copy link
Member

@mvdan mvdan commented Nov 2, 2020

I'm still not convinced that a "default" makes sense. It would be very confusing for go build on Linux to produce a Windows binary, or to produce a binary in an unexpected directory, for example.

I think we should design the semantics (what do we want to list, and for what purpose?) before we worry about what file it would go under or with what syntax. The semantics is why #39005 was retracted, after all - it opened up the go tool to executing arbitrary code, and overall the idea gained no traction.

@distinctdan
Copy link
Author

@distinctdan distinctdan commented Nov 3, 2020

So I'm thinking that the build config section would be optional. Any values omitted would use the current behavior, so if an organization was running locally and had a mix of windows and linux machines, they could still omit the GOOS variable so that it would use the OS's default. My particular use case is we've got a small app that's being deployed to aws lambda, so it always needs to build for linux, and my org uses several private repos, so when I first tried to build the project, I got a bunch of errors and had to do a bunch of googling to figure out how to get it to work.

Coming from a web background, the npm and webpack ecosystems offer a lot more tooling. It's normal to have a default task that builds and runs in dev mode, often with hot code reloading, then you've got a task that builds in release mode. It's expected that things just work out of the box and that each module you import is self contained. Coming from that, it just seems strange to have to make global environment changes to get a local project to build, or to have to pass a bunch of flags every time. I've worked around this in the meantime by putting all my flags in a shell script that calls go build, but this seems like a pretty common use case, so I think it'd be nice if Go natively supported it.

@bcmills
Copy link
Member

@bcmills bcmills commented Nov 3, 2020

As an alternative, note that you could at least reduce the number of environment variables from many to just one, by setting the GOENV environment variable to point to a location within your repo.

@pickfire
Copy link

@pickfire pickfire commented Nov 6, 2020

As an alternative, note that you could at least reduce the number of environment variables from many to just one, by setting the GOENV environment variable to point to a location within your repo.

Setting environment variable is not user friendly, it cannot be checked into the repo (it can through a file) and requires an extra step for new developers (new clone) to get started.

For example, one requires to source env.sh first before go build. Comparing to rust, one can just cargo build with the options in Cargo.toml.

@networkimprov
Copy link

@networkimprov networkimprov commented Nov 6, 2020

I build app releases for Linux, Windows, and MacOS. Each release includes a platform specific tree of files beside the executable, and is packed into a TGZ or ZIP file. I built a shell script to do this, tho I could have used a makefile. I've essentially duplicated the script in multiple projects.

If there's a Go-native way to do this, I overlooked it.

@ianlancetaylor ianlancetaylor added this to Incoming in Proposals Nov 11, 2020
@rsc rsc changed the title Proposal: Project config should live in go.mod instead of relying on env variables cmd/go: proposal add project config to go.mod Nov 18, 2020
@rsc rsc moved this from Incoming to Active in Proposals Nov 18, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants
You can’t perform that action at this time.