search

commercialhaskell / stackage

Stable Haskell package sets: vetted consistent packages from Hackage
https://www.stackage.org/
MIT License
530 stars 805 forks source link

aeson 0.10 #845

Closed bergmark closed 8 years ago

bergmark commented 9 years ago

aeson-0.10.0.0 depended on by:

phadej commented 9 years ago

new revisions of binary-orphans and binary-tagged published

phadej commented 9 years ago

Also, be aware of really breaking change https://github.com/bos/aeson/issues/287

jpvillaisaza commented 9 years ago

twitter-feed is updated in Hackage now.

adinapoli commented 9 years ago

Mandrill 0.4.1.0 is updated & on Hackage now, fixed by: https://github.com/adinapoli/mandrill/pull/22

mgajda commented 9 years ago

json-autotype is fixed too.

On Sunday, September 20, 2015, Alfredo Di Napoli notifications@github.com wrote:

Mandrill 0.4.1.0 is updated & on Hackage now, fixed by: adinapoli/mandrill#22 https://github.com/adinapoli/mandrill/pull/22

— Reply to this email directly or view it on GitHub https://github.com/fpco/stackage/issues/845#issuecomment-141772707.

Pozdrawiam Michał

nomeata commented 9 years ago

Is there actually any point in everyone reporting here that a fix is uploaded? I would presume that the stackage admins would see what’s fixed and what not based on their tool, and use that to check it. At least until there are only two or three packages left which everyone is waiting on, in which case a “I’m finally done message” might be useful.

hadronized commented 9 years ago

smoothie fixed.

nikita-volkov commented 9 years ago

"hasql-postgres" is fixed, but I would love to see the maintainers' input on @nomeata's comment.

snoyberg commented 9 years ago

Is there actually any point in everyone reporting here that a fix is uploaded? I would presume that the stackage admins would see what’s fixed and what not based on their tool, and use that to check it. At least until there are only two or three packages left which everyone is waiting on, in which case a “I’m finally done message” might be useful.

When it's just a few packages: telling us to try again is very helpful. With lots of packages: everyone needs to do the mental checklist of "did everyone else already fix this?" In which case: it's less useful. The curator team will regularly check on open issues and see if they're still relevant, so that seems like the right way to address these big issues.

How's this for a policy: if there are five or more package maintainers pinged in an issue, don't bother writing back.

@bergmark @DanBurton @juhp Any thoughts on that?

mgajda commented 9 years ago

Whatever helps You best Michael! Thanks for making awesome contribution to the commuńity, and making sure that our packages are all together compatibleand up to date.

On Monday, September 21, 2015, Michael Snoyman notifications@github.com wrote:

Is there actually any point in everyone reporting here that a fix is uploaded? I would presume that the stackage admins would see what’s fixed and what not based on their tool, and use that to check it. At least until there are only two or three packages left which everyone is waiting on, in which case a “I’m finally done message” might be useful.

When it's just a few packages: telling us to try again is very helpful. With lots of packages: everyone needs to do the mental checklist of "did everyone else already fix this?" In which case: it's less useful. The curator team will regularly check on open issues and see if they're still relevant, so that seems like the right way to address these big issues.

How's this for a policy: if there are five or more package maintainers pinged in an issue, don't bother writing back.

@bergmark https://github.com/bergmark @DanBurton https://github.com/DanBurton @juhp https://github.com/juhp Any thoughts on that?

— Reply to this email directly or view it on GitHub https://github.com/fpco/stackage/issues/845#issuecomment-141868023.

Pozdrawiam Michał

bergmark commented 9 years ago

:+1:

gregwebs commented 9 years ago

Due to the breaking change that got released mentioned by @phadej, I would recommend that nobody use aeson 0.10 for now. There is already a pull request to attempt to fix this situation: https://github.com/bos/aeson/pull/288

bitemyapp commented 9 years ago

