Accept either Nightly or LTS as the solver configuration variable in the
script. The Stackage version is now considered a tuple of solver and
version, allowing the script to handle updates and switches between
solvers gracefully.
Tested updating Nightly and updating from Nightly to LTS.
We have generally shipped the latest cabal-install version. Stackage has
re-added cabal-install recently which caused cabal-install to get
downgraded to 3.4 to match the Cabal version shipped by GHC 9.0.2. This
commit reverts that change.
usage
'./maintainers/scripts/remove-old-aliases.py --year 2018 --file ./pkgs/top-level/aliases.nix'
first the matched lines are converted to throws with the comment
'Converted to throw $CURRENT_DATE'
then the throws older than the passed date are removed.
I find it more practical (can run update.py --github-token=$(pass gihtub-token)" rather than putting token in ENV). Also makes it more discoverable. I introduced a FetchConfig variable to pass editor agnostic configuration.
Before 46c68ad both "@" and " as " could be used in the same line like
the following:
vimwiki/vimwiki@dev as vimwiki-dev
After 46c68ad this gives an error due to the split URI still erroneously
including the " as [name]" at the end, due to splitting from the wrong
variable.
configuration-nix.nix uses builtins.intersectAttrs to not any overrides
for packages not present in `super` (presumably for use outside of
nixpkgs?). To accomodate it, we pass an attribute set with every
attribute of haskellPackages, but set to `null` as `super`, and — while
we're at it — a fix point as `self`.
While being able to test them is neat (on x86_64-linux they work very
well, actually), we usually don't want to do this, since the set is
only (recommended to be) used to bootstrap GHC. Consequently there is
almost no binary cache and testing them mostly leads to unenlightening
and seemingly endless compilation.
The added nix expression allows maintainers to check for regressions in
the configuration overlays employed by haskellPackages and friends. The
reasoning behind this is that, if we add an override for something, it
should also build. To test this fact, we extract all attributes touched
by a configuration and obtain all relevant derivations corresponding to
it which can then be thrown into nix-build --keep-going.
I've been using this expression to verify configuration-ghc-9.2.x.nix
for a week or so which works quite well. The amount of stale overrides
in other configuration makes it a bit more painful for other use cases
at the moment.
The "0.5.0-1" rockspec on luarocks has a bug, resulting in it pulling
the current git master version, which is what we have effectively been
using.
Given that 0.5.0-1 is the latest release, is 6 years old, and that there
have been some bug fixes since then, we do actually want to be using the
git master version, but we also want to be using the correct rockspec
(particularly as alt-getopt has been replaced by argparse in the `moon`
binary).
