Proper way to maintain personal packages / non-nixpkgs derivations?

Help
1

I am looking for guidance when I run into the following two scenarios:

  1. I have certain personal projects that are useful to me, but not production ready and I don’t want to put them on nixpkgs, but I do want them to be packaged as a nix derivation on my computer.

  2. Sometimes I need to compile software in a specific way (PETSc with specific compilation flags for example) so I can’t use the nixpkgs version, but I also don’t think its right to push my specific compilation to nixpkgs since its really only useful to me. But I do want this to be packaged as a nix derivation so I can use it in a nix-shell development environment.

What is the “proper” way of handling these issues? My approach was going to be the following:

  • fork nixpkgs
  • add my nix derivations to my personal fork
  • use that fork as my nix channel in my configuration
  • use my personal projects from my personal nix fork in my configuration file

I wanted to check before I go down this path to see if I am missing any preferred or easier way of doing this.

I am trying to avoid just compiling PETSc (for example) locally on my machine, because I use many different computers and I want the build to be reproducible on all of them. My goal is to have everything done the nix way.

Thank you!

1 Like
2

A possible way is NUR, another is the use of flake.

3

I think the best way is to maintain your own packages in a repository, exposes them in an overlay, then use your overlay in any flake you want.

2 Likes
4

Thank you for the reply. I see how NUR could solve this issue. I’ll dive deeper into that. I am not sure how using a flake could solve this. This is probably due to a lack of understanding of flakes. Could you explain a bit more? I am currently using home-manager in a flake.

5

Thanks for the idea. Could you point me towards some resources to better understand how to do this? My understanding is that I would create a repo on gihub where I would put the Nix expressions for my custom packages. Then in my flake (I’m using home manager in a flake) I’d put something like this in the inputs:

 inputs = {
    nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
    myPackages.url = "github:myusername/my-nix-packages";
  };

And this in the outputs

  outputs = { self, nixpkgs, myPackages }: {
    nixosConfigurations.mySystem = nixpkgs.lib.nixosSystem {
      system = "x86_64-linux";
      modules = [
        ./configuration.nix
      ];
      configuration = {
        nixpkgs.overlays = [
          (import myPackages).overlay
        ];
      };
    };
  };

Then in my configuration.nix file I could write:

  environment.systemPackages = [
    myPackages.myCustomPackage  
    pkgs.somePackageFromNixpkgs 
  ];

Am I on the right track here?

6

Let me do an example project… BRB

7

Here you go: GitHub - drupol/my-own-nixpkgs: Scaffold

4 Likes
8

Wow, I really appreciate that. I’ll get started on this tonight. Thank you very much.

Give me some time and I’ll hopefully be able to help and contribute the way you do. Thanks for all your work.

1 Like
9

I just updated the repository for some more goodness, you might find it useful :wink:

10

I’ve improved it further by providing templates, so no cloning needed to make it work.

Make sure to read the README.

11

I have no idea what that specific software is but for the case where a piece of software is packaged in upstream Nixpkgs but has certain compile-time options that you wouldn’t generally set, you can still work with the upstream derivation. What you’d do is to make the upstream derivation configurable such that you can configure the package according to your needs using simple high-level overrides. See i.e. the ffmpeg package for an example how that can be done.

If that is not possible and this is only required for one specific project, another option would be to include the derivation for the dependency in the project’s source and simply callPackage it there.

12

Thank you! I really appreciate it

13

Thank you. I didn’t know you could make the upstream derivation configurable. I’ll look into that more.