this post was submitted on 08 Mar 2024
25 points (96.3% liked)

Nix / NixOS

1824 readers
1 users here now

Main links

Videos

founded 2 years ago
MODERATORS
25
submitted 9 months ago* (last edited 9 months ago) by [email protected] to c/nix
 

How easy would it be to flakify the Lemmy repo to add a fourth build option for those of us in the Nix world?

I had the (perhaps foolishly ambitious) idea of creating a rolling fork of Lemmy with the intent of modifying the codebase for use in an open source pub sub implementation of retail inventory. But I have to get standard Lemmy working first...and I like to use Nix for everything I do in the dev world (where feasible).

So, I forked the repo and was immediately brought into dev environment hell.

They only offer a choice between:

A.) Docker B.) Ansible C.) Building from scratch.

Two hours of fighting with the scratch build instructions and I eventually had to admit defeat due to some vague dependencies (and general malaise). Though I have completely flakified my Purescript and Haskell dev environments, I have found Rust to be a lot more challenging even on simple projects.

Anyway, I decided to come here to ask: **How easy would it be to flakify the Lemmy repo to add a fourth build option for those of us in the Nix world? **

Can I reference the build instructions from nixpkgs to get close to my intended goal? I need all of the help I can get. Be as pedantic or defeatist as you will. I currently have no skin in this game and merely want to help the Lemmy devs welcome people that are more nixy like myself (if nothing else).


edit: here's a naive attempt. I haven't tested anything other than it being a valid flake. Here's the link to my rolling flakification fork.

{
  inputs = {
    nixpkgs.url = "github:nixos/nixpkgs/nixos-unstable";
    flake-parts.url = "github:hercules-ci/flake-parts";
    systems.url = "github:nix-systems/default";

    # Dev tools
    treefmt-nix.url = "github:numtide/treefmt-nix";
  };

  outputs = inputs:
    inputs.flake-parts.lib.mkFlake { inherit inputs; } {
      systems = import inputs.systems;
      imports = [
        inputs.treefmt-nix.flakeModule
      ];
      perSystem = { config, self', pkgs, lib, system, ... }:
        let
          cargoToml = builtins.fromTOML (builtins.readFile ./Cargo.toml);
          nonRustDeps = [
            pkgs.libiconv
            # Derived from Documentation on Dev installation for Linux
            pkgs.cacert
            pkgs.postgresql
            pkgs.openssl
            pkgs.pkg-config
            pkgs.libpqxx
          ];
          rust-toolchain = pkgs.symlinkJoin {
            name = "rust-toolchain";
            paths = [ pkgs.rustc pkgs.cargo pkgs.cargo-watch pkgs.rust-analyzer pkgs.rustPlatform.rustcSrc pkgs.cacert pkgs.postgresql pkgs.openssl pkgs.pkg-config pkgs.libpqxx ];
          };
        in
        {
          # Rust package
          packages.default = pkgs.rustPlatform.buildRustPackage {
            inherit (cargoToml.package) name version;
            src = ./.;
            cargoLock.lockFile = ./Cargo.lock;
          };

          # Rust dev environment
          devShells.default = pkgs.mkShell {
            inputsFrom = [
              config.treefmt.build.devShell
            ];
            shellHook = ''
              # For rust-analyzer 'hover' tooltips to work.
              export RUST_SRC_PATH=${pkgs.rustPlatform.rustLibSrc}
              export CARGO_PROFILE_DEV_BUILD_OVERRIDE_DEBUG=true

              echo
              echo "🍎🍎 Run 'just <recipe>' to get started"
              just
            '';
            buildInputs = nonRustDeps;
            nativeBuildInputs = with pkgs; [
              just
              rust-toolchain
            ];
            RUST_BACKTRACE = 1;
          };

          # Add your auto-formatters here.
          # cf. https://numtide.github.io/treefmt/
          treefmt.config = {
            projectRootFile = "flake.nix";
            programs = {
              nixpkgs-fmt.enable = true;
              rustfmt.enable = true;
            };
          };
        };
    };
}

and here's the lemmy-ui flake (which, judging by past forays into tsc with nix last summer, should be a lot easier to create and work with than the Rust library):

{
  inputs = {
    nixpkgs.url = "github:NixOS/nixpkgs/nixpkgs-unstable";
    systems.url = "github:nix-systems/default";
  };

  outputs = {
    systems,
    nixpkgs,
    ...
  } @ inputs: let
    eachSystem = f:
      nixpkgs.lib.genAttrs (import systems) (
        system:
          f nixpkgs.legacyPackages.${system}
      );
  in {
    devShells = eachSystem (pkgs: {
      default = pkgs.mkShell {
        buildInputs = [
          pkgs.nodejs
          # You can set the major version of Node.js to a specific one instead
          # of the default version
          # pkgs.nodejs-19_x

          # You can choose pnpm, yarn, or none (npm).
          pkgs.nodePackages.pnpm
          # pkgs.yarn

          pkgs.nodePackages.typescript
          pkgs.nodePackages.typescript-language-server
        ];
      };
    });
  };
}
you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 1 points 8 months ago (1 children)

If you're using flakes and since lemmy is packaged in nixpkgs, you can spawn a dev shell with:

nix develop nixpkg#lemmy-server
[–] [email protected] 11 points 8 months ago* (last edited 8 months ago) (1 children)

Thanks for the advice.

I’m working on getting my own fork of Lemmy therefore I’m attempting to repackage it independently of Nixpkgs so I can get a flake in their actual repo that allows devs to spin up a Lemmy dev environment. I want my dev environment to reflect the changes being made on Lemmy in that dev environment when I make them. Unless I’m missing something, with your suggestion, I’d have no way to test a major change to Lemmy’s codebase in my fork (as I intend to).

[–] [email protected] 1 points 8 months ago (1 children)

This gives you a build environment for lemmy, see the example. You can clone upstream and use that shell to build lemmy. Quite convenient to test quick changes. However, that won't help distributing your fork.

[–] [email protected] 11 points 8 months ago

Thanks for the pointers.