It's working now, thanks. While I've got your attention, it was a little bit of effort to wrap my head around the APIs when `sandbox create` uses --root AND/or --volume, `snapshot create` uses positional args <volumeIdOrSlug> <snapshotSlug>, and `volumes create` uses --from
I know that each of these things is subtly different, but they're similar enough that the bootable snapshot creation workflow (which I expect is a common one) has some sharp edges, since you have to interact with all three APIs at the same time.
Also, the CLI doesn't give a useful error when you try to create a snapshot from a currently attached volume.
Finally, updating a snapshot is more steps than I'd ideally like. I would much rather be able to make changes in a sandbox with a snapshot root and have them persist as a new snapshot. I kind of get why this isn't currently the case, but The volume/snapshot dance feels (for my usecase) like it's missing some abstraction.
That said, now that I've got a snapshot set up it's a nice experience. I've got an alias for `deno sandbox create --root dev --ssh` and I can `claude` in yolo mode without much fear.
But we have an outdated system for general use, which is similar to what you have built: https://doc.deno.land/.
Did you know about this, and did you want to built your own system regardless, or did you not know about it and would this have been something you would have used instead of creating your own system?
Thanks for clarifying, could be perhaps more evident in the changelog.
I know Node had this idea of unstable APIs, but in practice it's hard to enforce of course, if you're building a software & gotta rely on them.
ARM64 builds are something that has been getting investigated. The biggest problem is that github doesnt provide any ARM64 runners, so workarounds around that are necessary
deps.ts is currently the most common way, however new projects like fresh use import maps. the problem with importmaps is they are not composable, as such, using an importmap for a library is usually bad as said importmap is not picked up and used, so the end-user would have to add their own importmap with entries compatible for the library (this is what fresh does: it generates an importmap with entries it needs). due to this problem, deps.ts is the most common solution, however I do hope that composability issue with importmaps will change.
It could be nice to have import-maps composability. However, I don't think it is planned because browsers' import-maps are not composable. I dislike the deps.ts concept. It is one of the main reason I did not switch to Deno yet.
IMHO it's a feature and not a bug that if you import a dependency you also have to carefully review and approve (or add) its dependencies to your application. The entire reason node is a mess of supply chain issues and problems, and is almost like nuclear waste in some professional orgs (i.e. impossible to use because of unclear and unknown licensing concerns, ownership, etc. across thousands of dependencies) is from the ease at which long and complex dependency chains are pulled into a single npm install.
proper applications as well. example is the https://deno.land website has an average CPU time of 6ms. CPU time means it doesnt include any IO bound operations, so ie doing a fetch request wont really contribute to the CPU time.
The M1 builds are made manually by us, as github doesnt provide any runners. the same problem does apply for linux arm, however we don't have any arm linux systems any one of the members use; and building on a pi is a no-go, as that can take 70+ minutes, so that would make our release cycle a lot more complicated. Either way, we are investigating potential possibilities besides waiting for github to have runners available
Have you tried building in a rpi virtual machine on a Mac? I have no idea what the performance would look like, but it’d be easy enough to try, especially since you are already managing your own max builders.
I want to say I followed these instructions for doing so recently:
