Skip to content

v0.220
Compare
Choose a tag to compare
@warpfork warpfork released this 22 Dec 19:27
· 4 commits to master since this release
release/v0.220
4254c09

This release is fabricated -- reproducibly! -- by the scripts in the omnibus dir of this repo. All source hashes can be seen pinned there. All build instructions are captured in formulas. There are two implementations of the build pipeline; the first uses bash, the second uses our own stellar tool. Both should produce identical results, and those results should also be identical to the attachments to this release on github.

This release has several massive changes; both in small quality-of-life improvements, in new features, and in a few schema changes. Lots of first-time setup operations when using stellar are now done automatically; we have recursive eval across modules (...!!!); the concept of "workspaces" in stellar has been dramatically simplified; and yes, there's one change to the module schema which will require some migrations (but everything Layer 1 and below is still unchanged). So there's a lot to read in the detailed changelog below!

Oh, and the release binaries are static. Because if you're working on bootstrap stuff, you probably don't appreciate having to bring your own libc. Yep, we hear you. Fixed. Sorry we didn't get on it earlier.

Major changes since the last release:

  • stellar:
    • workspace rework & simplification! This is mostly documented at polydawn/reach#4 . In short: a dir named .timeless is now always (and exclusively) the denotation of a workspace root. And a workspace is always necessary.
      • if you were previously confused about the difference between anonymous module mode and workspace mode, yep, you weren't alone. That was silly, and now the difference simply doesn't exist. Much easier!
    • lots of uninteresting initialization work (making directories, etc) is now automatic. Details at polydawn/reach#6 .
    • module-recursive eval mode!!!! 🎆 🎆 🎆
      • (this is has sometimes been referred to as "commissioning".)
      • stellar emerge -r $moduleName will now load the named module, and if it has any imports which refer to releases of other modules with a version name of "candidate"... it will automatically recurse to those modules, build their latest version, and use that.
      • yes, this works recursively.
      • each such evaluation will produce a "candidate" release. You can see the catalog files for these at $WKSPC/.timeless/candidates/default/*.
        • these "candidate" files are stored in the same format as other catalog releases. They're totally normal. So, they're imported in a fundamentally normal way to the module that references them.
        • the one exception to "candidate" release normalcy is that they're not suitable for publishing publicly. The intended path is to rewrite them into releases with a more permanent name, and then do so and publish that... at your leisure. (We'll introduce tools for automating this in the near future.)
      • this entire "candidate" system also works with regular stellar emerge; every module evaluation will leave behind a candidate release that other modules can import. -r-mode just makes all evals automatic so you don't have to sequence commands manually.
      • so! Now you're really free to start building large systems. Use a single module (with steps within it whenever you need separate containers with unique filesystems) when working on a single project; split things up into several modules whenever you deem it appropriate to do so, and when you want to be able to label and make releases of the products of each module. You're in control, and both forms of structure work easily and recursively.
    • there is a breaking change to the Module format. The Operation.Inputs map flipped key-value ordering: it is now Path:SlotRef ordering.
      • breaking changes are always unfortunate, but on a happy note, the migration is easy and mechanical; and it's only modules that have changed (no Layer 1 components or below are altered).
      • see polydawn/go-timeless-api#1 / polydawn/go-timeless-api@cf6aecf for more details on the reasons for this.
    • internally, some improvements to testing. Since we're doing a lot of stuff that infers things from surrounding context on the filesystem, it's important to make sure where the source repo is and its surroundings can't interfere too much! So, now we have a little more of the needed infrastructure for that: test fixture files are now copied into a tmpdir before test launch.
  • repeatr:
    • nothing changed, actually :3
    • we've successfully reached the point where all the interesting new challenges are appearing in how we use it (e.g., stellar)!
  • rio:
    • some error messages are improved, and typos fixed.
    • bug fixed in the git transmat: previously, if you asked for a hash you hadn't cached before from a repo which you'd already cloned, and the update fetch found that all remote refs were identical to their previous values, a nonsensical error would be raised. Now, that no-op is just a no-op. As it should be.
    • that's also it! As much as we might like to be adding new packtypes and warehousing transport protocols, all's quiet; and that's okay: things are settling into simply being... stable.

Oh, P.S.: You might want to check out the https://github.com/warpfork/smsh project. It's a small shell -- in golang, so its easy to compile, cross-compile, and ship statically -- and it's specifically designed to do the right thing when you pass an array of command strings to it (which can be cleanly appended, unlike bash, where unsafe concatenation is your only option for composition) -- and it keeps bash syntax so there's no new language to learn. It might be useful in your containers!

P.P.S.: There's a new project beginning to produce rigorously portable and well-packaged (and composably, path-agnostically packaged) software... and of course, building it with the Timeless Stack, because why wouldn't you... starting over at https://github.com/polydawn/radix . This is early days, and going to take a while to show really exciting results, but watch this space if portable packaging is your jam.

Live long and function purely!

Assets 3
Loading