regenerate haskell nix file (drops hex dependency)
apply ormolu to a few files
fixup cabal file
add polysemy logger interpretation of Output, fix bug in nixEvalSem bug
* nixEvalSem was accidentally not stripping the output
create test_data and simplify RewriteSpec to use it
move Polysemy interpretation stacks closer to where polysemy methods are made
eventually these will move more top level but for now this keeps it
more contained
update to ghc883, remove raw-strings-qq dep
No functional change; this pulls out all of the changes except the `polysemy`
refactoring from here:
https://github.com/ryantm/nixpkgs-update/pull/172
This will allow us to do development with the newer GHC and cleaned up
dependency stack, start using the `hspec` test suite, vet the `github` library
updates, etc., while we work on porting more of the effects to polysemy and
evaluating how it looks.
Having merged an update to make go packages passthru the `modSha256` [1], we can
now have `nixpkgs-update` inspect it and make updates, just as it now does for
Rust packages as of [2].
As a slight detail, because the attribute is in `passthru` rather than actually
being available in the derivation, we just do the equivalent of
`nix eval -f . <attrPath>.<attr>` rather than going through the `drvAttrs` as before.
This version has been tested successfully with at least one go update [3], but
not thoroughly vetted. That said, it's essentially identical to the Rust
implementation that has been working well for some time now.
[1] https://github.com/NixOS/nixpkgs/pull/82027
[2] https://github.com/ryantm/nixpkgs-update/pull/156
[3] https://github.com/NixOS/nixpkgs/pull/82465
- Put the Rust version rewriter ahead of the quoted urls rewriter, so it shows
up first in the PR description. This is a much more significant/important
update than the homepage quoting, so it should be emphasized first.
- Sorting the export orders
- Now that we capture rewriter args with `args@(..)`, some of these vars are
unused and generating compiler warnings.
- Fix some comments
This commit moves the meat of the standard `src` and `version` update into a
helper function that can be re-used across the regular version updater and the
Rust package updater.
Since I am soon to add it to a third place for updating Golang packages, which
structurally look a lot like Rust updates, I think it makes sense to move this
to a helper function rather than copy it in a third place.
Also adds a newline in front of the section on `Updates Performed` to make the
PR comment prettier.
All in all, no functional changes intended, just cleanups/prep for more features.
These are versioned per-file and should not be updated in-place; see here for details:
https://github.com/NixOS/nixpkgs/pull/81897
This also cleans up some formatting/spelling/consistency on the other log
mesages, but makes no material change there.
No functional change intended, but please review carefully, as this is mostly untested!
Previously:
1. The assertion about having a single sha was at the top-level, and
2. The assertion that the rewrite changed something meaningful (src url version,
output hash) was inlined inside the `version` rewrite rule.
This commit moves the single-sha limitation down into `version`, and moves the
"did we change something meaningful" check out of `version` and into the top-level.
This is a no-op refactoring to prepare for adding other rewrite rules which CAN
process multiple shas, such as update functions for Rust and Go packages. Like
the regular version one, these should still be constrained by the requirement
that they actually make a "real" version bump change, e.g. change the `src` and
`outputHash`.
Particularly as we add more specific rewrite functions, the norm is that most of
them will not generate a diff on a particular update, so the in-between diff
should be mostly the same. This keeps the log clean by just printing the final
diff; since we have msgs for rewrites fired we can still (somewhat) investigate
what did what when things go wrong.
Rather than enumerate all the negative cases and then fall through to a
modification, let's instead specify the 1 case where something needs to be done,
and otherwise do nothing.
The rewriter would do the right thing, but the comment would still show up in
the PR description. This adds a check to the quotedUrls rewriter to handle the
case where the homepage DOES exist and is NOT quoted, but also would not be it
by the text replace, because it inherits it from another file.
The version bump rewrite doesn't really need a message, since that's already in
the PR title; but other rewrites should probably provide some context by linking
to a ticket.
The first of these is the homepage quoting for [1], but I will also want this
for the cargo fetcher rewriter [2].
[1] https://github.com/NixOS/rfcs/pull/45
[2] https://github.com/NixOS/nixpkgs/issues/79975
Previously, the `--dry-run` would still call `hub pull-request`, and would also
refuse to run if there were a similar PR open on GitHub.
This also adds more logging information and prints `git diff` in the log as the
last step in dry runs. Since some rewriters may take a long time to run, it's
useful for interactive development to have status streaming into the logfile as
they process.
