-
Notifications
You must be signed in to change notification settings - Fork 29
Packaging.md
One meaning of the word "packaging" is to include the Ruby interpreter and gems that Shoes is going to use into a single file that you can copy around, run in place or install. Basically, to let Shoes be used on a machine with no Ruby in place, or to use it where there's Ruby but not necessarily the right version or the right gems for your app.
Packaging is going to be enormous. It was very hard for Shoes. It's going to be hard for us. It's also going to have massive overlap with multi-platform issues.
A Shoes app will have one or more Shoes source files. It may also have assets like videos, images, etc. It may have metadata like a Gemfile, a .ruby-version file and so on. Normally a Shoes application can be one of several things:
- A simple single-file single-segment Shoes app, normally called something like my-app.rb.
- A segmented Shoes app with an app, frontmatter and more segments (internal files) all contained in a single file. It may be called my-app.scas.
- A Shoes app in a directory, with some specific Ruby file as the launcher. This has a directory name (no extension) and a launcher name (.rb).
- A Shoes .shy file, called something like my-app.shy. Internally it is a .tar.gz archive with frontmatter tacked on the front and is created from a Shoes app in a directory. It may have Ruby and gems packaged inside, or may assume it will run with system-installed Ruby and Shoes.
Some other packaging methods:
- A .sspec file, which is a segmented app with a packaged test. It assumes it will start the app, run the test and then exit with a test report.
Ruby is already hard to package. We don't want to require a full software-dev-style Ruby install on every machine that can run Scarpe. So we'll want something like Traveling Ruby to install a packaged end-user Ruby instead. It could be some other way of packaging Ruby executables but that field is pretty dead as I write this (Oct 2023).
Yousaf Nabi has been maintaining an alternate fork of Traveling Ruby for projects he's doing, which is probably our best bet: old release issue, more recent release issue, his fork of traveling_ruby.
However, traveling_ruby doesn't support Windows native gems, and native gems are really important to Shoes. For native gems and very recent Ruby, Yousaf recommends a fork of OCRA, a Windows Ruby installer
Testing this stuff is going to be very hard. We'll need to test with a (probably virtual) machine of the appropriate type that doesn't have Scarpe installed and simulate the Ruby-and-Scarpe installation, run the Shoes-Spec tests, etc. Going to be a fair bit of effort.
There's an old Shoes walkthrough that talks more about how Shoes3 did this stuff.
Compatibility and packaging are hard. One great thing about Scarpe-Wasm is that it's cross-platform by nature. But it's also much harder to use it for the kind of "duct tape" debugging and UI apps that Scarpe is so good at, since it can't easily run a command-line program on your local computer.
Old Shoes included binject as a dependency.