Even broken packages shouldn't be breaking evaluation, I believe.

As far as I am concerned, the source of the problem is the fact that the bot evaluates explicitly broken packages!

I agree with @vcunat. This is the only broken package which doesn't even evaluate. What do you think about @pbogdan's other workaround:

  scalendar = markBroken (super.scalendar.override { SCalendar = null; });
  SCalendar = markBroken (super.SCalendar.override { scalendar = null; });

This isn't just about the package being broken, this is about the package being impossible, which I think deserves special attention.

Update that said, if you think we shouldn't be checking even broken packages to properly eval, we could talk about it?

@peti as mentioned I have revised that change in #33077 (comment). Would you consider that an acceptable solution? I believe that would address your concerns with regards to the usage of standard API's, and keeping our current PR checks working.

Even broken packages shouldn't be breaking evaluation, I believe.

@vcunat, the package is broken because it doesn't evaluate properly. That's the whole point of marking it broken. If it would evaluate, then I would not set meta.broken = true for it.

What do you think about @pbogdan's other workaround:

  scalendar = markBroken (super.scalendar.override { SCalendar = null; });
  SCalendar = markBroken (super.SCalendar.override { scalendar = null; });

@grahamc, yes, this is a much better; I'd be happy with that solution.

If you think we shouldn't be checking even broken packages to properly eval, we could talk about it?

I do think it's odd to check the status of a package that's been explicitly marked as broken and I cannot easily think of a use-case for that. What kind of issue would the bot detect due to this check that would otherwise go unnoticed?

I don't have a strong opinion on this. Use case: I think it's not that unreasonable to put allowBroken = true; into your config and still expect nix-env -qa etc. to work. To me it feels that "hard" evaluation errors (abort, infinite cycle, etc.) should not happen unless you do something very wrong. Throws are "soft" in this sense – they can be caught, they're filtered from nix-env -qa, etc.

@vcunat, the package is broken because it doesn't evaluate properly. That's the whole point of marking it broken. If it would evaluate, then I would not set meta.broken = true for it.

There are other possible motivations, e.g. avoid rebuilds for Hydra (or users) that are very likely to fail anyway (think Zero Hydra Failures), and for documentation of the state.