Add nix-on-droid

[alexshpilkin]

Nix-on-Droid is a Linux userland based on Nix and Nixpkgs (though not NixOS) that runs on Android inside a fork of the terminal emulator Termux uses. It seems to have a fair number of users given the target audience, although exact numbers are not readily available because builds are only distributed on F-Droid. The maintainer agrees with my wish that it be included in the global registry.

I’m not sure which order registry entries are supposed to be in, so I followed recent inclusions and put the entry for nix-on-droid at the end.

[zimbatm]

Hi, I believe this entry doesn't satisfy the utility point of the inclusion policy: https://github.com/NixOS/flake-registry#inclusion-policy . But let me know if I missed some arguments. You might want to submit this project to awesome-nix.

[alexshpilkin]

@zimbatm Clearly, the submission predates the current inclusion policy (or any inclusion policy, for that matter). That said, I don’t exactly see your point, could you explain what you are referring to specifically?

1. The namespace has a limited size.

A reasonable judgment the maintainer will have to make, but I as a submitter am hardly equipped to. At the same time, the reference class of “reasonably functioning clean-slate configuration system (if on top of Nixpkgs)” has a cardinality of ... four I think? NixOS, home-manager, Nix-on-droid, perhaps devshell. (There were also a couple of Mikrotik-targeting attempts IIRC but they didn’t get off the ground.) So on its face it doesn’t look like it provokes terrible namespace pollution.

2. Common names should be avoided to prevent confusion if a user mistypes an input in their flake.nix and it resolves to another input via the registry.

Not a problem as far as I can tell.

3. The shortcut must offer clear utility to the NixOS ecosystem; it is not intended to showcase random projects.

I mean, it’s ... not my intention to showcase a random project? It’s not my project, either, I was just using it for about a year when I got around to switching its configuration to flakes alongside others and thought it would make sense for it to have a registry entry.

You might argue that a thing that’s not relevant beyond Android is niche, which, I guess, somewhat? Then again, to me, for example, macOS has hardly any relevance. I don’t see this being an easy call either way.

4. Project popularity is taken into account.

I addressed this somewhat it my initial submission—the primary distribution (and, I’d guess, discovery) channel is F-Droid, which doesn’t track app users (even counts), so the policy will need to deal with that. Still, as a straw metric 500 stars on GitHub is sufficient to show popularity beyond “some guy’s obscure project” I’d say (as a guy with no projects that would pass that bar).

---

Again, please make your argument, because if you meant to imply it were obvious, to me at least it is not. I’ve tried to respond above to some arguments I imagine you could make, but that’s hardly efficient or productive except perhaps this first time around.

[alexshpilkin]

Ah, whoops, you did say “the utility point”, and apparently I can’t read. Sorry about that. As I’ve already said above (while failing to read)—perhaps?.. I don’t really see how I could argue one way or another, for any project not used by like half the Nix users, not only this one :)

[zimbatm]

Hey, I didn't mean to attack your submission. Nix-on-droid is a very cool project. I added the policy today, so this is part of an ongoing conversation I am trying to have. Both to judge the clarity of the inclusion criteria and where the line stands regarding the inclusion policy.

I guess, the main question to you is; in what ways do you see including nix-on-droid be beneficial?

[alexshpilkin]

Yeah. For some reason I read your response as just referring to the policy in general, not a specific point, and you can see how I could get a bit salty about that—except that’s not what you wrote! Sorry again about that, I’ll try to verify what I’m actually responding to when I sit down to write a long response from here on out :)

As for the actual question, I’ve realized that I might be using (or ... interpreting?) the flake registry in a way other than the intended one, and I now find myself genuinely unsure whether it’s good or not. From the name-collision point of the policy, I’d guess that the intention is for the registry to simplify interactive use.

My (up to now unarticulated) point of view was that flakes could refer to (e.g.) the nix-on-droid registry entry (perhaps even completely implicitly, by including it in the arguments for the output function), and have that be a simple extension point for users: clone the flake, nix flake update, and it now refers to whatever versions you have recorded in your local registry as opposed to the author’s ones (perhaps a local fork: it’s not that you want to redirect github:t184256/nix-on-droid systemwide, it’s that you want to be using a particular nix-on-droid systemwide). Of course, testing the resulting combination is now entirely on you! And in that respect having to clone the source code seems like an appropriate barrier to entry.

For example, the system registry on my NixOS machines also has a nixos-config entry that points to the (specific revision of the) flake that was used to build that particular machine, and I’ve been thinking that it might be generally useful to reserve a name like that in the registry (but not actually point it to anything there, like the lan. TLD). For interactive use, that’s probably useless, but you could see how it could be useful from the point of view I described. I’d say the nix-on-droid situation is similar in nature.

Does that make sense? Is it a spectacularly bad idea that I’m going to feel intense embarrasment for suggesting? I don’t know! Thoughts?

[edrex]

nix-on-droid is roughly a peer to other host-config-management nix projects like home-manager, nix-darwin, and nixos, so it should pass or fail the utility criteria along with them. As detailed above, including it in the registry allows upstream flakes that utilize nix-on-droid (such as those that provide a nix-on-droid module) to make their nix-on-droid input follow the system registry entry, which gives the system admin a single point to override that input. AFAICT this is one of the design use-cases for the registry (but I may be misunderstanding).

As far as popularity, anecdotally I've seen a few linux-comfortable folks adopt it successfully as their first experience with nix-the-package-manager, since the barriers to entry are so low (just install an app on the phone in your pocket).