Open kylebaron opened 2 years ago
I think we'll need to update cmd/pkgr/goreleaser.yml
to include arm64
or use macOS universal binaries (sounds like the second approach pretty much doubles the binary size):
(edit: go 1.16 is required too, I think, but a new enough go version will already come in with drone's pull of goreleaser/goreleaser:latest
)
Thanks, @kyleam ; that's helpful.
unfortunately, I am not certain that will be the fix you're hoping for. Eg you could already run pkgr "fine" under emulation (though there is no reason not to kick out an ARM binary. Plenty of stuff does - RStudio runs as x86, so does quarto (as underlying deno doesn't have a native arm build).
The bigger issue(s) will be two fold:
@dpastoor
The bigger issue(s) [...]
Ah, thanks for providing the broader, more relevant answer.
I didn't / couldn't follow the technical details on this. Is it possible to somehow use pkgr on m1 right now? Or would that require arm65 build?
For binary package question: is that something we can kick down the road and just work with source (we do it that way on Metworx anyway) or does something need to be solved on that front before we can go there?
Wondering about this as we're at a bit of a roadblock right now and looking for a way through.
KTB
As I understand it, which may be wrong:
Is it possible to somehow use pkgr on m1 right now?
Yes, you can do it through Rosetta.
is that something we can kick down the road and just work with source (we do it that way on Metworx anyway)
Yes, you can build from source, though you run into the pain of needing to have the system requirements installed. (For Linux, they're not bundled, as they are for macOS and Windows, so using binaries speeds things up, but it doesn't free you from needing the system reqs.)
Will the macos binaries run on macbook with M1 chip? If not, is there a way to get it installed on this arch?