Version bounds missing for dependencies
inariksit opened this issue · 6 comments
Someone involved in Hackage said that GF doesn't have correct version bounds for some dependencies. I paste the email here.
[Y]our package does not currently have correct version bounds for some of its dependencies. For instance:
Lines 78 to 90 in 8206143
Packages that are uploaded to Hackage are generally expected to follow the Package Versioning Policy and have version bounds on all dependencies indicating which versions they are known to build with. Here are some links that have more information:
https://hackage.haskell.org/upload#versioning_and_curation
https://pvp.haskell.org/Also, here are a few things to keep in mind when uploading to Hackage that help keep the ecosystem working reliably for everyone:
- Hackage is intended to be a permanent record. Therefore uploads cannot be changed or removed.
- Only upload things that work, are useful to other people, and that you intend to maintain.
- Use
cabal gen-boundsto put PVP-compliant version bounds (lower AND upper) on ALL your unique dependencies so your package will still be buildable years down the road. One important thing to note is that you only need to include version bounds once. For example, if you depend on the same package in your library and your test suite, you only need to put the version bounds for that dependency in one place. This keeps the dependency bounds information DRY.- Package candidates CAN be changed, so use them to test things out and get everything right before you publish permanently to the main index.
Here are a few important resources where you can learn more:
The hackage home page that contains some of the main guidelines for Hackage packages:
https://hackage.haskell.org/Information about package candidates can be found here:
https://hackage.haskell.org/packages/candidates/
Yeah, this is fair enough. It would be nice to clean those up. I guess we can take the lower bounds from the oldest Stackage snapshot (lts-6.35) and the upper bounds from the newest (lts-16.13). But I'm sure there'll be some unexpected complications, there always are when working with this stuff, which is probably they are so loosely defined in our cabal file in the first place.
This also applies to:
src/runtime/haskell/pgf.cabalsrc/runtime/haskell-bind/pgf2.cabal
Solution:
cabal build and cabal gen-bounds with GHC-8.0.2 and GHC-8.10.4 .
Specify version bounds accordingly (union of the gen-bounds outputs for the two GHC versions).
Also, farther widened lower bounds to accommodate stack build with LTS-9.21 (GHC-8.0.2).
And ceased support for GHC 7.10.3 (which required extra GHC options to build).
(Update: looks like CI tests succeeded for this too. Due to "allow-newer".)
For pgf.cabal and pgf2.cabal: placed identical version bounds as in gf.cabal .
Took the liberty to change GF version number to 3.11.0-git in gf.cabal .
On Ubuntu: stack test succeeded for both LTS-9.21 (GHC-8.0.2) and LTS-18.0 (GHC-8.10.4).
On Windows: stack test failed (partially; 18/33 passed/tests) for both LTS-9.21 (GHC-8.0.2) and LTS-18.0 (GHC-8.10.4).
But stack exec gf works™.
(Update: looks like CI tests succeeded on Windows too. The failed tests are probably because I did a naive git clone on Windows, and did not install any GF dependency.)
┌─[20210706-03:03:20] ‡ [jt2@JACOBTAN039FL:~]
└─[0] <> lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 20.04.2 LTS
Release: 20.04
Codename: focal
GHC-8.0.2
┌─[20210706-03:14:20] ‡ [jt2@JACOBTAN039FL:~/repos/gf-core]
└─[0] <git:(master 09d772046✱) > cabal gen-bounds
Resolving dependencies...
The following packages need bounds and here is a suggested starting point.
You can copy and paste this into the build-depends section in your .cabal
file and it should work (with the appropriate removal of commas).
Note that version bounds are a statement that you've successfully built and
tested your package and expect it to work with any of the specified package
versions (PROVIDED that those packages continue to conform with the PVP).
Therefore, the version bounds generated here are the most conservative
based on the versions that you are currently building with. If you know
your package will work with versions outside the ranges generated here,
feel free to widen them.
array >= 0.5.1 && < 0.6,
base >= 4.9.1 && < 4.10,
ghc-prim >= 0.5.0 && < 0.6,
bytestring >= 0.10.8 && < 0.11,
cgi >= 3001.5.0 && < 3001.6,
containers >= 0.5.7 && < 0.6,
exceptions >= 0.10.4 && < 0.11,
mtl >= 2.2.2 && < 2.3,
pretty >= 1.1.3 && < 1.2,
network-uri >= 2.6.4 && < 2.7,
time >= 1.6.0 && < 1.7,
directory >= 1.3.0 && < 1.4,
filepath >= 1.4.1 && < 1.5,
unix >= 2.7.2 && < 2.8,
fail >= 4.9.0 && < 4.10,
haskeline >= 0.7.3 && < 0.8,
terminfo >= 0.4.0 && < 0.5,
httpd-shed >= 0.4.1 && < 0.5,
json >= 0.10 && < 0.11,
parallel >= 3.2.2 && < 3.3,
process >= 1.4.3 && < 1.5,
random >= 1.2.0 && < 1.3,
transformers-compat >= 0.6.6 && < 0.7,
utf8-string >= 1.0.2 && < 1.1,
GHC-8.10.4
┌─[20210706-02:52:08] ‡ [jt2@JACOBTAN039FL:~/repos/gf-core]
└─[0] <git:(master 09d772046✱) > cabal gen-bounds
Resolving dependencies...
The following packages need bounds and here is a suggested starting point.
You can copy and paste this into the build-depends section in your .cabal
file and it should work (with the appropriate removal of commas).
Note that version bounds are a statement that you've successfully built and
tested your package and expect it to work with any of the specified package
versions (PROVIDED that those packages continue to conform with the PVP).
Therefore, the version bounds generated here are the most conservative
based on the versions that you are currently building with. If you know
your package will work with versions outside the ranges generated here,
feel free to widen them.
array >= 0.5.4 && < 0.6,
base >= 4.14.1 && < 4.15,
ghc-prim >= 0.6.1 && < 0.7,
bytestring >= 0.10.12 && < 0.11,
cgi >= 3001.5.0 && < 3001.6,
containers >= 0.6.2 && < 0.7,
exceptions >= 0.10.4 && < 0.11,
mtl >= 2.2.2 && < 2.3,
pretty >= 1.1.3 && < 1.2,
network-uri >= 2.6.4 && < 2.7,
time >= 1.9.3 && < 1.10,
directory >= 1.3.6 && < 1.4,
filepath >= 1.4.2 && < 1.5,
unix >= 2.7.2 && < 2.8,
fail >= 4.9.0 && < 4.10,
haskeline >= 0.8.0 && < 0.9,
process >= 1.6.9 && < 1.7,
terminfo >= 0.4.1 && < 0.5,
httpd-shed >= 0.4.1 && < 0.5,
json >= 0.10 && < 0.11,
parallel >= 3.2.2 && < 3.3,
random >= 1.2.0 && < 1.3,
transformers-compat >= 0.6.6 && < 0.7,
utf8-string >= 1.0.2 && < 1.1,
Stackage LTS 9.21 (GHC 8.0.2)
┌─[20210706-04:24:00] ‡ [jt2@JACOBTAN039FL:~/repos/gf-core]
└─[0] <git:(master 09d772046✱✈) > stack build
Cabal file warning in/home/jt2/repos/gf-core/gf.cabal@2:20: version with tags
Error: While constructing the build plan, the following exceptions were encountered:
In the dependencies for gf-3.11.0:
cgi-3001.3.0.2 from stack configuration does not match >=3001.5.0 && <3001.6 (latest
matching version is 3001.5.0.0)
exceptions-0.8.3 from stack configuration does not match >=0.10.4 && <0.11 (latest matching
version is 0.10.4)
json-0.9.1 from stack configuration does not match >=0.10 && <0.11 (latest matching version
is 0.10)
mtl-2.2.1 from stack configuration does not match >=2.2.2 && <2.3 (latest matching version
is 2.2.2)
network-uri-2.6.1.0 from stack configuration does not match >=2.6.4 && <2.7 (latest matching
version is 2.6.4.1)
parallel-3.2.1.1 from stack configuration does not match >=3.2.2 && <3.3 (latest matching
version is 3.2.2.0)
random-1.1 from stack configuration does not match >=1.2.0 && <1.3 (latest matching version
is 1.2.0)
transformers-compat-0.5.1.4 from stack configuration does not match >=0.6.6 && <0.7 (latest
matching version is 0.6.6)
utf8-string-1.0.1.1 from stack configuration does not match >=1.0.2 && <1.1 (latest matching
version is 1.0.2)
needed since gf is a build target.
Windows, GHC 8.10.4
PS C:\Users\2jtsm\repos\gf-core> cabal gen-bounds
Warning: C:\Users\2jtsm\repos\gf-core\gf.cabal:2:20: version with tags
Warning: C:\Users\2jtsm\repos\gf-core\gf.cabal:4:23: Packages with
'cabal-version: 1.12' or later should specify a specific version of the Cabal
spec of the form 'cabal-version: x.y'. Use 'cabal-version: 1.22'.
Warning: gf.cabal:2:20: version with tags
Warning: gf.cabal:4:23: Packages with 'cabal-version: 1.12' or later should
specify a specific version of the Cabal spec of the form 'cabal-version: x.y'.
Use 'cabal-version: 1.22'.
Resolving dependencies...
The following packages need bounds and here is a suggested starting point.
You can copy and paste this into the build-depends section in your .cabal
file and it should work (with the appropriate removal of commas).
Note that version bounds are a statement that you've successfully built and
tested your package and expect it to work with any of the specified package
versions (PROVIDED that those packages continue to conform with the PVP).
Therefore, the version bounds generated here are the most conservative
based on the versions that you are currently building with. If you know
your package will work with versions outside the ranges generated here,
feel free to widen them.
Win32 >= 2.6.1 && < 2.7,
base >= 4.14.1 && < 4.15,
ghc-prim >= 0.6.1 && < 0.7,
bytestring >= 0.10.12 && < 0.11,
array >= 0.5.4 && < 0.6,
filepath >= 1.4.2 && < 1.5,
cgi >= 3001.5.0 && < 3001.6,
containers >= 0.6.2 && < 0.7,
exceptions >= 0.10.4 && < 0.11,
mtl >= 2.2.2 && < 2.3,
pretty >= 1.1.3 && < 1.2,
network-uri >= 2.6.4 && < 2.7,
time >= 1.9.3 && < 1.10,
directory >= 1.3.6 && < 1.4,
fail >= 4.9.0 && < 4.10,
haskeline >= 0.8.0 && < 0.9,
process >= 1.6.9 && < 1.7,
httpd-shed >= 0.4.1 && < 0.5,
json >= 0.10 && < 0.11,
parallel >= 3.2.2 && < 3.3,
random >= 1.2.0 && < 1.3,
transformers-compat >= 0.6.6 && < 0.7,
utf8-string >= 1.0.2 && < 1.1,
stack test failed on Windows for Stackage LTS 9.21 (GHC 8.0.2)
gf> test (suite: gf-tests)
testsuite\runtime\typecheck\typecheck.gfs: OK
testsuite\runtime\typecheck\implicit-arguments.gfs: OK
testsuite\runtime\typecheck\hard-unification.gfs: OK
testsuite\runtime\parser\parser.gfs: FAIL
testsuite\runtime\paraphrase\lambda.gfs: OK
testsuite\runtime\linearize\linearize.gfs: OK
testsuite\runtime\linearize\brackets.gfs: FAIL
testsuite\runtime\eval\lazy.gfs: OK
testsuite\runtime\eval\eval.gfs: OK
testsuite\compiler\update\ArrityCheck.gfs: FAIL
testsuite\compiler\typecheck\concrete\test_A.gfs: FAIL
testsuite\compiler\typecheck\abstract\test_C.gfs: FAIL
testsuite\compiler\typecheck\abstract\test_B.gfs: FAIL
testsuite\compiler\typecheck\abstract\test_A.gfs: FAIL
testsuite\compiler\typecheck\abstract\non-abstract-terms.gfs: FAIL
testsuite\compiler\typecheck\abstract\LitAbs.gfs: OK
testsuite\compiler\typecheck\abstract\LetInTypesAbs.gfs: OK
testsuite\compiler\typecheck\abstract\LetInDefAbs.gfs: OK
testsuite\compiler\renamer\varpatt.gfs: OK
testsuite\compiler\renamer\funpatt.gfs: FAIL
testsuite\compiler\params\params.gfs: OK
testsuite\compiler\compute\Variants.gfs: OK
testsuite\compiler\compute\Records.gfs: OK
testsuite\compiler\check\strMatch\strMatch.gfs: OK
testsuite\compiler\check\oper-definition\test.gfs: FAIL
testsuite\compiler\check\lins\lins.gfs: OK
testsuite\compiler\check\lincat-types\test.gfs: FAIL
testsuite\compiler\check\cyclic\params\test.gfs: FAIL
testsuite\compiler\check\cyclic\opers\test.gfs: FAIL
testsuite\compiler\check\cyclic\abs-types\test3.gfs: OK
testsuite\compiler\check\cyclic\abs-types\test2.gfs: FAIL
testsuite\compiler\check\cyclic\abs-types\test1.gfs: FAIL
testsuite\compiler\check\abstract-operations\abstract-operations.gfs: OK
18/33 passed/tests
gf-tests.html contains an overview of the failed tests
gf> Test suite gf-tests failed
stack test failed on Windows for Stackage LTS 18.0 (GHC 8.10.4)
gf> test (suite: gf-tests)
testsuite\runtime\typecheck\typecheck.gfs: OK
testsuite\runtime\typecheck\implicit-arguments.gfs: OK
testsuite\runtime\typecheck\hard-unification.gfs: OK
testsuite\runtime\parser\parser.gfs: FAIL
testsuite\runtime\paraphrase\lambda.gfs: OK
testsuite\runtime\linearize\linearize.gfs: OK
testsuite\runtime\linearize\brackets.gfs: FAIL
testsuite\runtime\eval\lazy.gfs: OK
testsuite\runtime\eval\eval.gfs: OK
testsuite\compiler\update\ArrityCheck.gfs: FAIL
testsuite\compiler\typecheck\concrete\test_A.gfs: FAIL
testsuite\compiler\typecheck\abstract\test_C.gfs: FAIL
testsuite\compiler\typecheck\abstract\test_B.gfs: FAIL
testsuite\compiler\typecheck\abstract\test_A.gfs: FAIL
testsuite\compiler\typecheck\abstract\non-abstract-terms.gfs: FAIL
testsuite\compiler\typecheck\abstract\LitAbs.gfs: OK
testsuite\compiler\typecheck\abstract\LetInTypesAbs.gfs: OK
testsuite\compiler\typecheck\abstract\LetInDefAbs.gfs: OK
testsuite\compiler\renamer\varpatt.gfs: OK
testsuite\compiler\renamer\funpatt.gfs: FAIL
testsuite\compiler\params\params.gfs: OK
testsuite\compiler\compute\Variants.gfs: OK
testsuite\compiler\compute\Records.gfs: OK
testsuite\compiler\check\strMatch\strMatch.gfs: OK
testsuite\compiler\check\oper-definition\test.gfs: FAIL
testsuite\compiler\check\lins\lins.gfs: OK
testsuite\compiler\check\lincat-types\test.gfs: FAIL
testsuite\compiler\check\cyclic\params\test.gfs: FAIL
testsuite\compiler\check\cyclic\opers\test.gfs: FAIL
testsuite\compiler\check\cyclic\abs-types\test3.gfs: OK
testsuite\compiler\check\cyclic\abs-types\test2.gfs: FAIL
testsuite\compiler\check\cyclic\abs-types\test1.gfs: FAIL
testsuite\compiler\check\abstract-operations\abstract-operations.gfs: OK
18/33 passed/tests
gf-tests.html contains an overview of the failed tests
gf> Test suite gf-tests failed
johnjcamilleri said:
Yeah, this is fair enough. It would be nice to clean those up. I guess we can take the lower bounds from the oldest Stackage snapshot (lts-6.35) and the upper bounds from the newest (lts-16.13). But I'm sure there'll be some unexpected complications, there always are when working with this stuff, which is probably they are so loosely defined in our cabal file in the first place.
I ended up taking the lower bounds of Stackage LTS-9.21 (GHC-8.0.2).
Assuming we only intend to support (and run CI tests on) GHC-8.0.2 and newer.
Because GHC-7.10.3 has some build issues on newer OSes.
The upper bounds are given by cabal gen-bounds on GHC-8.10.4 .
Doing this is consistent with https://pvp.haskell.org/ .
Just to be clear (because I was also confused), support for GHC < 8 has not been dropped with this change.
I don't quite follow why the version bounds are set so GHC < 8 only works with --allow-newer instead of including the versions that belong to ghc-7.10 in the version bounds?
Now we get this output when trying to compile with older ghc:
WARNING: Ignoring gf's bounds on base (>=4.9.1 && <4.16); using base-4.8.2.0.
Reason: allow-newer enabled.
WARNING: Ignoring gf's bounds on bytestring (>=0.10.8 && <0.11); using bytestring-0.10.6.0.
Reason: allow-newer enabled.
WARNING: Ignoring gf's bounds on containers (>=0.5.7 && <0.7); using containers-0.5.6.2.
Reason: allow-newer enabled.
WARNING: Ignoring gf's bounds on directory (>=1.3.0 && <1.4); using directory-1.2.3.0.
Reason: allow-newer enabled.
WARNING: Ignoring gf's bounds on filepath (>=1.4.1 && <1.5); using filepath-1.4.0.0.
Reason: allow-newer enabled.
WARNING: Ignoring gf's bounds on ghc-prim (>=0.5.0 && <0.7.1); using ghc-prim-0.4.0.0.
Reason: allow-newer enabled.
WARNING: Ignoring gf's bounds on pretty (>=1.1.3 && <1.2); using pretty-1.1.2.0.
Reason: allow-newer enabled.
WARNING: Ignoring gf's bounds on process (>=1.4.3 && <1.7); using process-1.2.3.0.
Reason: allow-newer enabled.
WARNING: Ignoring gf's bounds on time (>=1.6.0 && <1.10); using time-1.5.0.1.
Reason: allow-newer enabled.
WARNING: Ignoring gf's bounds on unix (>=2.7.2 && <2.8); using unix-2.7.1.0.
Reason: allow-newer enabled.