What's the 2024 state of the art for local macOS+arm64 development nonsense?
Without spending TOO much time combing my (halfhearted because I've been developing via headless Linux since 2020 & it's actually very nice) notes, the last I recall hearing is:
Homebrew still "is what it is” & its entire world has since been updated for arm64?
Actual-Docker works now, but still via a (Virtualization.framework? emulating Intel??) Linux VM?
@Elucidating is this because the docker client and/or server components just generally run like shit, or because it requires running a VM in the background?
Eg, if one were to use say Colima + containerd, is that better on the battery, or nah?
@bitprophet@Elucidating Docker still runs in a VM, but it keeps getting a better virtualisation framework every couple years, so runs much better now.
Also, ARM64 support in Linux got much better, so you can actually compile a lot more stuff natively, or if you're lucky even get precompiled binaries in packages!
That said, emulation of AMD64 via Rosetta 2 does work, but it's really slow, so to be avoided as much as possible, but useful to be able to quickly check if an image works.
@daaain@Elucidating thanks! can you expound a bit on the 'better virtualisation frameworks over time' angle? I thought the native Virtualization.framework (or w/e it's called) was the only serious game in town, with other options still using the same low level guts and having a more experimental UI, as well)
@bitprophet@Elucidating yes, I meant actually using the latest Apple provided Virtualization.framework rather than earlier Hypervisor / HyperKit, VirtualBox, etc. But also, VirtioFS which mostly solved file system woes.
Honestly, having Docker and a container running doing nothing doesn't really add any extra CPU load. Of course you still wouldn't want to run stuff like LLMs in Docker because you can't benefit from Metal, but for a web server and a database it's perfectly fine.
@Elucidating@bitprophet I was talking about power draw when idle as most of the stuff I work on isn't complicated enough to be doing much work without file system changes or requests, but I can imagine that any substantial work inside Docker vs natively can be very different, so depends a lot on the use case.
For me the bottom line is, running browsers with multiple tabs and an IDE will have much bigger impact than Docker vs native so it's not my greatest worry.
@daaain@Elucidating
Fwiw,
(and I acknowledge a certain level of privilege)
I bought a used server for $300; 128G ram, 20/40 Xeon cores, and I used it for builds and docker images, to extend battery life. 🤣 @bitprophet
@blaise@daaain@Elucidating At the moment I'm exploring all this for dayjob reasons, which is Mac/Win only, alas! (I.e.: granting work credentials to a personal Linux box likely Not Okay. Maybe later?)
#Python env management. I’m told PDM is current state-of-the-art, Hatch also good, uv if you're not allergic to VC money, Poetry if you can stomach its bug surface, or the evergreen "just use pip-tools”.
Or use a polyglot tool like mise (fka rtx) or asdf (or haha-only-joking-unless, Determinate System's #Nix installer + flakes).
Also curious about #Rust on macOS arm64, even though that's getting ahead of myself.
@offby1 ah yea, Colima is one of the tools I knew I'd heard of but didn't seem to have in my notes anywheres, thanks! Sounds like it's basically the same VM-host approach Docker Desktop uses, except, it's not by Docker and it's open source?
@bitprophet roughly, yeah; I think any "docker on mac" is going to be VM-ish; you can't really avoid it because the host OS doesn't have the Linux kernel.
@offby1 of course, I was just quietly hoping that the last 4-5 years saw some sort of actual migration to “oh we can run vaguely container-shaped things on macOS arm64 directly now”, but no, of course not 🤣
@hynek@offby1@bitprophet he's convulsing and screaming so I assume ORB like as in CORBA, that's the main place I've seen that sort of reaction to an ORB
@daaain Literally what I've been doing on top of NixOS the last 4 years for personal kit 😂 Nix for the interpreters, -m venv and my old reliable pip shell aliases and requirements.txt’s…
That said, the hygiene of the Cargo/Poetry/etc approach - or at /least/ using pip-tools for a lockfile - is increasingly table stakes.
@daaain basically, though having distinct "acceptable versions" (requirements,txt) and "exact versions" (lockfile) files can be handy in some situations.
@bitprophet I got let down by too many libraries not following semver so routinely pin everything and then use Snyk and other SBOM scanners to let me know if a library has a CVE and needs to be patch updated. In other words, the only acceptable version is the known working one 😅
@bitprophet I like Poetry, with pyenv for maintaining multiple pythons. I’ve been playing with mise recently but don’t see it as a poetry replacement (yet). There’s Armin’s rye if you want to play with something that intends to do All The Things.
@bitprophet I personally use Nix + Poetry.
I like the way Poetry manages dependencies(groups and lock files) and it works with Renovate Bot we use at work.
PDM would make sense because of the one PEP but last I checked Renovate didn’t support it.
@bitprophet At the moment just the latter. However I probably have to look into the former as well when I want to build container images.
I already tried but it is a bit of a pain depending on your dependencies you have to write a lot of overrides.
@nebucatnetzer yea I’ve heard mixed things about poetry2nix (if also that it’s currently the least-bad option if one seriously wants to try and nix-ify one’s Python packages) so for now haven’t tried it. Thanks for the additional anecdata 😄
Add comment