@gregwebs yeah I've been holding out to see how that clears up.

erratic-pattern commented 9 years ago

For webdriver, my solution was to simply add a new operator to Test.WebDriver.JSON and use it in place of .:?

(.:??) :: FromJSON a => Object -> Text -> Parser (Maybe a)
o .:?? k = fmap join (o .:? k)

I believe this should have the same result regardless of which aeson version you use.

mgajda commented 9 years ago

I used Adam's solution in json-autotype too, and it passed all unit tests without issues.

On Monday, 28 September 2015, Adam Curtis notifications@github.com wrote:

For webdriver, my solution was to simply add a new operator to Test.WebDriver.JSON and use it in place of .:?

(.:??) :: FromJSON a => Object -> Text -> Parser (Maybe a) o .:?? k = fmap join (o .:? k)

Pozdrawiam Michał

phadej commented 9 years ago

I was a bit impatient so I made Data.Aeson.Compat

bitemyapp commented 9 years ago

Fixed in http://hackage.haskell.org/package/bloodhound-0.9.0.0 but I had to bring the lower-bound up to 0.10.

Current LTS Aeson is 0.8.0.2, let me know if this'll be a problem.

bergmark commented 8 years ago

Update:

aeson-0.10.0.0 depended on by:

postgresql-binary-0.7.4.1 depended on by:

YoEight commented 8 years ago

Fixed eventstore https://hackage.haskell.org/package/eventstore-0.9.1.2

borsboom commented 8 years ago

I've bumped stack's upper bound for aeson on Hackage (after checking that all tests still pass).

nikita-volkov commented 8 years ago

The package "hasql-postgres" has been deprecated, can you exclude it please?

mgajda commented 8 years ago

Hi Nikita, Since the packages are usually included by either maintainer or dependency to other package, it will probably happen when the respective person submits a pull request to GitHub.

On Wednesday, 16 December 2015, Nikita Volkov notifications@github.com wrote:

The package "hasql-postgres" has been deprecated, can you exclude it please?

— Reply to this email directly or view it on GitHub https://github.com/fpco/stackage/issues/845#issuecomment-165033054.

Pozdrawiam Michał

phadej commented 8 years ago

@mgajda the hasql-postgres is under nikita's name. Made a PR. https://github.com/fpco/stackage/pull/1044

bergmark commented 8 years ago

This is blocking at least bloodhound from being upgraded.

bergmark commented 8 years ago

We decided to start the new year and the upcoming LTS 4 with a clean slate. We'll be disabling most packages that block upgrades. Please send a pull request to re-enable your package if you update it. If you do so before new years you'll be included in LTS 4.

gregwebs commented 8 years ago

I fixed this by using aeson-extra which provides a stable interface

bitemyapp commented 8 years ago

@bergmark okay, so this means Bloodhound is disabled then? I asked you if I should restore compatibility with Aeson <0.10 - some notice on this decision would've been appreciated.

In the meantime: @gregwebs - can I use aeson-extra to avoid CPP here?

bergmark commented 8 years ago

@bitemyapp no sir! the latest version of bloodhound will be included in the next nightly.

bitemyapp commented 8 years ago

@bergmark so the libraries that don't support Aeson 0.10 are the ones getting dropped? Sorry for being a bit slow, I'm still catching up on my coffee for the day at 1849.

bergmark commented 8 years ago

@bitemyapp that's correct, we're trying to make sure as much as possible is the latest and greatest before releasing LTS 4.

bitemyapp commented 8 years ago

@bergmark I understand now - thank you. Seems the right idea to me. The Aeson 0.10 upgrade for Bloodhound was a titch traumatic. Users seem fine but I wish I'd maintained cross-lacuna compatibility.

gregwebs commented 8 years ago

Yep, the CPP is already in aeson-extra

bitemyapp commented 8 years ago

