~eliasnaur/gio#15: 'go run gioui.org/cmd/gio' is probably not a good idea

'go run some/cmd' doesn't cache the linked binary. That is, every time you run that command, a new temporary binary is linked, run, and deleted.

I understand that it's convenient, but I think it's a bit dangerous to encourage users to do that as a general rule. Why not simply say 'go install gioui.org/cmd/gio' at the beginning of the README? If you worry about $PATH, you can always add a short note about it.

Status
REPORTED
Submitter
~mvdan
Assigned to
No-one
Submitted
13 days ago
Updated
10 days ago
Labels
No labels applied.

~eliasnaur 12 days ago

Thanks, I agree that go run is slow, so I filed https://github.com/golang/go/issues/33468 for that. That issue also contains my reasoning behind listing go run instead of go install in the README.

~mvdan 12 days ago

Sorry, I forgot to link https://github.com/golang/go/issues/25416. I think 'go run' is only meant for sporadic use, not for continuous use.

~eliasnaur 10 days ago

I argue in https://github.com/golang/go/issues/33518#issuecomment-519045868 that just because of reproducibility, go run is be the correct choice for the gio tool.

I also argue that inside a module, go run is (or could be) as fast as running a installed binary.

What do you think?

~theclapp 10 days ago

just because of reproducibility, go run is be the correct choice for the gio tool

I think this is only true for you, or more generally for Gio developers (people working on Gio as opposed to people using Gio to build a gui app). I think Gio users will generally have a stable Gio environment and using go run, however fast it is, will be the wrong choice, compared to go build or go install.

I disagree with the reproducibility part (or don't understand it). go run seems like the opposite of the reproducible case. Unless you're modifying the cmd/gio/*.go code itself, how would go run of the gio tool be any better than go install or go build? The gio tool just runs go build, which seems like it would need to be the reproducible part? And then if you want it to be reproducible then shouldn't it not rebuild every time? Yeah, I think I'm missing something.

At the end of the day, on my system running an already built cmd/gio takes ~0.28s, and go run of cmd/gio takes ~0.65s, which is over twice as much time, true, but come on, it's still sub-second. I don't really think it's an issue worth optimizing.

FWIW, I disagree with most of your reasons (in https://github.com/golang/go/issues/33468) that go run is better. * It is more convenient, I'll grant you that. * Random Go developers are gonna know about $GOBIN, and if you don't want to pollute it, use go build. * Agree with bcmills that experienced Go users can easily translate a go install command to a go run command too * Binary always up to date -- this applies mostly to you (or Gio devs) and not Gio users. * Avoids binary name clashes -- Yeah, I suppose. I think that's on you, though. Rename it to gio_build or giob or something.

On the other hand, it's not something I feel that strongly about. By all means, use go run if that works best for you. I don't think it's that dangerous to mention go run in a README, which you want to be short and sweet and as painless as possible for new users. I think it'd be fair to bring up that in general if you're going to be using a command a lot you should install it and have done.

~theclapp 10 days ago

My formatting got a little hosed. (A preview/edit/delete function would be nice.) I'll try again; if this doesn't work, I'll stop.

  • It is more convenient, I'll grant you that.
  • Random Go developers are gonna know about $GOBIN, and if you don't want to pollute it, use go build.
  • Agree with bcmills that experienced Go users can easily translate a go install command to a go run command too
  • Binary always up to date -- this applies mostly to you (or Gio devs) and not Gio users.
  • Avoids binary name clashes -- Yeah, I suppose. I think that's on you, though. Rename it to gio_build or giob or something.

~mvdan 10 days ago

I don't feel strongly about this. The point of this issue was bringing to your attention that 'go run' has some disadvantages of its own, so it's a tradeoff.

In case you didn't know, Paul wrote https://github.com/myitcv/gobin, which among other things, caches binaries.

~eliasnaur 10 days ago

On Wed, Aug 7, 2019 at 4:20 PM ~theclapp outgoing@sr.ht wrote:

just because of reproducibility, go run is be the correct choice for the gio tool

I disagree with the reproducibility part (or don't understand it). go run seems like the opposite of the reproducible case. Unless you're modifying the cmd/gio/*.go code itself, how would go run of the gio tool be any better than go install or go build? The gio tool just runs go build, which seems like it would need to be the reproducible part? And then if you want it to be reproducible then shouldn't it not rebuild every time? Yeah, I think I'm missing something.

go run inside a module actually records the version of the program it runs in the current module's go.mod. I used to think this was an annoying feature, but it makes sense from a reproducibility perspective: as a developer of a mobile app, I want other people building my app to use exactly the same version of the gio tool as I did, just as I want them to use the exact same version of dependencies.

A good example of where this matters is

https://git.sr.ht/~eliasnaur/gio/commit/1c5ceab9c1d2a1cfa706f54128ecc6e89eed9561

a change which made a backward incompatible change to the gio tool.

Let's say you go install gioui.org/cmd/gio after that change and use the tool to build a webassembly version of a program that hasn't upgraded its gioui.org/ui version in its go.mod. The older gioui.org/ui/app package is not prepared to deal with the missing

element, and the program fails to run.

  • elias