postal-service: a combined for nix

[Milo123459]

postal-service is a way of combing stable and unstable versions of nix, to give a larger selection of packages. It would work like the current nix registry, just with more available versions.

If the same 2 versions are found in unstable and stable, and some config had changed, it will use the config from unstable. If config changes in different versions, it will always serve the config from the stable/unstable version that has that version.

The main goal is to add support for as many versions of nix packages as possible, whilst maintaining reproducibility and a "it just works" motto.

[JakeCooper]

Can you pull from both stable and unstable?

Suppose a config is two packages [pkgA, pkgB]

pkgA only found in unstable, pkgB only found in stable. Would that work?

[Milo123459]

Yes, that's exactly how it would work.

[ghost]

Alternatively, We can build something like nix-version. This will add support for more version (including versions that have been removed from the current branch).

[ghost]

It's not similar at all. Versions available will still be very limited if we combine both channels. But using something like nix-version will allow nixpacks to support all versions that were once available on the nix store.

[Milo123459]

It does the same thing with a different approach. That one contains more versions, this one doesn't. This one is designed to store recent versions, and not completely ancient ones.

[ghost]

nix only maintains version of packages it thinks is required. They just have one version of maven. But java buildpacks lets one customize maven's version but that isn't possible with nixpacks if we use postal-service(combine both channels).

[Milo123459]

See JRs post, basically postal-serice is changing what it is doing, to just resolving package hashes.

[coffee-cup]

Does that make sense? I want to make sure you all agree/understand why I am suggesting postal service to work that way. IMO it would offer the best flexibility in terms of being able to support all package versions.

[coffee-cup]

I think something like @wyzlle suggested could work quite well. Instead of just searching stable and unstable, we could search all historic Nix archives. Then we could have package@version syntax that would always resolve to an exact version. The process to resolve a package and version could work like this

• No version
  • Pick latest from unstable
• Version specified
  • Search latest unstable
  • Lookup latest archive that has a matching version

When creating the environment.nix file we can easily reference various version of the nix archive in a similar way to how we --pin the archive now

{ }:

let
  pkgs = import (fetchTarball "https://github.com/NixOS/nixpkgs/archive/41cc1d5d9584103be4108c1815c350e07c807036.tar.gz")   {};
in with pkgs;
buildEnv {
  name = "env";
  paths = [
    nodejs
  ];
}

[Milo123459]

This could be automated with postal-service (potentially automatically fetching the tarball, etc), and could be powered by nix-versions as well.

[coffee-cup]

The fetch would be handled by Nix but I think postal service would resolve package@version to a nix archive. This data could be cached by nixpacks. nix-versions looks slightly out of date (doesn't have nodejs 18 which is available on nixpkgs latest) so I think we would have to implement it ourselves (which is what postal service would do). Ideally, we have a rust library we can add as a dep and call with package name and version. Something like

nix_archive_for_package("nodejs", Some("18"))

In the above case it could return a struct like

{
  archive: "41cc1d5d9584103be4108c1815c350e07c807036",
  package: "nodejs_18x",
  version: "18.3.0"
}

[coffee-cup]

I also found another nix pkg version tracker https://pkgs.on-nix.com/