Another scenario,
There is a package x which requires a bin package Y,
if the bin package is installed as global, a per package dependency
reference breaks,
so the bin file needs to exists into a package/vendor/bin which co exists
with GOPATH/bin
having the path modified to ./vendor/bin does sound error prone.
A bin util, which would do something similar to your idea
`goexec bin args...` might be smart enough to sort things out
and call for the right binary in the right path,
it is also able to provide detailed information when something wrong happen.
More than that, if a collision happen,
it allows to add precision about the bin to execute until the collision is
solved,
something like
`goexec user/bin args...`
`goexec gh.com/user/bin args...`
And to make it awesome, auto completion support would be just awesome! imho.
On Thursday, March 30, 2017 at 11:28:28 AM UTC+2, Paul Jolly wrote:
>
> I've searched golang-nuts and the Go issue tracker pretty extensively and
> I can't find any mention of my question or the topic, so would appreciate
> any links if this has been previously covered and I was simply using the
> wrong search terms.
>
> go install takes a number of packages as arguments:
>
> $ go install -help
> usage: install [build flags] [packages]
>
>
> Let's assume for the sake of discussion we're talking about:
>
> go install github.com/fruit/banana
>
>
> (where banana is a main package)
>
> In writing documentation, particularly when it comes to code generators
> (but not exclusive to that), I find myself repeatedly asking the user to
> "ensure your path is correct..." so that when they now run:
>
> banana -help
>
>
> it invokes the banana binary we just installed.
>
> This is relatively painful and error prone because of any permutation of
> problems/inconsistencies with PATH values, not to mention the potential for
> clashes in names of installed Go programs within $GOPATH/bin/
>
> One way to deal with this is to do something like:
>
> $(go list -f {{.Target}} github.com/fruit/banana) arg1 arg2 ...
>
>
> but:
>
> 1. I'm unsure how cross-platform this is
> 2. it's not particularly pretty/friendly
> 3. it doesn't work with go:generate directives
> 4. it doesn't solve the problem of name clashes in $GOPATH/bin
>
> What about therefore making go run (which currently only takes .go files
> as arguments to the go command) also understand the case of a single
> package argument:
>
> go run github.com/fruit/banana arg1 arg2 ...
>
>
> Arguments that are then passed on to the command as before (here arg1 arg2
> ... are passed on to banana)
>
> This would not build/install anything, it would simply exec the program
> most recently built via 'go install github.com/fruit/banana', or fail if
> not such file exists.
>
> There are of course other details to work through... just looking to test
> the water with the thought.
>
> Appreciate any links/feedback etc, particularly if actually others
> consider that I'm perceiving an issue where in fact there isn't one (i.e. I
> needn't even both writing about getting PATH correct in docs) and that name
> clashes are not common.
>
> But it would seem to be a nice way of further lowering the bar for new
> starters with the language, work cross-platform and not require any further
> environment tweaking.
>
> Thanks,
>
>
> Paul
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
