change derivative to reduce to fix clippy issues

[YJDoc2]

ref #303 (comment)

This changes derivative to educe with the intention of fixing clippy failures.

Unfortunately I had to manually implement a Debug at one place to maintain the formatting as educe does not have equivalent to derivative's transparent option. It seems like we have switched one unmaintained crate to another almost unmaintained crate 🙃 . Atleast educe is more up-to-date and should fix the clippy. I checked few other options, but educe is by far the most compatible with derivative in terms of options.

Also changed CONTRIBUTING to mention opening an issue instead of mailing imsnif , as that seems more appropriate now.

[YJDoc2]

Thanks, I'll push with the Changelog updated when running CIs are finished.

[cyqsimon]

It seems like we have switched one unmaintained crate to another almost unmaintained crate 🙃 .

Yeah. Looking at the repo, the author seems MIA. Maybe derive_more is the way to go after all. Its Debug macro offers transparency and custom formatter, not to mention the way it does it is nicer too, not needing a standalone function. The lack of a customisable Default macro, well I should just quit bitching about it TBH. What matters is it actually has proper maintenance and governance.

So what do you think?

[cyqsimon]

And I'll update the contact info stuff separately from this PR, just to keep things clean.

[YJDoc2]

Maybe derive_more is the way to go after all. Its Debug macro offers transparency and custom formatter, not to mention the way it does it is nicer too, not needing a standalone function.

Sure, I'll probably close this PR and open another one for changing to derive_more.

So what do you think?

I agree with the part that having a properly maintained crate is better, I am wondering if we are implementing the Default macro by ourselves, should we go all the way and implement the Debug as well? We would remove the dependency completely.I;m not sure if that would be much more complex/harder to maintain these manual implementations. WDYT? I'll proceed accordingly.

And I'll update the contact info stuff separately from this PR, just to keep things clean.

Yep, thanks!

[cyqsimon]

I agree with the part that having a properly maintained crate is better, I am wondering if we are implementing the Default macro by ourselves, should we go all the way and implement the Debug as well? We would remove the dependency completely.I;m not sure if that would be much more complex/harder to maintain these manual implementations. WDYT? I'll proceed accordingly.

Let's go with derive_more. Many of its other macros are very useful as well, so I suspect I'll run into a reason to pull it in in the future regardless.

[YJDoc2]

Let's go with derive_more. Many of its other macros are very useful as well, so I suspect I'll run into a reason to pull it in in the future regardless.

ok, makes sense 👍 I'll close this PR and open another one for that soon.