search

bashup / .devkit

Portable project automation and dependency bootstrapping for polyglot projects
MIT License
23 stars 2 forks source link

Implement local go support (as `dk use: go`) #2

Closed pjeby closed 5 years ago

pjeby commented 7 years ago

It should be possible to use update-golang to do a local installation via github udhos/update-golang master update-golang.sh and then running RELEASE=$desired-version DESTINATION=$BASHER_PREFIX PROFILED=/dev/null update-golang.sh. (Possibly w/some addtional vars to unset, i.e. SOURCE, ARCH, OS, CACHE and any GO* vars.)

Probably the best way to do that is to wrap update-golang in a subshell function with an argument parser that exports all the vars; then you could get-go -s url -d dir --cache blah or some such. Probably if there's an existing GOARCH and GOOS, those should map to ARCH and OS. The .envrc will also need to set GOPATH and GOBIN.

Once all that's done it should be possible to just require foo go get foo for a lot of tools, such as modd, yaml2json, dnscontrol, etc.

pjeby commented 5 years ago

Since gimme is more flexible and more actively maintained, it should probably be used instead of update-golang. The go module could export gimme as a function that did require gimme github travis-ci/gimme 1.5.3 gimme, and then run command gimme "$@".

There probably needs to be some further consideration of things like whether to override the home cache for go compilers or not. On the one hand, it makes things fast and cheap; on the other, it's a global change by a project you're building. (Maybe the solution is to set the variables if they're not already set and a ~/.gimme directory doesn't already exist.)

OTOH, variables like GIMME_ARCH, GIMME_OS should all be unset by default, because we don't want the build environment to be corrupted by host settings... which also implies the installation should always be local to the project. (And the GIMME_TYPE should be binary, etc.)