haskell-infra / hackage-trustees

Issue tracker for Hackage maintainance and trustee operations
https://hackage.haskell.org/packages/trustees/
42 stars 7 forks source link

base bounds for 'warp' need adjusting #329

Closed chris-martin closed 2 years ago

chris-martin commented 2 years ago

I recently noticed a compilation failure of warp-3.3.5 with base-4.16. In https://github.com/yesodweb/wai/issues/867 @kazu-yamamoto says that base-4.16 ought to be out of bounds for all versions of the warp package prior to warp-3.3.18, but doesn't know how to efficiently perform such a correction in bulk to so many releases. Can the trustees help?

sjakobi commented 2 years ago

I have created revisions for warp-3.3.0 to warp-3.3.5, e.g. https://hackage.haskell.org/package/warp-3.3.0/revisions/.

I didn't find build plans with GHC 9.2.1 for any other version of warp:

$ trustee get warp
$ trustee --ghcs '== 9.2.1' matrix *
               9.2.1
warp-3.3.18    NO-IP
warp-3.3.17    NO-IP
warp-3.3.16    NO-IP
warp-3.3.15    NO-IP
warp-3.3.14    NO-IP
warp-3.3.13    NO-IP
warp-3.3.12    NO-IP
warp-3.3.11    NO-IP
warp-3.3.10    NO-IP
warp-3.3.9     NO-IP
warp-3.3.8     NO-IP
warp-3.3.7     NO-IP
warp-3.3.6     NO-IP
warp-3.3.5     FAIL 
warp-3.3.4     FAIL 
warp-3.3.3     FAIL 
warp-3.3.2     FAIL 
warp-3.3.1     FAIL 
warp-3.3.0     FAIL 
warp-3.2.28    NO-IP
warp-3.2.27    NO-IP
warp-3.2.26    NO-IP
warp-3.2.25    NO-IP
warp-3.2.24    NO-IP
warp-3.2.23    NO-IP
warp-3.2.22    NO-IP
warp-3.2.21    NO-IP
warp-3.2.20    NO-IP
warp-3.2.19    NO-IP
warp-3.2.18.2  NO-IP
warp-3.2.18.1  NO-IP
warp-3.2.18    NO-IP
warp-3.2.17    NO-IP
warp-3.2.16    NO-IP
warp-3.2.15    NO-IP
warp-3.2.13    NO-IP
warp-3.2.12    NO-IP
warp-3.2.11.2  NO-IP
warp-3.2.11.1  NO-IP
warp-3.2.11    NO-IP
warp-3.2.10    NO-IP
warp-3.2.9     NO-IP
warp-3.2.8     NO-IP
warp-3.2.7     NO-IP
warp-3.2.6     NO-IP
warp-3.2.5     NO-IP
warp-3.2.4     NO-IP
warp-3.2.3     NO-IP
warp-3.2.2     NO-IP
warp-3.2.1     NO-IP
warp-3.2.0     NO-IP
warp-3.1.12    NO-IP
warp-3.1.11    NO-IP
warp-3.1.10    NO-IP
warp-3.1.9     NO-IP
warp-3.1.8     NO-IP
warp-3.1.7     NO-IP
warp-3.1.6     NO-IP
warp-3.1.5     NO-IP
warp-3.1.4     NO-IP
warp-3.1.3.1   NO-IP
warp-3.1.3     NO-IP
warp-3.1.2     NO-IP
warp-3.1.1     NO-IP
warp-3.1.0     NO-IP
warp-3.0.13.1  NO-IP
warp-3.0.13    NO-IP
warp-3.0.12.1  NO-IP
warp-3.0.12    NO-IP
warp-3.0.11    NO-IP
warp-3.0.10.1  NO-IP
warp-3.0.10    NO-IP
warp-3.0.9.3   NO-IP
warp-3.0.9.2   NO-IP
warp-3.0.9.1   NO-IP
warp-3.0.9     NO-IP
warp-3.0.8     NO-IP
warp-3.0.7     NO-IP
warp-3.0.6     NO-IP
warp-3.0.5.2   NO-IP
warp-3.0.5.1   NO-IP
warp-3.0.5     NO-IP
warp-3.0.4.1   NO-IP
warp-3.0.4     NO-IP
warp-3.0.3     NO-IP
warp-3.0.2.3   NO-IP
warp-3.0.2.2   NO-IP
warp-3.0.2.1   NO-IP
warp-3.0.2     NO-IP
warp-3.0.1.1   NO-IP
warp-3.0.1     NO-IP
warp-3.0.0.8   NO-IP
warp-3.0.0.7   NO-IP
warp-3.0.0.6   NO-IP
warp-3.0.0.5   NO-IP
warp-3.0.0.4   NO-IP
warp-3.0.0.3   NO-IP
warp-3.0.0.2   NO-IP
warp-3.0.0.1   NO-IP
warp-3.0.0     NO-IP
warp-2.1.5.2   NO-IP
warp-2.1.5.1   NO-IP
warp-2.1.5     NO-IP
warp-2.1.4.1   NO-IP
warp-2.1.4     NO-IP
warp-2.1.3.3   NO-IP
warp-2.1.3.2   NO-IP
warp-2.1.3.1   NO-IP
warp-2.1.3     NO-IP
warp-2.1.2.1   NO-IP
warp-2.1.2     NO-IP
warp-2.1.1.2   NO-IP
warp-2.1.1.1   NO-IP
warp-2.1.1     NO-IP
warp-2.1.0     NO-IP
warp-2.0.3.4   NO-IP
warp-2.0.3.3   NO-IP
warp-2.0.3.2   NO-IP
warp-2.0.3.1   NO-IP
warp-2.0.3     NO-IP
warp-2.0.2.1   NO-IP
warp-2.0.2     NO-IP
warp-2.0.1     NO-IP
warp-2.0.0.1   NO-IP
warp-2.0.0     NO-IP
warp-1.3.10.2  NO-IP
warp-1.3.10.1  NO-IP
warp-1.3.10    NO-IP
warp-1.3.9.2   NO-IP
warp-1.3.9.1   NO-IP
warp-1.3.9     NO-IP
warp-1.3.8.4   NO-IP
warp-1.3.8.3   NO-IP
warp-1.3.8.2   NO-IP
warp-1.3.8.1   NO-IP
warp-1.3.8     NO-IP
warp-1.3.7.5   NO-IP
warp-1.3.7.4   NO-IP
warp-1.3.7.3   NO-IP
warp-1.3.7.2   NO-IP
warp-1.3.7.1   NO-IP
warp-1.3.7     NO-IP
warp-1.3.6     NO-IP
warp-1.3.5.1   NO-IP
warp-1.3.5     NO-IP
warp-1.3.4.4   NO-IP
warp-1.3.4.3   NO-IP
warp-1.3.4.2   NO-IP
warp-1.3.4.1   NO-IP
warp-1.3.4     NO-IP
warp-1.3.3.3   NO-IP
warp-1.3.3.2   NO-IP
warp-1.3.3.1   NO-IP
warp-1.3.3     NO-IP
warp-1.3.2     NO-IP
warp-1.3.1.2   NO-IP
warp-1.3.1.1   NO-IP
warp-1.3.1     NO-IP
warp-1.3.0.1   NO-IP
warp-1.3.0     NO-IP
warp-1.2.2     NO-IP
warp-1.2.1.1   NO-IP
warp-1.2.1     NO-IP
warp-1.2.0.2   NO-IP
warp-1.2.0.1   NO-IP
warp-1.2.0     NO-IP
warp-1.1.0.1   NO-IP
warp-1.1.0     NO-IP
warp-1.0.0.1   NO-IP
warp-1.0.0     NO-IP
warp-0.4.6.3   NO-IP
warp-0.4.6.2   NO-IP
warp-0.4.6.1   NO-IP
warp-0.4.6     NO-IP
warp-0.4.5     NO-IP
warp-0.4.4     NO-IP
warp-0.4.3.1   NO-IP
warp-0.4.3     NO-IP
warp-0.4.2     NO-IP
warp-0.4.1.2   NO-IP
warp-0.4.1.1   NO-IP
warp-0.4.1     NO-IP
warp-0.4.0.1   NO-IP
warp-0.4.0     NO-IP
warp-0.3.3     NO-IP
warp-0.3.2.3   NO-IP
warp-0.3.2.2   NO-IP
warp-0.3.2.1   NO-IP
warp-0.3.2     NO-IP
warp-0.3.1     NO-IP
warp-0.3.0     NO-IP

