Closed chris-martin closed 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)
If I may ask so that I understand, why should the other versions' bounds not be corrected as well?
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.
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?
@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.
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.
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.
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)
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.
@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.
@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".
I recently noticed a compilation failure of
warp-3.3.5
withbase-4.16
. In https://github.com/yesodweb/wai/issues/867 @kazu-yamamoto says thatbase-4.16
ought to be out of bounds for all versions of thewarp
package prior towarp-3.3.18
, but doesn't know how to efficiently perform such a correction in bulk to so many releases. Can the trustees help?