Aeson 0.11 migration - Githubissues

bitemyapp / bloodhound

Haskell Elasticsearch client and query DSL

bitemyapp.com

BSD 3-Clause "New" or "Revised" License

424 stars 118 forks source link

Aeson 0.11 migration #109

Closed bitemyapp closed 8 years ago

bitemyapp commented 8 years ago

I think this has the same behavior as 0.9, but this is where they're headed long-term.

Options:

Roll back to 0.9 since the semantics are the same and get in LTS 5. Upgrade to 0.11 with the next LTS.
Update to 0.11 now and then bug the Stackage people into doing LTS 6 with Aeson 0.11.

Opinions? Thoughts?

/cc @MichaelXavier @MHova

MHova commented 8 years ago

Either way works for my particular needs. It would seem like 1 is easier/faster?

bitemyapp commented 8 years ago

@MHova 1 is not easier or faster. 1's only benefit is getting us back into LTS rotation now as opposed to later. It's more work and we lose the nice error messages until 0.11.

MHova commented 8 years ago

Alright then 2 it is!

bitemyapp commented 8 years ago

@MHova well, being compatible with the current Stackage LTS is no small thing. Do you use Stack?

MHova commented 8 years ago

We are making changes to our build infrastructure to make Stack possible, but we're not dependent on it yet. We are still using regular old cabal and Hackage.

afldcr commented 8 years ago

0.11 is probably less work in the long term for y'all, so I would just go with that. 0.9 would be nice, but that too will be outdated soon and hopefully moving forward with the API isn't as painful as moving backward.

mightybyte commented 8 years ago

Since 0.9 and 0.11 are supposed to have the same behavior, could you do a new release with this constraint?

aeson (>= 0.9 && < 0.10) || (>= 0.11 && < 0.12)

It seems like this should get the best of both worlds since 0.10 is marked as deprecated now. If there's some obstacle to doing that, then I vote for just moving to 0.11. It seems like 0.9 people should be able work around it simply by adding a line to extra-deps in their stack.yaml.

mightybyte commented 8 years ago

FWIW I was able to build bloodhound-0.8.0.0 with aeson-0.11.0.0 successfully. You can see the exact state of what I was building here.

https://github.com/vfiles/bloodhound/tree/0.8-stable

bitemyapp commented 8 years ago

@mightybyte I've got a version going for this, currently getting errors about a ToJSON instance for NonEmpty. I need to finish the NonEmpty PR for Aeson before we can move forward.

fizruk commented 8 years ago

@bitemyapp are you planning on a release with a relaxed aeson bounds (like @mightybyte suggested)? I am currently trying to bring bloodhound into my project, but very specific aeson version brings me much trouble.

pavelkogan commented 8 years ago

It would be nice to be able to easily use latest bloodhound with Stackage LTS.

mightybyte commented 8 years ago

It looks like bloodhound-0.11.0.0 uses some features released in aeson-0.11.1. So my guess is that you won't be able to use this version until stackage catches up and uses aeson-0.11.1 or greater. Stackage LTS is always going to be inherently slower to adopt these new things. Other options would be to add the newer version of aeson and bloodhound to extra-deps or just use cabal and let it handle dependency resolution for you.