search

haskell / aeson

A fast Haskell JSON library
Other
1.26k stars 321 forks source link

Allow `primitive-0.9` #1075

Closed andreasabel closed 1 year ago

andreasabel commented 1 year ago

aeson

rejecting: aeson-2.2.1.0 (conflict: primitive==0.9.0.0, aeson => primitive>=0.8.0.0 && <0.9)

attoparsec-aeson:

rejecting: primitive-0.9.0.0 (conflict: attoparsec-aeson => primitive>=0.8.0.0 && <0.9)

andrewthad commented 1 year ago

Bumping the upper bound on primitive to <0.10 as a hackage metadata revision would be great if someone is able to do that.

phadej commented 1 year ago

To be honest, I'm a bit tired of these "please bump primitive-0.9", "please support GHC-9.8", "please support text-2.1".

I have noticed that the packages / GHC got new major release, especially the GHC one made me already look at a lot of stuff.

Pinging every other day won't make me do things faster. IMO, weekly ping is ok, more often is irritating noise.

andreasabel commented 1 year ago

@phadej, are you also referring to me? I am following your contribution guide at e.g. https://github.com/haskellari/microstache/blob/43cbc1ab80b1d6cff80a16cab470c67184a376fd/CONTRIBUTING.md?plain=1#L4.

phadej commented 1 year ago

@andreasabel No. Having an issue per repository is fine. As the CONTRIBUTING.md mentions, it can be used for tracking, e.g. "blocked on package-foo#123" comments etc (like your Agda issue, I also see what work is blocked - so I may prioritize). I use that feature myself. GitHub UI conveniently renders issue links showing whether they are still open or resolved, it's a nice feature.

But following (frequent) pings are easily just noise. In my case the noise is irritating enough as there are plenty of repositories I maintain. Andrew e.g. doesn't mention why he needs the revision, nor there are any issue-reference.

andrewthad commented 1 year ago

I'll avoid making this kind of comment in the future. Thanks for letting me know.

andreasabel commented 1 year ago

Update: Agda builds on GHC 9.8 now with aeson-2.2.10 and primitive-0.8.0.0, so this issue is not pressing for me now.

ulysses4ever commented 1 year ago

doesn't mention why he needs the revision

Cabal's testsuite (and therefore the whole Cabal's CI) can't support GHC 9.8 without allowing aeson to build with priimitive-0.9 (experiments are done here: https://github.com/haskell/cabal/pull/9330).

phadej commented 1 year ago

@ulysses4ever That is not correct. I tried quickly, and figured out that cabal's test-suite depends on tree-diff, nothunks which haven't been yet upgraded to support GHC-9.8 (nothunks needs to support bytestrring-0.12 and text-2.1). Also Cabal-tests doesn't allow recent optparse-applicative.

With

~/.ghcup/bin/cabal-3.10.1.0 build -w ghc-9.8.1 all --allow-newer=rere:base --allow-newer=tree-diff:base --allow-newer=tree-diff:text --allow-newer=tree-diff:deepseq --allow-newer=nothunks:text --allow-newer=tree-diff:bytestring --allow-newer=Cabal-tests:optparse-applicative --constraint='bytestring installed' --allow-newer=nothunks:bytestring

the build for patch in Cabal 9330 starts to build. No need to relax anything in aeson.

Also Cabal-tests doesn't allow recent base-compat(-batteries) (0.13), base-orphans (0.9), tasty (1.5).

The build-plan for above will use primitive-0.8.0.0 not latest 0.9, but that doesn't prevent having a build plan.

ulysses4ever commented 1 year ago

Thank you, @phadej, I was not able to find this set of constraints on my own. I still think that potentially many people, just like myself, would have an easier time figuring out the migration if aeson allowed primitive-0.9.