Stackage: cryptonite-0.23

[juhp]

cryptonite-0.23 (Vincent Hanquez @vincenthz) is out of bounds for:

• [x] avers-0.0.17.1 (>=0.21 && < 0.23). Tomas Carnecky @wereHamster. @wereHamster. Used by: library
• [x] servant-auth-cookie-0.5.0.1 (>=0.14 && < 0.23). Al Zohali [e-mail] @zohl. @zohl. Used by: library, test-suite
• [x] tls-1.3.10 (>=0.21 && < 0.23). Vincent Hanquez @vincenthz. @vincenthz. Used by: library, test-suite

[vincenthz]

some * hackage trustee put some * bounds on tls dependencies for no reason in a revision. the original package compiles very well, can stackage ignore revision ?

[snoyberg]

I wish we could opt out of them, they were a terrible idea hoisted on the community against our will for bad technical reasons. Now Stackage is stuck with them, like all other bad decisions that are made upstream of us.

This specific action seems contrary to normal Hackage Trustee policy, but in line with the unofficial policy spelled out in this email: https://gist.github.com/snoyberg/e556b855b023cd04f6fd5e74bb94a52d. I wonder if any other Hackage Trustees will ever weigh in on if this is acceptable trustee behavior.

[vincenthz]

Is there a fundamental reason why we can't opt out or anything to do in this area ?

[alanz]

In the same way that there is a build process for stackage to make sure everything works together, there is one for hackage too.

Both of these are used to point out issues that need to be resolved, to the benefit of the community.

There is nothing malicious about it. Occasionally mistakes get made, and they should be fixed, on whichever side is affected. This is all to the benefit of the greater haskell community.

[snoyberg]

Please explain how the added, clearly unnecessary upper bounds in this case help anyone.

[alanz]

I suspect this case may be an error. But this should not invalidate the process as a whole. I am looking into it.

[snoyberg]

@vincenthz I think I can propose an opt-in field added to the build-constraints.yaml which states that Hackage revisions should be ignored for a package. cabal users and people making custom snapshots will still be affected by the decisions of Hackage Trustees (which apparently we have no input on at all), but at least normal Stackage curation will be insulated from such decisions and "errors."

[snoyberg]

As a side note, it's really tiring constantly having to modify tooling to work around new "features" added upstream that cause nothing but harm.

[juhp]

It might nice if Hackage revisions were at least documented somewhere - like in a github repo.

[alanz]

The revision for tls has been updated. http://hackage.haskell.org/package/tls-1.3.10/revisions/

[snoyberg]

Thanks Alan.

[juhp]

Thanks!

[snoyberg]

I've implemented this new feature, but consider it experimental pending other curator feedback. I'll put up a post with information in the next day.

[juhp]

cryptonite-0.23 (Vincent Hanquez @vincenthz) is out of bounds for:

• [x] avers-0.0.17.1 (>=0.21 && < 0.23). Tomas Carnecky @wereHamster. @wereHamster. Used by: library

[alanz]

See https://hackage.haskell.org/package/avers-0.0.17.1/revisions/

[DanBurton]

I am +1 on stackage builds being able to selectively ignore revisions (or version bounds in general) when they are unhelpful. But we should avoid using this ability and just sort things out with trustees and package owners if at all possible.

Perhaps we should go so far as to say that Nightlies can ignore revisions, but LTS cannot? I do really want to avoid getting into a situation where people try to use a stackage snapshot, only to be blocked because their tooling says that the version constraints are wrong.