`aliases.nix` X `all-packages.nix`: Nim and Hare Implementations

I was wondering if there is a standard or a best practice to know when to use aliases.nix or all-packages.nix.

I ask this by bringing the current implementations of Nim and Hare on nixpkgs.


On its current implementation, the nim package is present on all-packages.nix. This allows for searching it directly on nix search.


On its current implementation, the hare package is present on aliases.nix. Thus, when searching for it on nix search, harePackages.hare is what appears.

Both packages — nim and hare — may be run directly with nix run nixpkgs#<pkgname>, however, as demonstrated above, this is achieved through different means — respectively, all-packages.nix and aliases.nix.

So I ask the following:

  1. Is one implementation preferred to the other? If so, why?
  2. What are the advantages, disadvantages, quirks etc. of using one over the other, besides the one related to nix search?
1 Like

The comment at the top of aliases.nix lays things out:

### Deprecated aliases - for backward compatibility
### Please maintain this list in ASCIIbetical ordering.
### Hint: the "sections" are delimited by ### <letter> ###

# These aliases should not be used within nixpkgs, but exist to improve
# backward compatibility in projects outside of nixpkgs. See the
# documentation for the `allowAliases` option for more background.

# A script to convert old aliases to throws and remove old
# throws can be found in './maintainers/scripts/remove-old-aliases.py'.

# Add 'preserve, reason: reason why' after the date if the alias should not be removed.
# Try to keep them to a minimum.
# valid examples of what to preserve:
#   distro aliases such as:
#     debian-package-name -> nixos-package-name

Things end up in aliases.nix, it seems, when they’re renamed or moved to a different attribute path and a temporary alias is needed for backward compatibility. In the normal course of events, an alias is added, changed to a throw after a certain period of time, and then deleted some time after that. Exceptions exist that will be preserved indefinitely, but these are still not meant to be used by new code.

A redirect intended to be used and supported indefinitely should be defined in all-packages.nix.

I see.

So taking the given examples — hare and nim —, the former should
follow the implementation of the latter, since it’s supposed to be
supported indefinitely.

Thanks for the clarification.

I agree, hare should be in all-packages.nix or in pkgs/by-name/ha/hare/package.nix.

There is an open PR to remove nimPackages completely so there may be better languages for examples of how to do harePackages.


Would any better language examples come to mind?