This commit was created by a combination of scripts and tools:
- an ast-grep script to prefix things in meta with `lib.`,
- a modified nixf-diagnose / nixf combination to remove unused `with
lib;`, and
- regular nixfmt.
Co-authored-by: Wolfgang Walther <walther@technowledgy.de>
After final improvements to the official formatter implementation,
this commit now performs the first treewide reformat of Nix files using it.
This is part of the implementation of RFC 166.
Only "inactive" files are reformatted, meaning only files that
aren't being touched by any PR with activity in the past 2 months.
This is to avoid conflicts for PRs that might soon be merged.
Later we can do a full treewide reformat to get the rest,
which should not cause as many conflicts.
A CI check has already been running for some time to ensure that new and
already-formatted files are formatted, so the files being reformatted here
should also stay formatted.
This commit was automatically created and can be verified using
nix-build a08b3a4d19.tar.gz \
--argstr baseRev b32a094368
result/bin/apply-formatting $NIXPKGS_PATH
The nixpkgs-unstable channel's programs.sqlite was used to identify
packages producing exactly one binary, and these automatically added
to their package definitions wherever possible.
Upstream XMonad was using our xmonad patch file for their flake build to
support our nixos module. This would of course break the build upstream
if the version we patched and their master branch diverged. We
[discussed] that it'd make sense to upstream the environment var code.
In the process it seemed sensible to rename the NIX_GHC variable as
well, since it isn't really Nix-specific – it's just a way to set the
GHC binary to execute. This change has been [implemented] upstream in an
unreleased version of xmonad now – meaning we'll be able to drop the
xmonad patch soon!
This also clarifies the situation in nixpkgs a bit: NIX_GHC is easy to
confuse with the environment variable used in the ghcWithPackages
wrapper where it is used to set an alternative prefix for a GHC-wrapper
for applications trying to discover it via e.g. ghc-paths. It is an
implementation detail in this context, as it is in the case of the
xmonad module. Since they are different implementations doing different
things, different names also make sense.
[discussed]: 36d5761b3e
[implemented]: 23f36d7e23
continuation of #109595
pkgconfig was aliased in 2018, however, it remained in
all-packages.nix due to its wide usage. This cleans
up the remaining references to pkgs.pkgsconfig and
moves the entry to aliases.nix.
python3Packages.pkgconfig remained unchanged because
it's the canonical name of the upstream package
on pypi.
This package should only install the xmonad manpage but not GHC's (it
doesn't even install GHC in the path). Installing both manpages makes
this package conflict with the GHC derivation.
Fixes#60914
PR #1366
The previous windowManager.xmonad option only starts xmonad and
doesn't make ghc available. This assumes that the user has GHC with
access to the xmonad package in his PATH when using xmonad.
Xmonad in Nix is now patched to accept the XMONAD_{GHC,XMESSAGE}
environment variables which define the path to either ghc or xmessage.
These are set automatically when using xmonad through
windowManager.xmonad.
My (or specific: @aristidb and my) changes make it possible to use
Xmonad without adding GHC to any profile. This is useful if you want
to add a different GHC to your profile.
This commit introduces some options:
- xmonad.haskellPackages: Controls which Haskell package set & GHC set
is used to (re)build Xmonad
- xmonad.extraPackages: Function returning a list of additional
packages to make available to GHC when rebuilding Xmonad
- xmonad.enableContribExtras: Boolean option to build xmonadContrib
and xmonadExtras.
Signed-off-by: Moritz Ulrich <moritz@tarn-vedra.de>