(CC @kazu-yamamoto)

chris-martin commented 2 years ago

If I may ask so that I understand, why should the other versions' bounds not be corrected as well?

sjakobi commented 2 years ago

Right now I simply don't have evidence that more versions actually require revisions. Feel free to reopen this issue if you can provide such evidence, e.g. when new dependency releases enable new bad build plans.

chris-martin commented 2 years ago

Does it not matter that a maintainer of the package has told us that they do not want to support this base version, and they just need help entering this information into Hackage?

gbaz commented 2 years ago

@chris-martin I think the point is that the revisions are unnecessary -- even without them, the solver will never be able to create an install plan with those versions, and so those versions are already "ruled out" even without further revisions.

chris-martin commented 2 years ago

Bound information does not exist only for the solver, though? For example, it is displayed on the Hackage website -- Presumably this is for the benefit of people who read these web pages. I read it often to get a sense of what version ranges other package authors are choosing to support, and to get a rough sense of what versions of things particular dependencies are constraining me to.

phadej commented 2 years ago

and they just need help entering this information into Hackage?

“If you give a man a fish, you feed him for a day. If you teach a man to fish, you feed him for a lifetime.”

If the information on how to make (bulk?) revisions is lacking, maybe someone should rather improve that. Write a blog post, explain why do so to begin with.


