Packaging BlueSky Services?

Continuing the discussion started on here: pds: init at 0.4.67, nixos/pds: init by t4ccer · Pull Request #350645 · NixOS/nixpkgs · GitHub

We’re starting to see packages land in nixpkgs for BlueSky.
Since BlueSky is mostly split into two language-specific monorepos (Golang and NodeJS services), we should figure out how to package them in a way that makes most sense, especially since they have common build processes and are interconnected to each other.

@pyrox Has already contributed atproto-goat which is a subset of the Golang BlueSky packages. I spent some time reworking this package to build all submodules in the Golang monorepo, but I’ve been debating naming schema and structure.

@t4ccer Has a PR open to land the pds server of BlueSky here: pds: init at 0.4.67, nixos/pds: init by t4ccer · Pull Request #350645 · NixOS/nixpkgs · GitHub.

I’m interested in the full suite of BlueSky services being in nixpkgs (including the relay, jetstream, etc.). A few questions that would be good to answer:

  1. Should we name / group these related packages together in a way that shows they’re related? Some users might only want to run one component of the BlueSky system, but others might want to run many / all of them.
  2. Given that the build processes will have a high degree of overlap, would it make sense to share some common code / build functions for package derivations?

Lots of options to think through. It might be good to find other package examples that have related components like this in nixpkgs as inspiration. Is there a world where we might want to package the whole system up under one large bluesky package, with many different binaries and components underneath? This isn’t really the nixpkgs way, but it does feel more in-line with monorepo style projects like this.

Curious to hear what people think, and if there’s a chance to collaborate on this work!

9 Likes