Better dev setup

[mmlb]

QoL additions

Nix for its wonderful packaging/better reproducibility.
Go based tools are tracked via go modules using tools.go setup.
A makefile because its just nice and easy and well known.
I'm using tinkerbell/lint-install because it integrates with Makefiles well and like the way it configures the tools it uses.
Replaces non-functional TravisCI with GitHub Actions.

And then just a bunch of formatting/lint fixes.

[thaJeztah]

All the new dependencies seem to be introduced because of the tools.go file. Would it be possible to move the tools.go to a submodule, so that it's dependencies do not end up in the main module's dependency?

Something like;

mkdir tools
mv tools.go tools/
go mod tidy

cd tools/
go mod init tools
go mod tidy

[mmlb]

@thaJeztah Is that actually a problem though? Having just the one module is easier to work with and it doesn't really have much of an effect on projects importing go-zfs, these deps only show up in go.sum.

[08:47:05]-[~/t/go-zfs-mod-tests]─[manny@zennix]> 
cat main.go go.mod
───────┬──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
       │ File: main.go
───────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
   1   │ package main
   2   │ 
   3   │ import (
   4   │     "fmt"
   5   │ 
   6   │     zfs "github.com/mistifyio/go-zfs/v3"
   7   │ )
   8   │ 
   9   │ func main() {
  10   │     datasets, err := zfs.Datasets("")
  11   │     if err != nil {
  12   │         panic(err)
  13   │     }
  14   │ 
  15   │     for _, ds := range datasets {
  16   │         fmt.Println(ds)
  17   │     }
  18   │ }
───────┴──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
───────┬──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
       │ File: go.mod
───────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
   1   │ module go-zfs-mod-tests
   2   │ 
   3   │ go 1.16
   4   │ 
   5   │ require github.com/mistifyio/go-zfs/v3 v3.0.0-20220213223527-e5563ba1dd28
   6   │ 
   7   │ replace github.com/mistifyio/go-zfs/v3 => github.com/mmlb/go-zfs/v3 v3.0.0-20220214015725-e51635b865aa
───────┴──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
                                                                                                                                                                                      
[08:47:07]-[~/t/go-zfs-mod-tests]─[manny@zennix]> 
go mod tidy
                                                                                                                                                                                      
[08:47:09]-[~/t/go-zfs-mod-tests]─[manny@zennix]> 
git grep lint-install go.*
go.sum:github.com/tinkerbell/lint-install v0.0.0-20220113213936-9b6f0db005b0 h1:wArDwmgA90A4klrkNhV7vTZfNiP1Z7O7NWhpOl4bDZ8=
go.sum:github.com/tinkerbell/lint-install v0.0.0-20220113213936-9b6f0db005b0/go.mod h1:0h2KsALaQLNkoVeV+G+HjBWWCnp0COFYhJdRd5WCQPM=
                                                                                                                                                                                      
[--:--:--]-[~/t/go-zfs-mod-tests]─[manny@zennix]> 

With go.sum being a db of sorts I'm not really inclined to split off into 2 modules. Do you have a specific concern?

[thaJeztah]

it doesn't really have much of an effect on projects importing go-zfs

Unfortunately, it does; go modules looks at what's defined in a dependency's go.mod and uses that to resolve what dependencies should be considered (and what version), even if the dependency is not used by the code you consume from the module you depend on 😞. We ran into issues because of that in various projects (e.g. the Cobra CLI-framework having some dependency on a grpc version, now forcing all projects to update their version).

[mmlb]

Ah yeah that makes sense. Will do what you mentioned then.

[mmlb]

Thanks for the feedback @thaJeztah I've updated the PR and split into 2 modules, PTAL.

[thaJeztah]

Thanks for updating! (Sorry for the extra hassle 😓)

I'll try to have a look soon (but quite busy currently, so don't hesitate to ping again 😅); I must add that I don't have much experience with Nix, but will try to see where I strand on that 😂

[mmlb]

You don't have to use nix for anything here. Its mostly just the happy path. No worries, I'll likely merge soonish to keep the momentum going.