Upstreamability status?

[Pandapip1]

This looks like pretty much what I want, particularly in terms of reducing the overhead of running Nix in CI. What's the status of upstreaming these patches to nix and nixpkgs? Is this still in active development? I see this uses GPLv2 only whereas nix uses LGPLv2.1 and nixpkgs uses MIT; might that cause issues?

[theoparis]

I would like to see this as well. The licensing issue is a good point. Another point worth bringing up is that styx is mostly Go code and Nix is written in C++...

[dnr]

There's maybe two separate questions here:

1. Could the patches in https://github.com/dnr/styx/tree/main/patches be upstreamed, and
2. Could the whole project somehow be "upstreamed"? (whatever that might mean)

For 1: I don't think the Nix team (or any fork of Nix) would accept those patches in their current form: they're a quick hack just to get things working, and they're fairly specific to Styx itself. The direction that things could go here, in theory, is to design a plugin mechanism for alternate substitution mechanisms, implement that, and then Styx could use it.

In theory this is simple enough, you need a protocol (either the simple http/json/unix socket protocol that Styx uses or maybe something based on subprocesses and pipes), a registration and opt-in mechanism for plugins, and a little metadata so that Nix can delete paths from the right plugins.

I think this would have to go through the RFC process and I would expect it to take a while. Possibly a fork of Nix would be more receptive with a quicker process.

For 2: That's much more ambitious: essentially that means Nix supporting a new substitution protocol natively, which is a pretty huge deal. There are a lot of infrastructure questions to consider. For one, it would not be cost-effective to offer a binary differ for free, though it would be possible (and maybe save money) to offer a pure chunk store.

This would probably be a series of RFCs with lots of work and I estimate maybe 2-3 years even if I worked on it full time :) Yes, the Go code would probably have to be rewritten in C++ at some point. The good news is that if (1) exists, then there isn't as much need for (2). Though in the long term I believe Nix does need something like this.

As for licences: so far I've written all the code for this project and I'd be happy to relicense it as required, so that's not really an issue.

Active development: I'm still using Styx on my personal laptop and fixing bugs. I do have an intention to continue work at some point but I've been too busy with other stuff lately.

[Pandapip1]

Okay; would you mind relicensing to LGPLv2.1 or later just to ease any future nix compatibility concerns?

[dnr]

Is the current licence preventing you from trying out or using the software in any way? I'm open to changing the licensing but it seems way premature to talk about upstreaming.

[Pandapip1]

Is the current licence preventing you from trying out or using the software in any way?

No, although from experience re-licensing after accepting third party contributions is a bit of a pain. I guess I might as well try to get this set up! Do you have a nixos config you can share? Never mind, I forgot to RTFM: https://github.com/dnr/styx?tab=readme-ov-file#use-it-in-your-system-configuration