How do I deal with a new package whose binary name is identical to an existing one?

1

I just discovered nom, a tui rss-reader that I think is pretty neat. I thought it would be cool to have this in Nix and it seemed like a simple enough application to give it a try myself.

Having never packaged a new application before, I just had a look at restic’s default.nix and removed anything I thought wasn’t needed.

I came up with this:

{
  lib,
  buildGoModule,
  fetchFromGitHub,
}:
buildGoModule rec {
  pname = "nom";
  version = "2.0.2";

  src = fetchFromGitHub {
    owner = "guyfedwards";
    repo = "nom";
    rev = "v${version}";
    hash = "sha256-6tk8NRuBbRMoaz3CmUUOC6thxIgjk/MWl50+YgQ6l5o=";
  };

  vendorHash = "sha256-fP6yxfIQoVaBC9hYcrCyo3YP3ntEVDbDTwKMO9TdyDI=";

  meta = with lib; {
    homepage = "https://github.com/guyfedwards/nom";
    description = "RSS reader for the terminal ";
    platforms = platforms.linux ++ platforms.darwin;
    license = licenses.gpl3;
    maintainers = [];
  };
}

Totally works, which is great, but there’s also nix-output-monitor in nixpkgs
that shares the same nom name for its binary.

What’s the correct way of dealing with something like this? I can only think of actually convincing upstream to change the name, or alternatively using a custom one just for nix.

2

Since every package is installed to its own prefix, it generally doesn’t matter if two programs share a binary name — this is often the case in Nixpkgs.

The only time it does matter is if you want to use both in a single search path or directory structure. For example, if you want to put both in environment.systemPackages. The best thing to do in this case would probably just be to set up some shell aliases, e.g.:

{ lib, pkgs, ... }:

{
  environment.shellAliases.nom-rss = lib.getExe pkgs.nom;
  environment.shellAliases.nix-output-monitor = lib.getExe pkgs.nix-output-monitor;
}
3 Likes
3

Thank you, I’ll use that suggestion in my config.

So if I wanted to create a PR for nixpkgs, the package is fine as it is, right? Any conflicts would need to be solved by a potential user.

4

Yeah, it should be fine as-is.