Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow text < 1.2.3 #5198

Closed
snoyberg opened this issue Mar 9, 2018 · 11 comments
Closed

Allow text < 1.2.3 #5198

snoyberg opened this issue Mar 9, 2018 · 11 comments

Comments

@snoyberg
Copy link
Collaborator

snoyberg commented Mar 9, 2018

In e945c24, @phadej added a stricter lower bound for the text package. The message says "the versions are bundled with GHC-8.4.1, no need to support older." However, we're still trying to build Stack (and therefore Cabal) on GHC 8.0 and 8.2, and the relevant Stackage build plans are pegged to an older text due to some upper bounds in other packages.

If there's no specific breakage, would it be possible to relax that lower bound?

@23Skidoo
Copy link
Member

23Skidoo commented Mar 9, 2018

Fine with me. @phadej, what do you think?

@phadej
Copy link
Collaborator

phadej commented Mar 9, 2018

@snoyberg isn't it's better for everyone to have one more LTS release for LTS-9 and LTS-10 to include text-1.2.3.0, it was minor bump from 1.2.2.2.

I'd rather ask a counter question, why 1.2.3.0 isn't in LTS-10? it was released on Wed Dec 27 17:48:29 UTC 2017, i.e over two months ago?

@23Skidoo
Copy link
Member

23Skidoo commented Mar 9, 2018

1.2.2.2 -> 1.2.3.0 changelog is mostly bugfixes + one API addition (unsnoc, which we don't use anywhere), so it should be safe to do this. I can also relax this bound in the released version on Hackage.

@23Skidoo
Copy link
Member

23Skidoo commented Mar 9, 2018

1.2.2.2 -> 1.2.3.0 changelog is mostly bugfixes

Though there is haskell/text#197, which is quite serious, so it may indeed make more sense to bump the version of text in LTS-{9,10} instead.

@snoyberg
Copy link
Collaborator Author

The reason is that some packages still have upper bounds preventing 1.2.3. This was recently raised elsewhere:

commercialhaskell/lts-haskell#103

I don't see logic in using upper bounds in a dependency to prevent consumers from receiving an unrelated bug, and I would recommend relaxing the bound regardless.

Thanks for the attention @23Skidoo.

@phadej
Copy link
Collaborator

phadej commented Mar 10, 2018

@snoyberg As you anyway have to extra-dep: Cabal, why couldn't you extra-dep: text too?


As for Stackage LTS snapshot:

Could you disable test-suite for text in LTS, so it itself can be upgraded in a snapshot. As I see from issue,text-all would allows newer text, and hopefully author of sqlite-simple-errors will respond soon as well. We (Hackage Trustees) can also revise the package so snapshot can proceed, as text-1.2.3.0 in Stackage LTS would benefit everyone.

Please implement commercialhaskell/stackage#3347 asap, so such situation won't occur in the future. As I said, text-1.2.3.0 is "old" version already, it should been at least in latest LTS-10

@phadej
Copy link
Collaborator

phadej commented Mar 10, 2018

Addition to previous, the LTS-9.21 https://www.stackage.org/lts-9.21 is released on 2017-12-28, the day after text-1.2.3.0. If the blocker would been noticed then, even LTS-9.22 could had text-1.2.3.0. (EDIT IMHO the changelog is weighty enough to justify new minor LTS release).

@snoyberg
Copy link
Collaborator Author

I really don't feel like debating all of this here. Asking for a relaxed lower bound when the package supports it seemed like a reasonable thing to do. If I'm going to need to justify every decision I'm making elsewhere in order to make such requests, I simply won't bother in the future.

@23Skidoo
Copy link
Member

I've relaxed the dependency on text in Cabal.cabal to >= 1.2.2.2 && < 1.3 on Hackage, but not on master or the 2.2 branch.

@snoyberg Feel free to reopen this issue if you'll need the dependency relaxed again in any post-2.2.0.0 lib:Cabal release.

@snoyberg
Copy link
Collaborator Author

Thanks @23Skidoo!

@hvr
Copy link
Member

hvr commented Mar 11, 2018

The irony isn't lost on me on various levels, including but not limited to that @snoyberg's demands end up requiring a Hackage revision which also cause the package's meta-data to differ from the meta-data that was shipped in the GHC 8.4.1 source tarball; Hackage meta-data revisions saved the day, again. ;-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants