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

difflicious and diffx #26

Closed
ghostbuster91 opened this issue Nov 7, 2022 · 3 comments
Closed

difflicious and diffx #26

ghostbuster91 opened this issue Nov 7, 2022 · 3 comments

Comments

@ghostbuster91
Copy link
Collaborator

Hi,

I tried reaching you out on twitter but the tweet must've got lost among others. I always thought that the way you designed difflicious internals is superior to what I did in diffix, but up until that moment I was able to implement everything I needed in diffx.
Recent bug issue(softwaremill/diffx#418) pointed out some flaws in the diffx that cannot be fully fixed without major rewrite of internals. Of course, I could make that rewrite but that would mean doing basically the same thing what you did in difflicious. I don't really see a point in fixing diffx that way, when there is already a better version of it implemented :) While implementing diffx and later maintaining it was a great journey for me, I think that objectively the best I can do now is to deprecate it and redirect users to your library. However, there are some users of diffx out there and I would like to do it right, and provide a smooth transition for them.

First, I would like to make sure that you are planning to maintain difflicious and you have a capacity to do that. These days my capacity is fairly limited by other projects but I will be happy to help if you need any help.
Second, I am considering writing a scalafix rule to ease the migration. I guess rewriting imports and class names would cover most of the cases. Do you think it is a good idea?
Third, difflicious doesn't support automatic derivation. I understand reasoning behind that decision. I never use auto derivation in my own projects. Still, there are some people that do, and it is a nice feature especially when prototyping/ trying out new things. Would you consider adding it? (maybe it could be done as a separate module?)

@jatcwang
Copy link
Owner

jatcwang commented Nov 7, 2022

Hi @ghostbuster91 thanks for the kind words. Yeah I did not receive any message from you on Twitter..definitely had similar things happen before 🤔

  • I do plan to maintain this lib and still got some big improvements I'm hoping to implement, but time is limited these days and whatever I have I try to push Doobie a little bit closer to 1.0. Help will be much appreciated and I'm more than happy to add you as a maintainer :)
  • I think the lack of auto-derviation will be a blocker for a useful scalafix rule. Happy to make auto-derivation available under a separate import (like Circe) as I have wished for it a few times while debugging legacy tests using classic assertions ;)

@ghostbuster91
Copy link
Collaborator Author

Understood and thank you. I won't have much time before December but after that I can try contributing the auto-derivation. It seems that we have some vague plan of moving forward. So to sum up:

  • add the auto-derivation to difflicious
  • put diffx into maintenance mode
  • scalafix rule for migration from diffx
  • test the migration and see if there is still anything missing that should be added to difflicious
  • final deprecation of diffix and redirection of users to difflicious

Let me know if you think that something is missing or should be done in different order.

@jatcwang
Copy link
Owner

jatcwang commented Nov 8, 2022

Yep sounds good to me thanks!

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

No branches or pull requests

2 participants