馃摎 Context
The CLI uses several external programs to fullfil its duties. This is a non-exaustive list of programs used by build and run commands:
- cartesi-machine
- cartesi-machine-stored-hash
- xgenext2fs
- mksquashfs
- cartesi-rollups-cli
- cartesi-rollups-node
Some of these programs are maintained by the Machine Emulator Unit and others by the Node Unit.
The only binary distribution for those is currently to Debian, usually packaged as a Docker image, and compiled to amd64 and arm64 architectures.
Depending on Docker on the user machine has proven to not be so easy. Docker Desktop has improved the user experience a lot, but there are still some issues that may happen, and also users who don't use Docker Desktop and try different installation methods, causing problems.
鉁旓笍 Solution
We will still depend on Docker for buiding the root filesystem of the user application, with the help of Docker RISC-V support through QEMU, but we could reduce this dependency if we had the binaries above distributed to our supported development platforms and architectures:
OS:
- macOS
- Linux
- Windows through WSL2
Architecture:
Instead of spawning binaries another possibility is to build NodeJS bindings to native code components listed here. This allows more flexibility as how to drive the use of those components, and is more elegant IMO.
馃搱 Subtasks
馃幆 Definition of Done
馃摎 Context
The CLI uses several external programs to fullfil its duties. This is a non-exaustive list of programs used by
buildandruncommands:Some of these programs are maintained by the Machine Emulator Unit and others by the Node Unit.
The only binary distribution for those is currently to Debian, usually packaged as a Docker image, and compiled to amd64 and arm64 architectures.
Depending on Docker on the user machine has proven to not be so easy. Docker Desktop has improved the user experience a lot, but there are still some issues that may happen, and also users who don't use Docker Desktop and try different installation methods, causing problems.
鉁旓笍 Solution
We will still depend on Docker for buiding the root filesystem of the user application, with the help of Docker RISC-V support through QEMU, but we could reduce this dependency if we had the binaries above distributed to our supported development platforms and architectures:
OS:
Architecture:
Instead of spawning binaries another possibility is to build NodeJS bindings to native code components listed here. This allows more flexibility as how to drive the use of those components, and is more elegant IMO.
馃搱 Subtasks
馃幆 Definition of Done