haskell / haskell/cabal

`allow-newer: latest:PKG` (and `constraint: PKG latest`)

Open
#8,790 0 comments 0 reactions 0 assignees View on GitHub
cabal-install: solver re: allow-newer re: constraint type: discussion
Dominant language
Haskell
Stars
1.7k
Forks
750
Avg merge
4d 3h
Merged PRs (30d)
28

Description

Preparing for new GHCs we often need to test our package with dependencies whose upper bounds have not been bumped yet.

A bare `allow-newer: *:DEPS` is (with e.g. DEPS the GHC-preinstalled packages) often ruins the build, bringing tons of outdated packages into the plan. (E.g. there could be a stone-age version of `foo`, say `foo-0.2`, kept in check by `base < 4.5` that would suddenly be unleashed onto us.)

I would find `allow-newer: latest:DEPS` more useful. It would allow bumping `DEPS` in only the _latest_ available version. E.g. if this was `foo-3.1.4`, then it would enjoy relaxed upper bounds for `DEPS`, but `foo-0.2` would still kept outside of the party.

This is hard to work around, because it is not easy to get the transitive dependencies of a package without having a valid build plan in the first place.

(Along similar lines, I would sometime find a `constraint: DEP latest` useful to demand the latest version of package DEP. This is easier to work around. But maybe this is also easier to implement.)

In anticipation that we might get `allow-newer: latest:...` at some point, I squatted the name `latest` on Hackage so that it does not accidentially get used. (Such a package would conflict with the proposed syntax, as you can e.g. have `allow-newer: mypackage:base`.)

Lifted from:
- https://github.com/haskell-CI/haskell-ci/issues/642#issuecomment-1437507237

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.