Nixpkgs: NixOS-only packages in nixpkgs

[fpletz]

Problem

From a discussion in #11592:

Some packages in nixpkgs are tied to their specific NixOS module or some paths only available on NixOS. nixpkgs should however also be usable on other operating systems and Linux distributions.

This has different reasons. For instance the person that packaged it could just not have had the time do it properly but in other cases like Gitlab where there are hardwired paths where write access is need to modify or add files in the code which need to be patched to point to general locations for which there is IMHO no real convention where to put it. As patching those paths deviates from upstream documentation there is no way for users of nix-env to inspect and find out about those paths for editing configuration or putting application state or caches.

Proposed solution

I propose adding a new boolean meta attribute called e.g. onlynixos (looks awful, other options welcome!) so that these packages raise an error when trying to use them on non-NixOS systems.

Open Questions

Is there a way to determine if the package is used on a NixOS system or is this maybe an information that can only be obtained from nix itself?

[dezgeg]

IMHO this could be generalized even further, i.e. a way to prevent a package from being added to systemPackages or nix-env -i'd even on NixOS. Potential use cases:

• Prevent installation of libraries, since lots of newcomers will try nix-env -i pythonPackages.numpy and then try to use it in an interactive python session, or nix-env -i openssl and try to compile stuff that requires OpenSSL. It's not nice that installing them works fine but actually trying to use them like in other distros fails silently.
• Prevent installation of packages providing services and drivers; since newcomers will try to put apache or the NVIDIA driver into systemPackages, which doesn't work either.

[7c6f434c]

• Prevent installation of packages providing services and drivers; since newcomers will try to put apache or the NVIDIA driver into systemPackages, which doesn't work either.

I think having Apache in your systemPackages can sometimes be useful,
though. If only for ab…

[cleverca22]

and openssl in the env, for things like "openssl s_client" (basically telnet with ssl support)
maybe mixing in the seperate output stuff, dont allow openssl.dev to enter the env, since thats not how nix works

[knedlsepp]

Hm. Giving this some more thought I'm not sure if this is the right move. Is there really a reason why such a package will only be useful on NixOS? From a non-technical viewpoint, what makes a service like gitlab different from the standard helloworld is that it needs some extra configuration to work properly and thus may not meaningfully be installed as an ad-hoc via nix-env -i. I guess raising an error for trying to install a package which expects additional arguments (the configuration) might be more straightforward than making said package nixOS specific.

[joelmo]

I would prefer that nixpkgs gives a warning when trying to do something unsupported. The user may know how to fix that and giving them an error and aborting everything would be annoying.

[vcunat]

To do this, we would probably need some changes in nix itself, as IMO nixpkgs can't detect during evaluation whether a package is built as a dependency or to be installed directly. To be more general, we could just add
meta.dontInstall = "message explaining why you probably don't want to install it";
(perhaps with a different name :) and leave deciding the value of that to the nixpkgs layer. If we wanted to support this on nix-env -i /nix/store/some-package, things would get more complex.

Still, for the particular (non-)nixos case, I'm not certain how should nix(pkgs) decide whether it runs on nixos or not. (This might also be helpful wrt. using nixpkgs.config from configuration.nix.)

I think having Apache in your systemPackages can sometimes be useful, though. If only for ab…

I imagine nix-env would abort with a warning, but you could force it by some setting (env var might be easiest as it could be read by nixpkgs directly).

[peti]

IMHO, this approach doesn't feel right. I see no reason why a package in Nixpkgs should work on NixOS only. If such a package exists, then it seems much better to document the proper settings and/or to parameterize the build expression so that proper defaults can be built-in.

[Profpatsch]

One concrete action item would be to compile a list of packages for which this is true. Maybe this can be automated.

[stale[bot]]

Thank you for your contributions.

This has been automatically marked as stale because it has had no activity for 180 days.

If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity.

Here are suggestions that might help resolve this more quickly:

1. Search for maintainers and people that previously touched the related code and @ mention them in a comment.
2. Ask on the NixOS Discourse.
3. Ask on the #nixos channel on irc.freenode.net.