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

Extract Data.Aeson.Compat #30

Open
pbrisbin opened this issue Jun 26, 2023 · 2 comments
Open

Extract Data.Aeson.Compat #30

pbrisbin opened this issue Jun 26, 2023 · 2 comments
Assignees

Comments

@pbrisbin
Copy link
Member

This package contains a module to paper over some aeson-1.x vs 2.x differences. Specifically Key and KeyMap. We've since needed this in many other places, it seems like something that would be useful community-wide.

When we did it originally, we only didn't release it as its own package because one already existing with the name aeson-compat, doing a different thing. That package appears to be gone now, so we can use that name.

@pbrisbin pbrisbin moved this from 👜 To do to 🏇 In progress in Open Source Jul 6, 2023
@pbrisbin pbrisbin self-assigned this Jul 6, 2023
@pbrisbin
Copy link
Member Author

pbrisbin commented Jul 6, 2023

I've started working on this, but I can't decide between two approaches:

  1. Expose Data.Aeson.Compat modules
  2. Expose Data.Aeson modules

With (1) users would need to add our package and import(s). They would have to be sure to use our modules, probably qualified, to avoid having redundant import warnings when aeson-2.x is present and Data.Aeson exposes some of the same types itself. This is less intrusive, but having to dance around a particular kind of imports feels counter to our intent of making it easy to operate with mixed-version aeson dependencies.

With (2) users would need to replace the aeson package and imports with ours. This is better ergonomics, as you can just import and use Data.Aeson{.Key,.KeyMap} normally and it'll Just Work in the presence of aeson-1.x or 2.x. But it would be harder to also use the aeson package at the same time (without, e.g., PackageImports), so if the user needs to do that for whatever reason, are we making it more harder for them than we are making it easier for the common case?

@pbrisbin
Copy link
Member Author

pbrisbin commented Aug 2, 2024

After discussion with @chris-martin, we lean toward Data.Aeson.V2{.Key,.KeyMap}. This makes it explicit that we're offering compatibility for aeson-2-and-back. If/when aeson-3 comes out, we'd create Data.Aeson.V3{...} to support that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: 🏇 In progress
Development

No branches or pull requests

1 participant