-
Notifications
You must be signed in to change notification settings - Fork 45
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
aeson dependency #136
Comments
@2mol There are a few options:
It would be worth discussion these points |
I looked at how many transitive dependencies Edit: yeah, we can cross off that option. |
@NorfairKing @2mol I also would like to make This whole orphan instances situation is pretty said. On one hand I want to have light packages that contain only data types (like |
If it helps to add some direction to this discussion, I think we should avoid conditional compilation where possible. A package is easiest to understand, test and tool when it is just a package, and not N packages depending on configuration. I can understand not wanting to depend on How this affects library users: they need to add However, how do we inform end-users when they eventually see |
@chrisdone Thanks for your feedback on this problem! I want to add from my side that things improved a bit since then. Now there's an even better solution than a separate library. Since cabal-3.0 you can use Multiple Public Libraries features to have many independent libraries inside single package. The only example and tutorial of this feature I'm aware of can be found here:
In our projects, we usually specify Migration guide in the CHANGELOG. You can find an example here: I think this is fine because changing dependency is a separate explicit action. It would be nice to use custom type errors here but this doesn't look possible 😞 |
Hi everybody! First of all, this library is really great, and I very much enjoy using it.
I wanted to discuss the dependency on aeson. As far as I can see, the only weight it's pulling, is a
toJSON
instance inPath.Internal
. Since aeson itself has a pretty massive dependency graph, that's a lot of dependency for not a whole lot of feature. I mean, aeson is super nice, but I don't use it in every program.Let me know if there was already a discussion about this, or if there are some obvious good reasons like avoiding orphan instances that counterbalance my desire for faster initial compilation times. The last thing I want to do is nitpick something good. But personally, I would be really happy if my dependency graph could be trimmed of aeson it's dependencies.
The text was updated successfully, but these errors were encountered: