Earlier quoted context omitted.
Surface-level feedback: get rid of the word "derivation". Surely there must be a better way to describe the underlying thing...
Agreed! It's such an alien term to describe something quite mundane. Language clarity is a big part of a friendly UI.
Zb: An Early-Stage Build System
81–90 of 132 posts
Re: Zb: An Early-Stage Build System
#82Re: Zb: An Early-Stage Build System
#83Earlier quoted context omitted.
"Derivation" refers to the nix intermediate build artifact, a .drv file, which contains the instructions to perform the build itself. Basically a nix program compiles to a derivation file which gets run to produce the build outputs. The hash in the /nix/store for a dependency is the hash of the derivation. Conveniently if the hash is already in a build cache, you can download the cached build outputs instead of build…
Ah OK, then I'd actually never actually understood what a derivation is. But then again, the name "derivation" doesn't at all lead to guessing at such a definition, either.
Re: Zb: An Early-Stage Build System
#84If the build language is LUA, doesn't it support top level variables. It probably just takes a few folks manipulating top level variables before the build steps and build logic is no longer hermetic, but instead plagued by side effects.
I think you need to build inside very effective sandboxes to stop build side effects and then you need your sandboxes to be very fast.
Anyway, nice to see attempts at more innovation in the build space.
I imagine a kind of merging between build systems, deployment systems, and running systems. Somehow a manageable sea of distributed processes running on a distributed operating system. I suspect Alan Kay thought that smalltalk might evolve in that direction, but there are many things to solve including billing, security, and somehow making the sea of objects comprehensible. It has the hope of everything being data driven, aka structured, schemad, versions, json like data rather than the horrendous mess that is unix configuration files and system information.
There was an interested talk on Developer Voice perhaps related to a merger of Ocaml and Erlang that moved a little in that direction.
Re: Zb: An Early-Stage Build System
#85Earlier quoted context omitted.
Agreed! It's such an alien term to describe something quite mundane. Language clarity is a big part of a friendly UI.
what word would you fit to what a nix derivation is?
The same is true for "flakes". It's a uniquely Nix term with no previous technical usage AFAIK.
Ideally you want to avoid using specialized terms if possible. But if you do decide to do that, then your documentation needs to be very clear and precise, which is another thing that Nix(OS) spectacularly fumbles. Take this page[2] that's supposed to explain derivations, for example. The first sentence has a circular reference to the term, only mentioning in parenthesis that it's a "build task". So why not call it that? And why not start with the definition first, before bringing up technical terms like functions and attributes? There are examples like this in many places, even without general problems of it being outdated or incomplete.
Though I don't think going the other way and overloading general terms is a good idea either. For example, Homebrew likes to use terms like "tap" and "bottle" to describe technical concepts, which has the similar effect of having to explain what the thing actually is.
Docker is a good example of getting this right: containers, images, layers, build stages, intermediate images, etc. It uses already familiar technical terms and adopts them where they make most sense. When you additionally have excellent documentation, all these things come together for a good user experience, and become essential to a widespread adoption of the tool.
[1]: https://discourse.nixos.org/t/what-is-a-derivation/28311/6
Re: Zb: An Early-Stage Build System
#86Re: Zb: An Early-Stage Build System
#87TIL I can also use semicolons on lua tables, not just commas:
return derivation {
name = "hello.txt";
["in"] = path "hello.txt";
builder = "/bin/sh";
system = "x86_64-linux";
args = {"-c", "while read line; do echo \"$line\"; done $out"};
}
I like using lua as a DSL, now I like it even more! I've using lua as a html templating language that looks like this: DIV {
id="id";
class="class;
H1 "heading";
P [[
Lorem ipsum dolor sit amet, consectetur adipiscing elit,
sed do eiusmod tempor ]] / EM incididunt / [[ ut labore et
dolore magna aliqua.
]];
PRE ^ CODE [[ this is tag inside ]];
}
Re: Zb: An Early-Stage Build System
#88Whatever choices this project makes (I have some opinions, but I think they're not too important) I don't see it mentioning one of the most absolutely critical choices Nix made that was absolutely key to its insane success (at least, IMO, as a hardcore contributor and user for like 10+ years): the monorepo, containing all of the packages and all the libraries for use by everyone downstream, and all contributions tryi…
Re: Zb: An Early-Stage Build System
#89https://github.com/256lights/zb/blob/102795d6cb383a919dd378d... TIL I can also use semicolons on lua tables, not just commas: return derivation { name = "hello.txt"; ["in"] = path "hello.txt"; builder = "/bin/sh"; system = "x86_64-linux"; args = {"-c", "while read line; do echo \"$line\"; done $out"}; } I like using lua as a DSL, now I like it even more! I've using lua as a html templating language that looks like th…
Re: Zb: An Early-Stage Build System
#90Happy to see someone inspired by Nix, but wanting to carve their own path. Nix popularized some powerful ideas in the Linux world, but it has a steep learning curve and a very unfriendly UI, so there is plenty of room for improvement there. I'm not sure if Lua is the right choice, though. A declarative language seems like a better fit for reproducibility. The goal of supporting non-deterministic builds also seems to…