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

proposal: cmd/go: provide a portable and simple way to run SDK-like Go tools #33518

Open
eliasnaur opened this issue Aug 7, 2019 · 4 comments

Comments

@eliasnaur
Copy link
Contributor

commented Aug 7, 2019

The Gio library contains a module (gioui.org/ui) for creating GUI programs in Go. For desktop platforms, running a Gio program is as easy as any other Go program, provided you have a few common system libraries and a C compiler installed:

$ go run gioui.org/apps/hello

Running Gio programs on Android, iOS and in the browser requires packaging several support files and meta data, so the Gio project includes the gio tool in the `gioui.org/cmd module to automate the tedious work.

Note that the gio tool is not general purpose: it is intrinsically bound to the giou.org/ui module. Similar examples are the gobind and gomobile tools from the Gomobile project.

This issue is about providing an easy and portable way to run such support tools.

In #33468 I described a possible solution in terms of go run because go run is very close to what I want. This is the simple and portable one-liner for creating an Android app for a Gio program:

$ go run gioui.org/cmd/gio -target android gioui.org/apps/gophers

Unfortunately, according to #33468 (comment), #25416 and #25416 (comment), it is almost accidental that go run can run the above one-liner.

go install

@bcmills brings up the usual way to use Go tools: go install and setting up $PATH to run them:

You could give separate instructions for cmd.exe and for Unix-like shells. Or assume that they have their PATH configured appropriately (perhaps by reference to some other document) and tell everyone:

go install gioui.org/cmd/gio
gio -target android gioui.org/apps/gophers

However, setting up PATH is not portable and not nearly as simple as go run, in particular for Windows users.

Case in point: go env can now set environment variables for the Go tool because (#30411)

Setting environment variables for go command configuration
is too difficult and system-specific.

go build

#25416 (comment) suggests

$ go build -o /some/dir/gio gioui.org/cmd/gio
$ /some/dir/gio ...

which doesn't depend on the environment, but still more awkward than just go run.

(Some) Solutions

  • Let go run be the way to conveniently run Go commands without fiddling with the environment. #33468 is about speeding up go run so that it is (nearly) as fast as running a go install'ed binary. go run is also the only way to get reproducible builds; see #33518 (comment).
  • Set up the user's environment when installing Go so that go install'ed programs are guaranteed to be in PATH.
  • As a variant to the above, provide a portable and simple way to run a go install'ed binary that doesn't depend on the environment.
@eliasnaur

This comment has been minimized.

Copy link
Contributor Author

commented Aug 7, 2019

In #33468 (comment), @bcmills brings up an interesting point:

When working within a module in module mode, go run should produce a reproducible result, not always upgrade to the latest version.

I agree that within a module the result should be reproducible which is the reason go run records the version of the command in a current module's go.mod.

However, that means that within a module, go running gio is superior to running a previously go install'ed version, just because the tool version is reproducible with go run, but not with the binary that happens to be in GOBIN.

So go install is not always the correct choice, even if we assume PATH is correctly set up.

@mvdan

This comment has been minimized.

Copy link
Member

commented Aug 7, 2019

As a variant to the above, provide a portable and simple way to run a go install'ed binary that doesn't depend on the environment.

It is possible to get the path to the installed binary in a portable way, with something like:

go list -f {{.Target}} some/main/pkg

Note that this will still resolve the version and do extra work outside a module, so it's not instantaneous.

@eliasnaur

This comment has been minimized.

Copy link
Contributor Author

commented Aug 7, 2019

It is possible to get the path to the installed binary in a portable way, with something like:

go list -f {{.Target}} some/main/pkg

Note that this will still resolve the version and do extra work outside a module, so it's not instantaneous.

Thank you. My current thinking is that the speed of go run outside a module is not that important; most actual uses will be from inside a module.

@andybons andybons changed the title cmd/go: provide a portable and simple way to run SDK-like Go tools proposal: cmd/go: provide a portable and simple way to run SDK-like Go tools Aug 12, 2019

@gopherbot gopherbot added this to the Proposal milestone Aug 12, 2019

@gopherbot gopherbot added the Proposal label Aug 12, 2019

@dmitshur dmitshur added the GoCommand label Aug 13, 2019

@tv42

This comment has been minimized.

Copy link

commented Aug 13, 2019

Unfortunately, according to #33468 (comment), #25416 and #25416 (comment), it is almost accidental that go run can run the above one-liner.

It seems like your use cases for running this tool would always be within a module, though -- it's only relevant when developing programs using your giou.org/ui module. And for that, go run (or go build blah && ./blah, for caching the executable) seem just right.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.