Move TaskResult (and friends) to core FsToolkit.ErrorHandling package

[isaacabraham]

I think the core FsToolkit.ErrorHandling package should include the TaskResult CE etc. by default and use the FSharp.Core task { } block.

[TheAngryByrd]

I listed some hurdles in regards to this in: #142 (comment)

• I was able to address the F# 6.0 concern by creating separate packages for netstandard2.0 and netstandard2.1.
• I didn't want to deal with all the Fable concerns (unless they have shims for task now)

[TheAngryByrd]

use the FSharp.Core task { } block

If you mean by trying to recreate TaskResult in terms of task CE, unfortunately that isn't possible. taskResult (and friends) need their own Resumable Code to work correctly.

[TheAngryByrd]

I may revisit this for 4.0 but closing for now.

[TheAngryByrd]

for v5 of FsToolkit.ErrorHandling i'm removing Ply as a dependency and requiring F# 6 Core as a minimum. Because of that, I'm re-evaluating moving all the task code into the core package.

However I'm concerned with what the migration would look like. How will I be able to prevent someone from having v5 of FsToolkit.ErrorHandling and v4 of FsToolkit.ErrorHandling.TaskResult?

Trying to weight the options because no matter how loud you are in the release notes or social media, someones not gonna read the memo.

[pblasucci]

First off: I am in favor of setting .NET 6 as the minimum target runtime. 🎉

As for collapsing the libraries... I can´t think of a technical way to prevent weird dependency mish-mashes 🙁 But I still think it's a reasonable idea.

[TheAngryByrd]

I am in favor of setting .NET 6 as the minimum target runtime. 🎉

To clarify, that is not what I'm doing (I know this gets confusing). I'm setting the minimum to be F# Core 6 (when tasks were introduced) and still be on netstandard2.0/netstandard2.1. There isn't a compelling reason for this library to move to net6 unless someone really wants PoolingValueTask support.

[pblasucci]

Aaahhh... I see. That's actually more reasonable. 👍

[l3m]

However I'm concerned with what the migration would look like. How will I be able to prevent someone from having v5 of FsToolkit.ErrorHandling and v4 of FsToolkit.ErrorHandling.TaskResult?

Trying to weight the options because no matter how loud you are in the release notes or social media, someones not gonna read the memo.

That true, unfortunately. Despite that, it seems like a good idea and I personally would prefer an integration of TaskResult into the main package.

[siwatanejo]

by default and use the FSharp.Core task { } block.

What's wrong with async{} blocks? They are actually more idiomatic F#.

[mwyrebski]

How will I be able to prevent someone from having v5 of FsToolkit.ErrorHandling and v4 of FsToolkit.ErrorHandling.TaskResult?

There's a way to enforce compatibility with specific versions using version ranges.

In this case, setting a dependency on FsToolkit.ErrorHandling <= 5.0 for the FsToolkit.ErrorHandling.TaskResult would prevent the problem. Ideally, the resulting FsToolkit.ErrorHandling.TaskResult.nuspec should include proper dependencies, like:

<dependency id="FsToolkit.ErrorHandling" version="[4.*, 5.0)" exclude="Build,Analyzers" />

Of course, this version enforcement would need to be included in the next release, as it can't address existing cross-dependencies from earlier versions. It would be most useful having it from first version of new major release, for example [5.0, 6.0).

---

According to the docs, version ranges can be easily defined using PackageReference or manually crafted .nuspec files. However, FsToolkit.ErrorHandling uses ProjectReference(s), which don't support version ranges (yet), as they make dependencies autogenerated with versions determined during dotnet pack.

This appears to be a long-awaited feature, with some clever workarounds suggested in NuGet/Home#5556.
By adding one of them to src/Directory.Build.props and setting the PackageVersion="[~, 5.0)" attribute, I was able to run a build that produced the FsToolkit.ErrorHandling.TaskResult.nuspec file containing:

<dependencies>
  <group targetFramework=".NETStandard2.0">
    <dependency id="FsToolkit.ErrorHandling" version="[4.17.0, 5.0.0)" exclude="Build,Analyzers" />
    <dependency id="Ply" version="0.3.1" exclude="Build,Analyzers" />
  </group>
  <group targetFramework=".NETStandard2.1">
    <dependency id="FsToolkit.ErrorHandling" version="[4.17.0, 5.0.0)" exclude="Build,Analyzers" />
  </group>
</dependencies>