Something like:
go get -tool github.com/golangci/golangci-lint/cmd/golangci-lint@v1.64.4
And then you can list tools : go list -f '{{.Tool}}' all
ANd run them: go tool staticcheck ./...21–30 of 71 posts
Something like:
go get -tool github.com/golangci/golangci-lint/cmd/golangci-lint@v1.64.4
And then you can list tools : go list -f '{{.Tool}}' all
ANd run them: go tool staticcheck ./...pixi init && pixi add wget
And youre ready to go, everything confined to the venv within the directory
Five years ago, I would've loved this. I love the simplicity and power of good old Make. And I obsess over my workstation's configuration. I used to have a massive bash script I would use to reprovision my workstation after every clean upgrade of Ubuntu. But these days, I just tell codex to install things for me. I basically use it as a universal package manager. It's more reliable honestly than trying to keep up to…
I feel like even iPad kids are more capable with a computer than HN users these days.
Configuration is in scheme (guile) so that may be a turn off though.
With tooling for deployment I prefer to heed an adaptation of Greenspun's Tenth Rule. Neither Guix nor Nix are really all that "complex" from a user's perspective.
If you haven’t tried it, I highly recommend Mise. It manages everything at the user level so it’s not as “all encompassing” as Nix and is readily compatible with immutable distros. https://mise.jdx.dev/ Your solution is akin to putting your dotfiles in the code repo, which is going to cause issues with languages with poor version compatibility (such as node and python) when switching between old projects. Also, bold…