~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
RESOLVED BY_DESIGN
Submitter
~mvdan
Assigned to
No-one
Submitted
4 months ago
Updated
3 months ago
Labels
No labels applied.

~eliasnaur 4 months 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 4 months 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 3 months 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 3 months 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 3 months 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 3 months 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 3 months 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

~myitcv 3 months ago

I added a comment over in https://github.com/golang/go/issues/33468#issuecomment-522449679. FWIW I think gobin has been a relatively successful experiment in convincing me we need such a tool (modulo a couple of tweaks in behaviour) distributed as part of the Go distribution (whether part of cmd/go or not I leave to someone else). Relying on the contents of PATH, having to tell users to set their PATH, things getting stale, etc is such a footgun moment for every user of every tool they ever install, whether globally or as part of a project. Further evidence of this to my mind is that situations that most users find themselves in when using gopls with their editor: just run go get golang.org/x/tools/gopls, and ensure your PATH is correct. Followed by the inevitable instructions that are not cross-platform on how to set your PATH. It's just not the user experience anyone wants or needs. If some users need it as an escape hatch, that seems fine (https://github.com/myitcv/govim/issues/440)

So, as mvdan points out, the only real issue I see with go run X is the link cost you encounter each time. gobin saves that link cost but is still not fully optimised to the point of it being equivalent to a PATH resolution, instead it's equivalent to the cost of a go list call.

That said, I'm sure there are optimisations to be had in gobin (or whatever will replace it).

~eliasnaur REPORTED BY_DESIGN 3 months ago

I'm going to close this as BY_DESIGN because I believe the use of go run is valid despite it being slower.

Register here or Log in to comment, or comment via email.