I am writing a declerative package manager for Linux, which will hopefully fill the gap between LinuxFromScratch and Nix/Guix. So far the package definitions are completed (called tessera), and after I manage to get some actual packages packaged, I will start working on mosaic, the actual decorative package manager.
I wrote a blog post going into more detail https://aethrvmn.gr/blog/package-manager/
Let me know what you think!
That looks pretty nifty! I've been tempted to do something similar a few times. It'd be really handy for embedded linux projects and Nim is perfect. I tried Nix but ad hoc language never made sense to me.
BTW, if you want to do version resolution I'd recommend copying the DepGraph/SAT stuff from Atlas.
Though it sounds like you want to do a declarative PM. Still being able to say "git >= 2.1" would be pretty handy. Atlas SAT and package info should be easy to adapt to Tessera. Atlas breaks up building up the dependency graph and solving it into two parts. Meaning you could just steal the DepGraph and solver. :) The gitops module too, as using -C makes testing git commands much easier (no hidden CWD state).
Either way I'd be interested in adding it as a plugin to Atlas itself. It'd be cool to be able to pull in and build a C library like libcurl without the headache of wrapping it in Nim static execs or nimscript tasks.
Besides the perfectly valid response of "because I like it" or "because I wanted to", it's not clear to me why one would want to define packages within a nim macro.
At least with the examples I peeked at here it didn't seem like any of them even leveraged the fact that they were written in a programming language and could have just been plain data files.
Are there future features you expect to need that necessitate compiling a build script generated using a nim macro for every package?
Just to clear things up, glaucus is a Linux distribution, not a new operating system. Sure it is independent and opinionated, but it is not a new operating system.
That being said, Nim is only being used to write a boring package builder, not a fancy declarative one like Mosaic. We leverage Nim's C backend to compile the package builder with our custom gcc toolchain. This allows us to cross compile the package builder with our cross compilation toolchain (like any other C/C++ project) and provide it early on in subsequent stages making the bootstrap process a bit easier.
Still very interesting. I also considered going with musl/busybox, but at the point where I felt comfortable enough I was already deep into the LFS pipeline and I didnt want to potentially ruin a weekend's worth of compiling.
There is also TetoRC at https://github.com/Tayzonxperia/TetoRC which is an init system for a future distro called TetOS, so between the three of us we have three early stage nim based distros being worked on :^), very cool tbh.
Interesting indeed.
There is also Kreato Linux which is also using Nim for its package manager.
Good news, I now have a proper justification for using macros. I'm packaging freetype which has a cyclical dependency with harfbuzz. You build freetype, then you build harfbuzz, and then you rebuild freetype. To solve this in the non declerative state I'm at, I can use a simple if statement on the result.
if fileExists("/usr/lib/libharfbuzz.so"):
expectedResult = "libfreetype.so"
else:
expectedResult = "Cyclical dependency. Must be rebuilt"
tessera "freetype":
...
result: expectedResult