I noticed that the [really great] nixpkgs search page doesn’t give instructions on how to run services, e.g. via modules or Nix container. I observed Nix standalone users (without NixOS) to be confused by this, including myself when I started using Nix a few years ago. I remember at the time I wanted to run elasticsearch and basically tried what the search page still suggests without succes:
Since services and modules are such a big part of the Nix world, how about adding instructions for services/modules for NixOS users and standalone (e.g. via nix container) to this page where appropriate?
To add this information we would need to link packages to their NixOS modules, somehow.
A way could be to use the relatedPackages option of mkOption, there is only a handful of modules using it, though.
Alternatively a new attribute in the package could be added, like meta.module, or maybe in passthru.
We had one more idea about this this morning when writing nixos tests:
If setup correctly, a NixOS test can startup a full, preconfigured instance of a service with a single command in a VM. It just needs port forwarding through the qemu VM network to be accessible from the host machine, the browser etc. Tests are also known by packages through the passthru argument. So why not expose tests with a particular name, e.g. exampleInstance on the search page with an associated command to run them? The command could be either existing ones, or a new one that directly includes the one-liner that forwards the port? The test snippet itself would serve as template documentation to setup your own configuration. Maybe it could even really be connected to flake templates so that you can just do flake init -t nixpkgs#elasticsearch or something similar.
In a time, where the community tries to decouple the different layers of the Nix ecosystem, such ideas (while undoubtedly useful for some) may require a thorough second consideration.
There is at least one entirely “neglegted” branch of use cases of the Nix ecosystem tree, in which NixOS modules don’t make any sense at all and it would be “discriminatory” (or at least counter-productive) to suggest that NixOS module system is at the core of the Nix ecosystem.
Now, what is that perspective/branch (of which I have knowledge of)? → Nix language in DevOps used as a configuration lingua franca. “Nix as alternative to yaml / cue / dhall / json / hocon / hjson / hcl / etc”
With that constructivly meant, dialectically opposite perspective in mind, what would be an even better solution to the NixOS discoverability problem that you describe?
Edit: For the semantic discussion around the Nix ecosystem and further reference, I defer to the work of the Doc Team.
That’s true @blaggacao . However, I do think that “services and modules are such a big part of the Nix world” is a fair statement. Maybe, it makes sense to postpone the bigger question about whether and how to integrate modules and service into a configuration lingua franca, and just focus on pragmatically making the search page usable for now.
I don’t oppose out of practicality / path-dependency.
But I want to add the somewhat anecdotal account that the very existence of NixOS (and the way it is currently presented) is a hinderence to adoption of Nix.
People see NixOS and feel they also have to switch their OS. Next thought, then: “you, Nix, go away and leave me alone”.
I have that problem every day and I’m glad to see the attempts of the Doc Team to rectify our semantics.
The root issue, here, of course is in the current semantics, not in your proposal.
I really just wanted to shed some light on this other aspect for consideration. This is where I’m coming from.
