fsprojects / Paket

A dependency manager for .NET with support for NuGet packages and Git repositories.
https://fsprojects.github.io/Paket/
MIT License
1.99k stars 520 forks source link

Sunset Chessie and Migrate to FsToolkit.ErrorHandling #4250

Open 1eyewonder opened 3 months ago

1eyewonder commented 3 months ago

Summary

Just some Saturday shenanigans I was playing around with. I was looking over the code and wanted to see what the general thoughts were on migrating the error handling tooling over to FsToolkit.ErrorHandling since it is more "modern/maintained" (IMO). I still have more work to do but figured I'd show the idea off. If we think there is some merit behind it, I would be more than happy to continue on with following through with this work 😄 If we don't see value in it, I can always close it and say it was a good exercise for myself 🤷‍♂️

Note

In addition to error handling changes, I have done some minor List filter/map optimizations to reduce number of iterations in certain areas which I thought were straight forward. I can revert these if we find them to be out of scope.

smoothdeveloper commented 3 months ago

I'm wondering if, for sake of this getting reviewed in detail, there isn't a pro in having a compatibility module under the Chessie namespace.

We would still make sure new code is written with FsToolkit.ErrorHandling, and that code we change conforms to it, but for sake of adjusting the dependency, we would focus on minimizing the diff / having the lowest possible impact on the code.

I'm not familiar with either packages, so unable to assess if compatibility module (Chessie API currently used, implemented in terms of FsToolkit.ErrorHandling) would just work.

Such compatibility module could also be used in other projects that want to take similar migration path.

voronoipotato commented 3 months ago

@baronfel I was rubber ducking for @1eyewonder . We were having challenges getting things to resolve for the integration tests. I'm almost wondering if it would be easier to break it out into two assemblies, one for the netstandard integration tests and the netcore integration tests? This might just be a result of my own ignorance though.