<isd>
garrison: what is your end goal with the nix stuff? Beyond just getting it to build, I have doubts about what a package that would pass the standards for integration into nixpkgs would look like.
<isd>
My own hope was to use nix for reproducible builds, and maybe to make it easier to pull in other system components (e.g. if we want to swap databases or something, we'd need to figure out where to get the DMBS from)
<isd>
*DBMS
<isd>
I think there's an impedence mismatch between how sandstorm wants to operate and what distros expect
<isd>
but I wasn't necessarily shooting for a distro-quality package.
<isd>
I guess the other thing is I'd like to have a solution where you could nix-shell and then use that for development, but pulling out all of the dependencies (particularly capnp) is somewhat counter to that, since it makes it harder to hack on both.
<isd>
(I'm also vaguely wary of being too accomodating to the way distros want to do things; I actively do not want sandstorm packaged in say debian stable, because I do not want to have to deal with systems in the wild that are 3 years out of date. Nix in particular is less bad about this, I think. But it would be very bad if we got into a situation where app developers needed to wait a year or more to use features we ship)
<Corbin>
isd: Just like with k8s, nixpkgs would be enriched by carrying stuff that can transform NixOS machines into Sandstorm hosts. It's okay if nixpkgs without NixOS only carries the raw ingredients.
<garrison>
isd: Right now my goal is to get it to build. In fact, it would be possible to add sandstorm to nixpkgs without building it, just by unpacking the binary.
<garrison>
But either way will require some integration work, as the only supported install mechanism (I think) is install.sh.
<garrison>
It would be nice if Sandstorm could work in immutable environments, i.e., ones where it does not manage its own updates.
<garrison>
I share your concern about out of date packages, but I think a nix one could be kept up to date since things are readily backported.
<garrison>
As I've mentioned before, I think the goals of the sandstorm distro can likely be met using rpm-ostree (better than they could be in nixos). This will likely also involve it working in an immutable environment, so in a sense my work on nix is an indirect way of moving toward that.
<garrison>
seeing where the rough edges are, etc.
<Corbin>
Looking at how Firefox is packaged in nixpkgs and configured in home-manager might be enlightening. It would not be the first time that we support configuring a typically-mutable application which wants to manage its own updates and extensions.
<garrison>
Corbin: does it matter at all that Firefox is a user application while Sandstorm is a system service? I typically think of home-manager as working for the former but not the latter, but I haven't looked at it carefully.
<Corbin>
garrison: Yeah, we'd use NixOS instead of home-manager to manage state, databases, etc.
koo6 has quit [Ping timeout: 260 seconds]
<garrison>
To clarify what I wrote above: yeah, I agree that it would make everyone's life worse if it becomes easy for one to end up with a server running a sandstorm version that is more than ~1 month out of date. I wouldn't want to do anything that could easily result in this future.