Nix flake support

[yajo]

Is there an existing issue for this?

• [X] I have searched the existing issues

Feature description

Nix is becoming, little by little, the only dependency management tool I'm using. It covers every possible case in the best possible way.

Modern nix is based on flakes, which is currently experimental, but is already quite stable. Read here about them please.

Did you read that? OK.

As you've seen, there are 2 things that could be auto-updated when using flakes:

1️⃣ flake.lock file. Reproduce a single input upgrade with:

git clone https://github.com/copier-org/copier
cd copier
git checkout f722b9acf5d7e21f35d410e015f4ae6f36587e4a
nix flake lock --update-input poetry2nix
git diff

You'll see that command updated only a single input from the flake lock file.

2️⃣ some inputs inside the flake.nix file. Usually flake users refer to the main branch on the input, but they can refer to a tag. If so, it'd be also helpful for dependabot to support those kind of updates.

For example, updating an input like this would result in:

-    devenv.url = "github:cachix/devenv/v0.5";
+    devenv.url = "github:cachix/devenv/v0.6.2";

... together with the corresponding lock file update, which would be done running nix flake lock.

[drupol]

I'm also looking for this feature.

[hschaeidt]

renovate has nix support

https://docs.renovatebot.com/modules/manager/nix/

[drupol]

Renovate doesn't fully support it since it cannot be triggered when the flake.nix file contains custom inputs (not from nix)... so it's totally useless.

Example: https://github.com/loophp/php-src-nix/pull/14

[KiaraGrouwstra]

an alternate approach could be to use nix flake update such as to grab updates within the flake input's specified branch, as suggested at https://github.com/NixOS/nix/issues/9823

[KiaraGrouwstra]

i think the OP's approach seems like a straightforward port of dependabot logic to the nix context, but it feels weird with flakes that way, essentially moving the lock file responsibility from flake.lock to flake.nix, raising questions as to how one might then express flake.nix's present functionality to specify what branch to follow or revision to lock to.

even under an approach based on nix flake update as suggested in the linked thread tho, one might imagine variants doing a general update versus updating single flake inputs at a time. the latter there seems maybe more like how dependabot has functioned so far.

now, a nix flake update approach would move updates from the release level to the commit level, which would be a somewhat dramatic departure from how dependabot has functioned so far, raising questions both about update robustness as well as about a potentially exploding number of automated pull requests.

i imagine dependabot may have settings to curb the last problem.

i feel like i had seen a project to allow flake updates to stick to releases, but i don't really remember.

[KiaraGrouwstra]

reading the renovate module, they:

• artifacts.ts#updateArtifacts: using a github api token, do a nix flake update, optionally just for specified deps, returning the updated lockfile.
• extract.ts#extractPackageFile: given a flake.nix's contents, return its nixpkgs dep.

going over dependabot's instructions for adding a package manager conceptually for nix flakes:

• FileFetcher:

  • Fetches the relevant dependency files for a project (e.g., the Gemfile and Gemfile.lock). See the README for more details.

  • for nix flakes grab flake.nix + flake.lock
• FileParser:

  • Parses a dependency file and extracts a list of dependencies for a project. See the README for more details.

  • for nix flakes, parse JSON file flake.lock, checking attribute root to find the root name, then in nodes.<root>.inputs find an object containing the deps, mapped from user-specified names (key) to their unique name (values) where they are stored in the lock file: nodes.<dep>. the keys are what we wanna return here.
• UpdateChecker:

  • Checks whether a given dependency is up-to-date. See the README for more details.

  • for nix flakes, checking for new versions likely involves a nix flake update operation for the dependency, maybe with --no-write-lock-file
• FileUpdater:

  • Updates a dependency file to use the latest version of a given dependency. See the README for more details.

  • for nix flakes, this would be the actual nix flake update operation for the given dependency
• MetadataFinder:

  • Looks up metadata about a dependency, such as its GitHub URL. See the README for more details.

  • for nix flakes, flake.nix's inputs attribute yields an object with keys indicating the dependencies, and values indicating the requirements. i think nix builds' json output have the URLs in a more usable format, so maybe we could have nix give us those somehow, preferably offline.
• Version:

  • Describes the logic for comparing dependency versions. See the hex Version class for an example.

  • for nix flakes: could we settle for equal vs unequal, or should we really distinguish newer vs older too? the latter seems tougher, maybe it would make sense for any 'different' upstream version to indicate.. newer version available?
• Requirement:

  • Describes the format of a dependency requirement (e.g. >= 1.2.3). See the hex Requirement class for an example.

  • for nix flakes, this would involve flake.nix's inputs attribute, ideally turned into json as above

[JohnRTitor]

Found this issue, would love to have this feature!

[peterbecich]

Can some effort be saved by integrating this GitHub Action with the Dependabot? https://github.com/DeterminateSystems/update-flake-lock

[luisnquin]

I support this

[sebastien]

Support this as well

[noverby]

@JohnRTitor @luisnquin @sebastien You don't have to comment to support this feature. Just with an upvote, you can show support. :) When you comment, you trigger notifications to everyone subscribed to the issue.

[JohnRTitor]

I kind of see your point. But upvoting is very silent on GitHub.

Commenting on an issue sends a notification, and could serve as a reminder for those who wanted to work on it at some point and then forgot.

A long discussion on a GitHub issue itself means the issue is pretty relevant and looking for attention.

[sebastien]

Ok so happy to make a case: Nix usage is increasing, and overall offers a wide coverage that includes not only language-specific packages, but also the underlying native libraries which are often themselves the root cause of vulnerabilities. As a result, supporting Nix lockfiles helps Dependabot better archive its goal of flagging vulnerabilities across a wider range of languages.