@gregwebs well the Stackage goats have already been sacrificed so I'm holding off unless a user of the library speaks up and wants it. Thank you very much for writing it!

bergmark commented 8 years ago

Here's another package that was already disabled (for other reasons that have been resolved now)

aeson-0.10.0.0 depended on by:

brendanhay commented 8 years ago

New pagerduty release with relaxed upper bound also dependent upon bos/aeson#293.

bergmark commented 8 years ago

Thanks for letting us know!

I asked for a patch release here: https://github.com/bos/aeson/issues/328

tolysz commented 8 years ago

There is a mistake in handling cases for Maybe in aeson I wonder why no one noticed it :); therefore there is no breaking changes https://github.com/bos/aeson/pull/326 please do not create -extra packages to fix them.

tmcgilchrist commented 8 years ago

Fixed riak https://hackage.haskell.org/package/riak-0.9.1.0

juhp commented 8 years ago

I am afraid I will have to disable riak again:

vector-0.11.0.0 depended on by:

codedmart commented 8 years ago

@bergmark Released new rethinkdb-2.2.0.2 with aeson 0.10 support.

fizruk commented 8 years ago

Released new swagger2-1.0 with aeson-0.10.0.0 support. Corresponding PR — #1066.

tmcgilchrist commented 8 years ago

If we bump that dependency is there anything else that's a problem?

We have a build setup against stack nightly (nightly-2015-12-20) is there something else I can point to to check proactively whether we've got an issue?

On Mon, Dec 21, 2015 at 3:38 PM, Jens Petersen notifications@github.com wrote:

I am afraid I will have to disable riak again:

vector-0.11.0.0 depended on by:

— Reply to this email directly or view it on GitHub https://github.com/fpco/stackage/issues/845#issuecomment-166201604.

fizruk commented 8 years ago

@tmcgilchrist I am not sure what you're asking. You can check the Travis build for v1.0. The only problem I had with aeson-0.10.0.0 was a couple of bugs fixed in HEAD but not released (e.g. bos/aeson#293 and the misplaced MINIMAL pragma). To fix compatibility with aeson-0.10.0.0 I just replaced TH with Generic-based code.

bergmark commented 8 years ago

@tmcgilchrist Do you mean if there are other dependencies you might need to bump? If you can build against the latest nightly and cabal sandbox init && cabal install --dry-run | grep latest doesn't give any results you should be good. Possibly also pass --enable-tests --enable-benchmarks if you have those

tolysz commented 8 years ago

Whenever your code handle Maybe via Value type it will be broken in aeson saying that there is a patch for that. So Basically if you use .:? or anything Value -> Maybe a there will be issues as current version is not working correctly there. So if you have Maybe in your type there is no way to write correct fromJson.

tmcgilchrist commented 8 years ago

@bergmark Yes that's what I meant. Thanks.

New version of riak up on package 0.9.1.1. @juhp

juhp commented 8 years ago

@tmcgilchrist okay thanks - looks good now

freizl commented 8 years ago

houath is bump to 0.5.0 in order to work with aeson-0.10

jgm commented 8 years ago

In my opinion, it was premature to add aeson 0.10 to stackage. The problem noted in bos/aeson#296 essentially makes it impossible to compile pandoc-types on a machine with 2 GB RAM or less. Once pandoc enters lts-4.0, many people are going to find that stack install pandoc simply dies with an unexplained "ExitFailure 127."

As long as aeson 0.10 is in stackage, I'm faced with the choice between putting an upper bound on aeson in pandoc-types, thus excluding the pandoc ecosystem from stackage, or having many users complain that they are unable to install pandoc. (Yes, I know there are workarounds; you can specify a constraint on aeson; but most people aren't going to know that, and there's no way to figure out that that's what is needed.)

See my comment on haskell reddit.

DanBurton commented 8 years ago

@jgm the problem is with the generics-based default implementation, right? As an implementation workaround, how about using Data.Aeson.TH instead?