nix flake check with no-url-literals fails

[lorenzleutgeb]

Background

URL literals are deprecated:

• [RFC 0045] Deprecating unquoted URL syntax NixOS/rfcs#45
• Nix Manual

There was at least one treewide commit in nixpkgs removing URL literals three years ago, which rewrote a URL literal in the definition of the prettytable (Python) package.

I think that ngipkgs should evaluate with no-url-literals.

Problem

Today, I tried:

% git name-rev HEAD
HEAD main
% git rev-parse HEAD
ab5adeaed3c36a91236f99b7ccd41dfaf1cf48ea
% nix flake --allow-import-from-derivation --extra-experimental-features 'no-url-literals' check
error:
       … while checking flake output 'hydraJobs'

         at /nix/store/yfs4vb1xvhx3qlclr36z4mqi1r1qdhvp-source/flake.nix:88:9:

           87|         # See <https://hydra.ngi0.nixos.org/jobset/ngipkgs/main>.
           88|         hydraJobs.packages.${linuxSystem} = self.packages.${linuxSystem};
             |         ^
           89|

       … while checking the Hydra jobset 'hydraJobs'

         at /nix/store/yfs4vb1xvhx3qlclr36z4mqi1r1qdhvp-source/flake.nix:88:9:

           87|         # See <https://hydra.ngi0.nixos.org/jobset/ngipkgs/main>.
           88|         hydraJobs.packages.${linuxSystem} = self.packages.${linuxSystem};
             |         ^
           89|

       (stack trace truncated; use '--show-trace' to show the full trace)

       error: URL literals are disabled

       at /nix/store/87jb2lym32p02bg284nhfxqw3vk37lwi-source/pkgs/development/python-modules/prettytable/default.nix:24:16:

           23|     description = "Simple Python library for easily displaying tabular data in a visually appealing ASCII table format";
           24|     homepage = http://code.google.com/p/prettytable/;
             |                ^
           25|     license = licenses.bsd3;

Note that this is nixpkgs:

% ls /nix/store/87jb2lym32p02bg284nhfxqw3vk37lwi-source
COPYING  default.nix  doc  lib  maintainers  nixos  pkgs  README.md
% ls -1 /nix/store/87jb2lym32p02bg284nhfxqw3vk37lwi-source/**/*.nix | wc -l
14460
% grep 'Nixpkgs is' /nix/store/87jb2lym32p02bg284nhfxqw3vk37lwi-source/README.md
Nixpkgs is a collection of packages for the [Nix](https://nixos.org/nix/) package

I tried to find the reason for this dependency using nix why-depends:

% nix why-depends .#hydraJobs.packages.x86_64-linux.flarum /nix/store/87j…lwi-source
'git+file:///…/ngi-nix/ngipkgs#hydraJobs.packages.x86_64-linux.flarum' does not depend on '/nix/store/87j…lwi-source'
% nix why-depends .#hydraJobs.packages.x86_64-linux.gnunet-messenger-cli /nix/store/87j…lwi-source
'git+file:///…/ngi-nix/ngipkgs#hydraJobs.packages.x86_64-linux.gnunet-messenger-cli' does not depend on '/nix/store/87j…lwi-source'
% nix why-depends .#hydraJobs.packages.x86_64-linux.kikit /nix/store/87j…lwi-source
'git+file:///…/ngi-nix/ngipkgs#hydraJobs.packages.x86_64-linux.kikit' does not depend on '/nix/store/87j…lwi-source'
% nix why-depends .#hydraJobs.packages.x86_64-linux.lcrq /nix/store/87j…lwi-source
'git+file:///…/ngi-nix/ngipkgs#hydraJobs.packages.x86_64-linux.lcrq' does not depend on '/nix/store/87j…lwi-source'
% nix why-depends .#hydraJobs.packages.x86_64-linux.lcsync /nix/store/87j…lwi-source
'git+file:///…/ngi-nix/ngipkgs#hydraJobs.packages.x86_64-linux.lcsync' does not depend on '/nix/store/87j…lwi-source'
% nix why-depends .#hydraJobs.packages.x86_64-linux.liberaforms /nix/store/87j…lwi-source
'git+file:///…/ngi-nix/ngipkgs#hydraJobs.packages.x86_64-linux.liberaforms' does not depend on '/nix/store/87j…lwi-source'
% nix why-depends .#hydraJobs.packages.x86_64-linux.liberaforms-env /nix/store/87j…lwi-source
'git+file:///…/ngi-nix/ngipkgs#hydraJobs.packages.x86_64-linux.liberaforms-env' does not depend on '/nix/store/87j…lwi-source'
% nix why-depends .#hydraJobs.packages.x86_64-linux.libgnunetchat /nix/store/87j…lwi-source
'git+file:///…/ngi-nix/ngipkgs#hydraJobs.packages.x86_64-linux.libgnunetchat' does not depend on '/nix/store/87j…lwi-source'
% nix why-depends .#hydraJobs.packages.x86_64-linux.librecast /nix/store/87j…lwi-source
'git+file:///…/ngi-nix/ngipkgs#hydraJobs.packages.x86_64-linux.librecast' does not depend on '/nix/store/87j…lwi-source'

Since there's also an IFD involved (see also #24), it might well be that the evaluation of the IFD depends on a version of nixpkgs that is old.

Suggestions

• If the IFDs are removed, check whether the problem disappears.
• If IFDs are kept, diagnose further whether they really pull in some old version of nixpkgs. If that's the case, try to have the IFDs follow the flake input.

[cleeyv]

Yes, the use of mach-nix for liberaforms (which is what uses an IDF) depended on an old version of nixpkgs as a workaround to a bug a with mach-nix DavHau/mach-nix#549 which made it incompatible with newer versions of nixpkgs. That is documented here: https://github.com/ngi-nix/ngipkgs/blob/main/pkgs/liberaforms/env.nix#L9-L16 it was from back in June when we set up ngipkgs with liberaforms as the initial test service.

Since then, I see that in early July a new PR was merged for mach-nix DavHau/mach-nix#563 that apparently fixes the incompatibility with newer nixpkgs. Assuming this fix works, then in theory this issue could be resolved by sourcing the import of mach-nix for liberaforms from its master branch (to include the fix) and then removing the old nixpkgs workaround. I tried this here: https://github.com/ngi-nix/ngipkgs/tree/remove-old-nixpkgs but ran into an error that I will document in a new issue.

[cleeyv]

As expected, this seems to have been resolved by #41.

I just ran the check on the main branch of ngipkgs and it completed without an error so I'm going to close the issue:

$ nix flake --extra-experimental-features 'no-url-literals' check
warning: unknown flake output 'nixosTests'

[lorenzleutgeb]

IMO, no-url-literals should be set in the GitHub Actions workflow to catch regressions. At the moment, if someone adds a URL literal, CI will not fail immediately, but only once URL literals are removed from Nix itself. This has not been done, so I do not agree that this issue is resolved. Reopening to invite further discussion.

[mightyiam]

My two cents: not enforced == not resolved

[cleeyv]

Sure, CI enforcement seems like a reasonable addition to this issue. I'll review #44 now.