Proposal: global/module context awareness

[bcomnes]

Having to remember the -m and -m -run flag feels cumbersome for some reason. Would it be possible to infer which mode gobin is running in based on the cwd? (e.g. in a folder tree of a module, infer -m. Outside of a go module project tree, global gobin?

[myitcv]

Apologies for the delay in replying, I had closed Octobox and so was not receiving notifications for this repo.

Thanks for raising this.

However I don't think this is feasible. It's something that, along with @rogpeppe and @mvdan, we mused over during early discussions. Having gobin operate in "global" or "non-module" mode by default felt correct. Having the -m is then the explicit signal to say "operate via the main module".

There are a number of reasons for this, chief among them being that if we did automatically infer the mode then it would be impossible to run "global" commands whilst in the context of a module.

Unless I misunderstand the suggestion?

[bcomnes]

The suggestion stems from finding my own use of gobin always having to set the -m flag. It seems like the flagged behavior is more common than the global behavior. From what I can tell, gobin's most compelling use case is allowing projects to specify versions of development time module bins and their consumption.

The global capabilities are nice, but they seem secondary to the module mode. Being able to install a specific go program at a specific version globally is a nice capability (one that go get I hope supports one day), but I only ever see myself doing that instead of a plain go get -u if the latest version of something doesn't happen to work and I need an older version, and I'm working outside of a go project and just happen to need a go based tool, or the nature of the tool is extremely one-off. If a go project is requiring a dev time command at a specific version, it should be defined in its mod file and run with gobin, probably from some kind of Makefile or other entrypoint.

Another reason to default to module mode is prior art: npm (which go modules has a lot of similarities with now: nested, project-local dependency trees) defaults to local actions over global actions, to discourage projects from adopting un-versioned global devDependencies. Despite any possible negative bias people have of JS/Node, the local over global behavior works very well and has overall been great for the ecosystem.

Possible solutions I see would be to switch from a -m flag for local actions, to a -g for global actions, or perhaps switch on GO111MODULES=auto's status.

[myitcv]

Thanks for the comprehensive reply. I've not forgotten about this issue; just a bit busy with other things right now, so please bear with me.

[bcomnes]

No problem! Sorry, sort of poor taste of me to show up and be like 'here are reasons to change your flags around'. Although a little more cumbersome imo, the current explicite flags work and are simple.

[myitcv]

Sorry, sort of poor taste of me to show up and be like 'here are reasons to change your flags around'

Not at all. It's great to have feedback/experience reports from others. So thank you for contributing.