Sunset Chessie and Migrate to FsToolkit.ErrorHandling

[1eyewonder]

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]

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.

[baronfel]

This LGTM - replacing a deprecated dependency and aligning with the rest of the ecosystem is a net good.

[voronoipotato]

@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.

[Numpsy]

When I build this branch locally, it seems to build Paket.Core with FSharp.Core 8, then build the integration tests with FSharp.Core 5, and then v5 is the one that ends up in the output directory - and then various tests break because the code built against 8 won't run against 5 (that seems to be the same as some of the CI failures).

Compare that to the current master branch, where FSharp.Core 6 ends up in the integration test output directory.

So, I wonder if the IntegrationTests group needs to force a newer version of FSharp.Core? (maybe that would break the strict dependency on FSharp.Core 5 from version 38 of FSharp.Compiler.Service, but then I think that must already be the case in the master branch?)

[Numpsy]

On a related note, when I try to run the integration tests on the master branch locally they get stuck in a loop with it repeatedly printing

:paket> The process is taking longer than expected.
 :paket> Paket may still find a valid resolution, but this might take a while.
 :paket>   Conflict detected:
 :paket>    - Microsoft.Win32.Registry 4.7 requested package System.Security.AccessControl: >= 4.7
 :paket>    - System.Security.Permissions 6.0.0 requested package System.Security.AccessControl: >= 6.0

and that doesn't happen with this branch, so I wonder if breaking out the update to System.Security.Permissions into a separate PR would be useful to fix that? (I'm guessing that's what's causing the CI builds to timeout, but I'm not certain there)

[1eyewonder]

When I build this branch locally, it seems to build Paket.Core with FSharp.Core 8, then build the integration tests with FSharp.Core 5, and then v5 is the one that ends up in the output directory - and then various tests break because the code built against 8 won't run against 5 (that seems to be the same as some of the CI failures).

Compare that to the current master branch, where FSharp.Core 6 ends up in the integration test output directory.

So, I wonder if the IntegrationTests group needs to force a newer version of FSharp.Core? (maybe that would break the strict dependency on FSharp.Core 5 from version 38 of FSharp.Compiler.Service, but then I think that must already be the case in the master branch?)

Yeah, I was initially locking FSharp.Core into v5 so I didn't break so many things with Fsharp.Compiler.Service, however if we think this is the workaround, I'd have to dig into all the new updates I'd have to make.

[Numpsy]

If it's already the case that it's using FSharp.Core 6 with FSharp.Compiler.Service 38 despite the stated requirement for version 5, what actually breaks when updating it further to v7 or 8?
(I see that the .NET Standard 2,1 build of FsToolkit.ErrorHandling requires FSharp.Core 7, but I don't know much about the version history of the other dependencies here)