cabal2nix tries to fetch hackage revisions even if already present in the source

[sternenseemann]

Consider the servant-cassava.cabal file: It has a Hackage x-revision field checked in the repository which, interestingly, was never applied on Hackage.

cabal2nix, however, recognizes this and sets the revision and even editedCabalFileSha256 (I have no clue yet where this hash comes from). Arguably, when cabal2nixing a revision of a git repo where the modifications of the revision are checked in, it doesn't make sense to fetch the revision from Hackage (it may even fail as in this case). Fixing this will require careful checking if there are any cases where this would be desireable and, most importantly, how this works exactly in all-cabal-hashes, so we don't regress hackage2nix.

Another question is of course if x-revision entries should even be checked in, but seeing as the have been, maybe not that important. Workaround is of course to overrideCabal { revision = null; editedCabalFileSha256 = null; }.

[Ericson2314]

I don't think the old behavior is ever desirable. When cabal2nix is given source code it shouldn't be doing IO to get other source code, full stop. That just doesn't make sense at all. In general, don't mix IO with business logic like that too.

[sternenseemann]

There is some nuance to it, since there is a difference between being given a cabal file and being given source code. This difference is already present in the fetcher code, so I think we just need to mirror it for the revision logic.