cabal2nix icon indicating copy to clipboard operation
cabal2nix copied to clipboard

How to deal with broken packages?

Open peti opened this issue 10 years ago • 4 comments

At the time hackage2nix generates the hackage-packages.nix file, it already knows that certain packages will be broken because their dependency version constraints aren't met. So it sucks that users might try to compile them and fail (possibly after a long build process to compile the inputs) if we could have alerted them of the problem beforehand. The question is how to alert them?

  • We can set meta.broken. This communicates the problem clearly. The drawback is that you cannot override anything from a broken package. :-( Oftentimes it would be possible to fix the build by passing in some other dependency or by adding a jailbreak, etc., but you can't, because stdenv.mkDerivation just won't evaluate if meta.broken is true. So there's no way to override anything.
  • We can let the package compile but add the information in comments and/or in the description / long description.
  • We could put broken packages into a sub-set haskellngPackages.broken.
  • We could add assert statements at the top of the expression to verify the version constraints (https://github.com/NixOS/cabal2nix/issues/129).
  • We could add a jailbreak = true to every such package and hope this fixes things.

peti avatar Jan 13 '15 19:01 peti

IMO the right solution here is to make meta.broken less strict. Overriding a broken package where the override unsets broken should work, if it doesn't that's a nixpkgs bug.

shlevy avatar Jan 14 '15 14:01 shlevy

@shlevy that's because mkDerivation throws, so you don't have a derivation to override... perhaps we have to delay the meta.broken check down to nix. Alternatives?

We might have a _derivationError, which is the unfree+broken+everything that still lets you evaluate the expression, but eventually fails in nix itself instead of throwing in the nix code. Additionally specifying the error message.

That's much like about choosing one of these two flows:

try {
  drv1 throw
} catch in nix {
}

vs

drv1
drv2
...
in nix
if drv1.hasError() { throw }
if drv2.hasError() { throw }

That is, the classical if vs throw dilemma in programming.

lucabrunox avatar Aug 06 '15 13:08 lucabrunox

https://github.com/NixOS/nixpkgs/pull/9305 might do the trick for us.

peti avatar Aug 17 '15 23:08 peti

Glance at stackage conventions for motivation

ghost avatar Feb 19 '17 18:02 ghost