Why do we even keep the package-list-with-aliases task? I assumed we'd just drop it.

Why do we even keep the package-list-with-aliases task? I assumed we'd just drop it.

I believe the whole reason #594 was closed rather than merged to begin with is because then aliases.nix would not longer be checked for errors (see #594 (comment))

Should we just merge it with the check right above it to only check that the package list with aliases.nix evaluates fine? Or is there value is checking the JSON package list both with and without aliases?

Ah, I see. Checking that does make sense.

Why do we even keep the package-list-with-aliases task? I assumed we'd just drop it.

I believe the whole reason #594 was closed rather than merged to begin with is because then aliases.nix would not longer be checked for errors (see #594 (comment))

Should we just merge it with the check right above it to only check that the package list with aliases.nix evaluates fine? Or is there value is checking the JSON package list both with and without aliases?

Let's keep it as-is for now.

I like this much better than #643 (provided it works... 🤞). I'll make some time to get this deployed tomorrow.

Thanks for the PR!

I like this much better than #643 (provided it works... 🤞).

I did attempt to test it locally and while I could confirm that the with-aliases check works, I apparently don't have enough memory (32G ram + 16G swap!) to fully eval outpaths.nix

But I did manage to get it to eval far enough to fail one of the problematic alias PRs that ofborg missed, so it does look like it should be good. Thank you!

I'll close the other PR and mark this one ready-for-review since I've done a little testing now and this one seems to be more acceptable

Yes, these things can eat a lot, as I warned. See e.g. NixOS/nixpkgs#227945

Alright, testing this out dirtily, and if it holds well for the next ~hour, I'll merge this and make it stick. Thanks!

Seems to work great. Thanks!