It might be easier to use self.blaze-markup_0_8_2_0? The same applies to virtually all those overrides that update a package to the latest version. We have the latest version in Nixpkgs, and using those names has the advantage that evaluation will break every time these receive an update, which gives us a nudge to re-evaluate the situation and follow the update (or drop the overrive).

I think that's also automatable to a sufficient extent -- will do!

@peti, I'm trying to replace the src-based override with these "shadow" attributes:

  hspec-core = overrideCabal super.hspec-core_2_4_7 (drv: {
    editedCabalFile = null;
  });

..and I'm getting:

FATAL:  failed to instantiate text-lens:  nix-instantiate packages.nix -A text-lens --argstr compiler ghc841 --show-trace
error: while evaluating the attribute ‘propagatedBuildInputs’ of the derivation ‘text-lens-0.1.1’ at /home/deepfire/src/nixpkgs/pkgs/stdenv/generic/make-derivation.nix:148:11:
while evaluating the attribute ‘propagatedBuildInputs’ of the derivation ‘lens-4.15.4’ at /home/deepfire/src/nixpkgs/pkgs/stdenv/generic/make-derivation.nix:148:11:
while evaluating the attribute ‘buildInputs’ of the derivation ‘base-orphans-0.6’ at /home/deepfire/src/nixpkgs/pkgs/stdenv/generic/make-derivation.nix:148:11:
while evaluating the attribute ‘propagatedBuildInputs’ of the derivation ‘hspec-2.4.7’ at /home/deepfire/src/nixpkgs/pkgs/stdenv/generic/make-derivation.nix:148:11:
while evaluating the attribute ‘buildInputs’ of the derivation ‘hspec-core-2.4.7’ at /home/deepfire/src/nixpkgs/pkgs/stdenv/generic/make-derivation.nix:148:11:
while evaluating the attribute ‘buildInputs’ of the derivation ‘silently-1.2.5’ at /home/deepfire/src/nixpkgs/pkgs/stdenv/generic/make-derivation.nix:148:11:
while evaluating the attribute ‘buildInputs’ of the derivation ‘temporary-1.2.1.1’ at /home/deepfire/src/nixpkgs/pkgs/stdenv/generic/make-derivation.nix:148:11:
while evaluating the attribute ‘buildInputs’ of the derivation ‘base-compat-0.9.3’ at /home/deepfire/src/nixpkgs/pkgs/stdenv/generic/make-derivation.nix:148:11:
infinite recursion encountered, at undefined position

Am I doing something obviously wrong?

My guess is that overrideCabal cannot be used for those shadow attributes for some reason.. although I'm somewhat surprised, given how they are defined (same as normal, non-version-suffixed ones).

For a bit more context -- the construction I'm using is:

ghcOrig.override (oldArgs: {
    overrides = self: super:
    with haskellLib; with self; {
       ...
        hspec-core = overrideCabal super.hspec-core_2_4_7 (drv: {
            editedCabalFile = null;
        });
       ...
    };
}

The hspec packages are tricky because some of their dependencies depend on hspec for testing --- which causes infinite loops. The easiest way to avoid that issue is to disable the check phase of those packages, like I did in https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/haskell-modules/configuration-ghc-8.4.x.nix#L46.

A better albeit more involved solution is to figure out which package is causing the recursion and to pass a dont-check-variant of that particular package to hspec during testing, like we do at https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/haskell-modules/configuration-common.nix#L51-L52. We have those overrides for the default versions, but apparently we don't have them for the latest versions, which makes sense, I guess.

BTW, I'm wondering why you set

editedCabalFile = null;

in your override. That doesn't seem necessary to me?

The editedCabalFile is coming from a pre-auto-trim state of the override set, but after I have promoted the package from github-overridden (where the editedCabalFile negation is necessary) to "hackaged" -- basically intermediate state, that's not intended as a final result.

Investigating now how to deal with the loops -- mainly how many instances of the problem can be dealt with doCheck = false..

Done -- the use of versioned attributes is now automatic.

How will this override be updated when a new release version of free comes out that supersedes this one?

Good question! -- I've added automation to the audit script to catch the override version lagging behind upstream to the update script. I'll update the override set tonight.

So the full answer is -- there are scripts that:

1. automatically generate set trimming proposals, and
2. audit the current override set for various invariants, like:

• Nixpkgs-supplied packages lagging behind the Hackage-based overrides
• Upstreamed-overridden version not lagging behind upstream master, in terms of Cabal version number
• User-overridden version having a PR supplied and the PR not being merged
• User-overridden version having the same Cabal version as upstream master

When I run the audit script and see any warnings, that means actions need to be taken.

OK, if you've automated these things, then that's a pretty good solution. :-) It would be great if you could provide a brief step-by-step write-up of how to run those scripts of yours so that I know how to run them, too.

My only concern them being such a mess, I'm somewhat ashamed to bring them to light -- this is truly a case of exploratory chaos -- in bash..

That said, I'll close my eyes and still do this -- just give me a bit more time..

I've mostly refactored the thing into a tolerable shape.

I guess a small test suite is what remains.

Would it be possible to use fetchGitHub instead of fetchgit? It's a minor optimization, granted, but fetchGitHub downloads a single tarball rather than fetching each file individually and is therefore more efficient.

Sure, I'll do that.

Done.