Replace Gambas with Nix

[SandaruKasa]

I'm trying to make this thing also build inside Nix, just for the fun of it, and I've run into the issue that Gambas is not packages in Nixpkgs and is quite a hustle to build manually.

So why not replace Gambas with the Nix language itself? After all, Gambas was not that fun (just add a "print"), and, luckily, Ubuntu has nix in its repos.

I was initially going to add Numbat, but Ubuntu being Ubuntu has a version of Numbat from spring (despite itself being released autumn 2025), back then they didn't even have string escaping.

---

P.S. amazing piece of work, I should finally stop procrastinating on learning Japanese and eventually read the book about this quine.

[mame]

Thanks for the suggestion.

To be honest, supporting multiple operating systems in quine-relay is difficult. When an Ubuntu package used in quine-relay disappears, I sometimes need to look for a new language and replace it. At that point, I don't want to impose a constraint that the language must be available as a package on multiple operating systems.

That said, if simply replacing Gambas with Nix makes it work on the current NixOS, I think I would be okay with accepting this change itself.

However, I'm not planning to make further changes beyond that, such as additional modifications or adding NixOS CI. Also, I can't promise that Gambas will never be used again in the future. Would that be acceptable to you?

[SandaruKasa]

I in no way suggest you take the burden of maintaining 128 toolchains on yet another OS, especially such an exotic one as Nix. I have no intention of upstreaming this experiment, but after managing to get everything except for Gambas working under Nix, I would be really happy if just this one language could be replaced upstream. And yes, I am fine with having no guarantees that it won't be brought back.

---

That being said, here are the results of my little experiment (took me roughly 2 days):
https://github.com/SandaruKasa/quine-relay/tree/nix (based on top of this PR)

So,

nix -Lv build github:SandaruKasa/quine-relay/nix

will build the entirety of Quine Relay inside of nix.

This required writing nix recipes for the following 21 packages (not counting the vendored ruby scripts):

1. acme-chef
2. afnix
3. aplus
4. beanshell
5. cfunge
6. cimfomfa
7. genius
8. gm2
9. gpt
10. lazyk
11. lci
12. livescript
13. nickle
14. parser3
15. ratfor
16. spin
17. spl2c
18. squirrel
19. vlt
20. yorick
21. zoem

as well as some tweaking to quine-relay's 128 build steps, mostly to turn each step into its own separate derivation and work around occasional dynamic linking shenanigans from Nix.

See also: NixOS/nixpkgs#131492

[silky]

Seems we had a similar idea @SandaruKasa 😀

[mame]

Thank you both, what an interesting coincidence.

TBH, I prefer #162 over #163.
I know nothing about Nix packaging or its culture, but I don't want to maintain patches for each interpreter in this repository.
Also, flake.nix don't seem maintainable for me who doesn't use Nix regularly.

Not having to remove Gambas is an advantage, but I don't have such a strong attachment to Gambas that it outweighs the disadvantages mentioned above.

[silky]

No worries @mame

Do note that it's trivial for @SandaruKasa to add gambas to this PR now; if they wish, by just taking the Nix derivation I made. So if you want to keep it, you can. That said, it's of course nice to see Nix in the list :)

I agree that the PR I have is a little large; and that this approach is done more elegantly in general. It's really nice work @SandaruKasa !

Very cool/interesting to see that we both were inspired to try this at pretty much the same time! Also a cool story for Nix that packaging all of this was so approachable that two people could do it independently in a matter of days 😀 :)

[silky]

Note: @SandaruKasa , the genius build fails for me; I think the URL you're using seems to 404; but you can change it like so if you wish:

diff --git a/nix/genius.nix b/nix/genius.nix
index cb29ec9..665b501 100644
--- a/nix/genius.nix
+++ b/nix/genius.nix
@@ -16,18 +16,16 @@
   termcap,
   readline,
   vte,
+  fetchgit
 }:
 
 stdenv.mkDerivation rec {
   pname = "genius";
   version = "1.0.27";
-
-  src = fetchFromGitLab {
-    domain = "gitlab.gnome.org";
-    owner = "GNOME";
-    repo = "genius";
-    tag = "genius_1_0_27";
-    hash = "sha256-Q+s4sRPq3ho/W8wIdtrgKbBRlOPbxLqh2fpNICiOI54=";
+  src = fetchgit {
+    url = "https://gitlab.gnome.org/GNOME/genius/";
+    rev = "genius_1_0_27";
+    sha256 = "sha256-Q+s4sRPq3ho/W8wIdtrgKbBRlOPbxLqh2fpNICiOI54=";
   };
 
   strictDeps = true;

[SandaruKasa]

Sorry for disappearing, I'm back.

Not sure what the issue with the src of genius is. It fetches just fine for me on two different machines on two different networks.

What does cause some issues for me is afnix's src, but that's because Russia seems to have blocked some part of AWS, so now a third of sites on the internet just won't load unless you employ some countermeasures. Yay.

Anyways, it seems like the Swift issue has been fixed in nixpkgs 25.11, so now we don't need two nixpkgs versions anymore, yay. Gonna push an update to my fork soon.

I will take a look at building Gambas following your recipe, @ silky, and if it looks viable I guess I can just close this PR.

[silky]

That's weird re: the src change there I agree; maybe it was a temporary issue with gnome.org somehow (though now looking at the diff I can't imagine how 😅 ).

Do note that I've done some solid updates to my branch now @SandaruKasa following your style in various places.

Was nice to learn from you :)

I still think it'd be nice for someone to get a flake.nix added to this repo; but the thing I found when playing with it more (and I'm sure you noticed the same), is that what you really want to do is add more languages; and that's a much deeper change to the code in this repo to support that (because a lot of the generating code is structured around the assumption that it's going to work on Ubuntu.)

[SandaruKasa]

Was nice to learn from you :)

I wish nix was more accessible and didn't require so much peer-to-peer learning. But glad you found my stuff helpful.

I still think it'd be nice for someone to get a flake.nix added to this repo;

Perhaps, but that means putting additional (and quite tremendous) maintenance burden on the repo owner. So I don't really see it as a possibility.

Maybe it would be nice to integrate nix recipe generation into existing Rakefile infrastructure (in a fork), but that's not something I'm personally interested in doing at the moment.

I will take a look at building Gambas following your recipe, @ silky, and if it looks viable I guess I can just close this PR.

Eh, still a pain in a certain body part. I see that in your repo you have a different version of nixpkgs pinned specifically for gambas. Using the same recipe on nixpkgs 25.11 didn't work out for me. And I personally don't really feel like adding a second nixpkgs version (especially now that Swift no longer needs it). Or spending more time dealing with Gambas's painfully slow and cryptic build process.

---

So I guess I still want to move forward with this PR. I think I've addressed all the review notes. Would appreciate if you could take another look at this PR, @ mame.

[silky]

Do note one trivia @SandaruKasa , is that because you use runCommand and don't explicit mention src inputs; if you for example edit QR.rb and then rebuild, your entire derivation chain does not rebuild; this is a little unfortunate in my opinion, because it makes it a little harder to see the joy of the nixification; i.e. cached rebuilds only exactly when you need them.

[SandaruKasa]

because you use runCommand and don't explicit mention src inputs; if you for example edit QR.rb and then rebuild, your entire derivation chain does not rebuild;

No, that is because I use fixed-output derivations with hashes taken from SHA256SUMS. So when a source for one of the step changes, it only rebuilds that one step, gets the same output hash, and deduces there's nothing else to redbuild.