Users who need to use gokr-packer to migrate an existing setup to the
instance-centric config can use the following command to install the
last version before it was deleted:
go install github.com/gokrazy/tools/cmd/gokr-packer@703a8605028963d13a9d00815ccedfae13f0ce6d
fixes https://github.com/gokrazy/gokrazy/issues/301
This interfaces with spf13/cobra without typing ourselves to its types, and
exerting control (for better of for worse) about what aspects one can control.
With this, we can move the code in cmd to internal/
Adding the require line using `go get` does not work for
https://github.com/evcc-io/evcc as of commit
504ed7172efdd6e849985280a21feccbbf455b9d:
panic: internal error: can't find reason for requirement on
github.com/rogpeppe/go-internal@v1.6.1.
It is cleaner to have this happen outside of the gok tool.
That way, users can see the config, as the tool will read it,
using `cat config.json` before calling gok.
related to https://github.com/golang/go/issues/53804
When validation fails, the error message looks like this:
2022/09/17 20:53:07 /tmp/gokrazy-bins-1604202262/dhcp4d is not an ELF binary!
bad magic number '[0 0 0 0]' in record at byte 0x0
Before
Before this commit, gokr-packer was building all Go binaries to include in the
gokrazy root file system from the same working directory, meaning the same
go.mod and go.sum files were used for all packages.
This wasn’t really an intentional choice, instead it was the easiest way to get
things working when Go switched from GOPATH to modules.
The downside of that approach is that updates in one package can result in other
packages no longer building. In the most extreme cases, it can mean that two
packages cannot be built into the same gokrazy root file system at all.
After
With this commit, gokr-packer will build each package in a subdirectory of the
new builddir/ directory in your gokrazy instance directory,
e.g. ~/gokrazy/scan2drive/builddir.
If there is no go.mod file in the builddir yet, gokr-packer will copy the
top-level go.mod/go.sum files into the builddir to keep your current module
selection, and hopefully build exactly the same binary as before.
Influencing the granularity
Often, one Go package will be the only package you use from a certain Go
module. But this isn’t always the case: for example, the system packages
github.com/gokrazy/gokrazy/cmd/dhcp and github.com/gokrazy/gokrazy/cmd/ntp both
come from the github.com/gokrazy/gokrazy module.
gokr-packer will by default create a separate builddir, including a separate
go.mod and go.sum, for each package, even when they come from the same module.
If you want to add module-wide replace directives to your go.mod file,
you can influence the granularity at which gokr-packer works as follows.
Move the go.mod/go.sum files to the directory level within the builddir/
hierarchy at which you would like to work. gokr-packer will look for
go.mod/go.sum files at the package level, going one level up until it finds the
files.
Hence, you can use the following locations, ordered from finest to coarsest
granularity:
1. per-package builddir (default), e.g.:
builddir/github.com/gokrazy/gokrazy/cmd/dhcp/go.mod
2. per-module builddir (convenient when working with replace directives), e.g.:
builddir/github.com/gokrazy/gokrazy/go.mod
3. per-org builddir (convenient for wide-reaching replace directives), e.g.:
builddir/github.com/gokrazy/go.mod
4. single builddir, preserving the previous behavior, e.g.:
builddir/go.mod
related to https://github.com/gokrazy/tools/issues/38