https://github.com/haskell-infra/hackage-trustees/blob/master/policy.md#1-metadata-only-changes-tightening-constraints says (emphasis mine)

The trustees' view is that tightening constraints is very useful, and is pretty safe and obvious. It is safe in the sense that it does not make possible any configurations that were not previously possible. It's pretty obvious when it needs to be done because there is concrete evidence that certain combinations of versions do not in fact compile.

In this case there is no concrete evidence. There are no install plan, but that is not a compilation failure. The world is open and an install plan may emerge (unluckily, but could happen; or if someone could do allow-newer/older on other packages then warp itself).


Given how much unreachable lower bounds there are on Hackage, i'd suggest to not set any precedent of doing "cosmetic" revisions. They aren't strictly required.

andreasabel commented 2 years ago

the information on how to make (bulk?) revisions

Btw, @phadej, do we have a tool that does this? hackage-cli add-bound seems to only work on a local .cabal file. I imagine a tool which allows to:

(In general, a transactional mode for hackage revisions would be nice.)

(off topic)

kazu-yamamoto commented 2 years ago

I cannot build hackage-cli even with GHC 8.6 on Monterey due to libiconv of MacPorts. hackage-cli should be improved as it can be built with newer GHCs.

phadej commented 2 years ago

@andreasabel IIRC you are a maintainer of hackage-cli:

% hackage-cli pull-cabal --help     
Usage: hackage-cli pull-cabal PKGNAME [--incr-rev] [--force]
                              [VERSION-CONSTRAINT]
  download .cabal files for a package

Available options:
  -h,--help                Show this help text
  --incr-rev               increment x-revision field
  --force                  force overwriting existing files

Also add-bound and push-cabal works with multiple files at once. The push doesn't produce single "transaction", but I'm not sure it's necessary. index file "supports" single revision transactions only anyway.

It's all there? But this discussion is indeed off-topic, so I won't engage further here. Possible issues with hackage-cli should be discussed there. It's not a tool maintained by trustees as a group.

andreasabel commented 2 years ago

@chris-martin wrote:

Bound information does not exist only for the solver, though? For example, it is displayed on the Hackage website -- Presumably this is for the benefit of people who read these web pages. I read it often to get a sense of what version ranges other package authors are choosing to support, and to get a rough sense of what versions of things particular dependencies are constraining me to.

I can easily replace base < 5 by base < 4.16 for all versions of warp that still say base < 5. Should I go ahead and do this? (I have the revisions on my machine, just need to press the push button.)

Note that for most versions of warp, this will still be a imprecise upper bound; yet a better approximation than < 5. However, folks might read < 4.16 as a promise that everything is fine up to base-4.15 while < 5 is usually understood as "I didn't care to give an upper bound".