In reply to @pederbs:pvv.ntnu.no
make an alias?

One nice property of flakes is that I can address them as github:edolstra/hello, that's something I can remember as a human. This reference changes over time and is not reproducible. Whenever I call nix build github:edolstra/hello, Nix must inevitably somehow resolve this reference to a concrete revision. The concrete revision is a long hexadecimal string I cannot remember. Therefore I do see value in nix build to, when requested, just print the revision. Then, I can share its output (which now includes the resolved URL, which includes the hash) to my teammates, who can run the same build even if the revision that the default branch of github:edolstra/hello resolves to has changed in the meantime.

It's not a question of whether there is a possibility to somehow obtain a fully resolved flake URL, and that it can be provided as an argument to nix build, but a matter of convenience of the user experience with nix build.

One nice property of flakes is that I can address them as github:edolstra/hello, that's something I can remember as a human. This reference changes over time and is not reproducible. Whenever I call nix build github:edolstra/hello, Nix must inevitably somehow resolve this reference to a concrete revision. The concrete revision contains a long hexadecimal string I cannot remember. Therefore I do see value in nix build to, when requested, just print the revision. Then, I can share its output (which now includes the resolved URL, which includes the hash) to my teammates, who can run the same build even if the revision that the default branch of github:edolstra/hello resolves to has changed in the meantime.

It's not a question of whether there is a possibility to somehow obtain a fully resolved flake URL, and that it can be provided as an argument to nix build, but a matter of convenience of the user experience with nix build.

One nice property of flakes is that I can address them as github:edolstra/hello, that's something I can remember as a human. This reference changes over time and is not reproducible. Whenever I call nix build github:edolstra/hello, Nix must inevitably somehow resolve this reference to a concrete revision. The concrete revision contains a long hexadecimal string I cannot remember. Therefore I do see value in nix build to, when requested, just print the revision, i.e. the result of the resolution it must perform anyways. Then, I can share its output (which now includes the resolved URL, which includes the hash) to my teammates, who can run the same build even if the revision that the default branch of github:edolstra/hello resolves to has changed in the meantime.

It's not a question of whether there is a possibility to somehow obtain a fully resolved flake URL, and that it can be provided as an argument to nix build, but a matter of convenience of the user experience with nix build.

What is the flakes way of going about installing packages from different nixpkgs branches?

I have been seeing stuff like this everywhere, but no equivalent method for flakes that doesn't break reproducibility:

unstable = import <nixos-unstable> {};
environment.systemPackages = [ unstable.myPackage ];

or

unstable = fetchTarball https://github.com/NixOS/nixpkgs/archive/nixos-unstable.tar.gz

I was thinking about making an overlay using flake-utils.lib.eachDefaultSystem to instantiate nixpkgs to be set as pkgs.unstable, but this feels wrong and I'm wondering if this will cause lots of cache misses & blow up my build times.

Is there a "best practices" way of going about this?

In reply to @lehmanator:gnulinux.club

What is the flakes way of going about installing packages from different nixpkgs branches?

I have been seeing stuff like this everywhere, but no equivalent method for flakes that doesn't break reproducibility:

unstable = import <nixos-unstable> {};
environment.systemPackages = [ unstable.myPackage ];

or

unstable = fetchTarball https://github.com/NixOS/nixpkgs/archive/nixos-unstable.tar.gz

I was thinking about making an overlay using flake-utils.lib.eachDefaultSystem to instantiate nixpkgs to be set as pkgs.unstable, but this feels wrong and I'm wondering if this will cause lots of cache misses & blow up my build times.

Is there a "best practices" way of going about this?

In reply to @petrichor:envs.net
you can include it as another input to your flake, like nixpkgs-unstable.url = "github:nixos/nixpkgs/nixos-unstable";

Right, but how should I make its packages accessible by the system / home-manager?

I know I can do something like:

In reply to @petrichor:envs.net
you can include it as another input to your flake, like nixpkgs-unstable.url = "github:nixos/nixpkgs/nixos-unstable";

Right, but how should I make its packages accessible by the system / home-manager?

I know I can do something like:

In reply to @petrichor:envs.net
you can include it as another input to your flake, like nixpkgs-unstable.url = "github:nixos/nixpkgs/nixos-unstable";

Right, but how should I make its packages accessible by the system / home-manager?

I know I can do something like:

nixpkgs.overlays = [
  (final: prev: { pkgs.unstable = inputs.nixpkgs-unstable.legacyPackages.${prev.stdenv.system}; })
];

but I remember seeing one of the big maintainers saying that using a lot of overlays is discouraged and often causes slow builds, and suggested a better practice (which unfortunately I dont remember) for overriding / adding packages, but that was for one-off packages and not an entire instance of nixpkgs.

In reply to @lehmanator:gnulinux.club

What is the flakes way of going about installing packages from different nixpkgs branches?

I have been seeing stuff like this everywhere, but no equivalent method for flakes that doesn't break reproducibility:

unstable = import <nixos-unstable> {};
environment.systemPackages = [ unstable.myPackage ];

or

unstable = fetchTarball https://github.com/NixOS/nixpkgs/archive/nixos-unstable.tar.gz

I was thinking about making an overlay using flake-utils.lib.eachDefaultSystem to instantiate nixpkgs to be set as pkgs.unstable, but this feels wrong and I'm wondering if this will cause lots of cache misses & blow up my build times.

Is there a "best practices" way of going about this?

In reply to @lehmanator:gnulinux.club

What is the flakes way of going about installing packages from different nixpkgs branches?

I have been seeing stuff like this everywhere, but no equivalent method for flakes that doesn't break reproducibility:

unstable = import <nixos-unstable> {};
environment.systemPackages = [ unstable.myPackage ];

or

unstable = fetchTarball https://github.com/NixOS/nixpkgs/archive/nixos-unstable.tar.gz

I was thinking about making an overlay using flake-utils.lib.eachDefaultSystem to instantiate nixpkgs to be set as pkgs.unstable, but this feels wrong and I'm wondering if this will cause lots of cache misses & blow up my build times.

Is there a "best practices" way of going about this?

when you do outputs = { self, ... }@inputs: ...; in your flake.nix, pass inputs to specialArgs, then you can use the flake inputs and outputs (via self) in your nixos modules. maybe home manager has something like specialArgs too.

for example: https://or.computer.surgery/charles/servy-fleet/-/blob/3eae347d2cce33d1fed7371346b9d8b2aced891b/config/matrix-conduit/default.nix#L17

Hey everyone. Flake novice here. I used a flake to create a reproducible development shell for one of my python applications. So far, so good.

Then I wanted to integrate my application into my configuration.nix and run it as a recurring service via systemd. To this end, (after browsing github for inspiration), in my nix config repo I created a pkgs/app/default.nix, which points to the github repo of my application, and a modules/app/default.nix, which defines settings and applies those appropriately. My configuration.nix imports the app's module and enables it. Although it took me a while cause I'm new to Nix, I got that setup working after a while.

Now I'd like to turn the second part (module, pkg definitions) into a flake, and have some questions about that. Because there's so many open questions, I'll just post them in the order that makes sense to me. Any help/pointers would be greatly appreciated:

• When searching for flakes on github, I only found repos that turn other repos into flakes. Is there a reason to separate the flake part from the code part? Or is this mainly due to people turning other people's applications into flakes?
• What if I want to turn code I maintain into a flake? Should I also use dedicated repos for the application and the flake? Since I already have a flake.nix file for the development shell in my application's repo, at first glance it doesn't make sense to me to have a dedicated repo for the module/pkg functionality because there's a chance the lock files are not in sync so you might be running different code/deps than you're using during development.
• If it's therefore considered a best practice to put the functionality for the devshell and packaging into the same repo, is there some other set of best practices about the layout? On one hand, I don't want to stuff the code repo with nix-specific directories and files; on the other, putting everything into flake.nix might make the code cluttered.
• Last but not least, how do I port the functionality from the {pkgs,module}/app/default.nix files so it can be used as a flake in my configuration.nix? If anyone has a (preferably simple) example repo on github, that would be great.
  Sorry for the lengthy list, but I felt putting all questions out there so people can immediately shoot down stupid questions and point me into the right direction. Thanks!