Split up FSharp.Data

[dsyme]

@cartermp We've discussed splitting out core packages for Http, Csv etc.

The split in this PR is this:

• FSharp.Data -- everything including type providers
  • FSharp.Data.Http -- http helpers
  • FSharp.Data.Csv.Core -- csv types/helpers
  • FSharp.Data.Json.Core -- json types/helpers
  • FSharp.Data.Html.Core -- html types/helpers
  • FSharp.Data.Xml.Core -- xml types/helpersThis attempts to do that.
  • FSharp.Data.WorldBank.Core -- xml types/helpersThis attempts to do that.

At a later point we may split out the separate type providers to allow you to use just the one you want. However that's not done here - currently if you want a type provider you reference FSharp.Data which implies all the core pacakges too.

Some of the design-time inference logic used by the type providers is in the Core packages, now made internal.

Some of the public IO and pluralization helpers used by the the other components and the type provider inference are in FSharp.Data.Http. These may be moved around or made internal in a future release. There's no "right" place to put these.

[cartermp]

What's the benefit to pulling it out to be a separate dll?

[dsyme]

@cartermp The relevant issue is here: #1311

We can decide on the split we want. To me the following eventually makes sense, as it's reasonable to just want the helpers for a particular data format:

• FSharp.Data -- includes all type provider references
• FSharp.Data.Core -- causes no type provider references
  • FSharp.Data.Http.Core -- causes no type provider references
  • FSharp.Data.Csv.Core -- causes no type provider references
  • FSharp.Data.Json.Core -- causes no type provider references
  • FSharp.Data.Html.Core -- causes no type provider references
  • FSharp.Data.Xml.Core -- causes no type provider references
  • FSharp.Data.WorldBank.Core -- causes no type provider references

What's currently in this PR is this, which is a stepping stone to the above:

• FSharp.Data -- includes type provider references
• FSharp.Data.Core -- causes no type provider references, just the various data formats and helpers

I don't think it's worth splitting the different type providers out as yet - at least it's a lot of work as each also needs a DesignTime thing. But we should probably leave the door open to doing that.

[dsyme]

Maybe a better alternative is this:

• FSharp.Data -- includes everything
  • FSharp.Data.Http -- http helpers
  • FSharp.Data.Csv -- csv types/helpers and CsvProvider
    • FSharp.Data.Csv.Core -- csv types/helpers
  • FSharp.Data.Json -- json types/helpers + JsonProvider
    • FSharp.Data.Json.Core -- json types/helpers
  • FSharp.Data.Html -- html types/helpers + HtmlProvider
    • FSharp.Data.Html.Core -- html types/helpers
  • FSharp.Data.Xml -- xml types/helpers + XmlProvider + XsdProvider
    • FSharp.Data.Xml.Core -- xml types/helpers
  • FSharp.Data.WorldBank -- world bank thing

This is based on the logic that

• The most common thing is "just give me the support for X, including everything"
• Occasionally, people want "just give me the core helpers for X, forget the type provider"

That does mean splitting the specific type provider DesignTime out, it's work though the user doesn't see that.

A stepping stone could be:

• FSharp.Data -- includes everything
  • FSharp.Data.Http -- http helpers
  • FSharp.Data.Csv.Core -- csv types/helpers
  • FSharp.Data.Json.Core -- json types/helpers
  • FSharp.Data.Html.Core -- html types/helpers
  • FSharp.Data.Xml.Core -- xml types/helpers

[pimbrouwers]

Done and done!

[cartermp]

@dsyme makes sense!

[cartermp]

Why is this commented out?

[dsyme]

So I can't work out why having this in fails the package build when there are two packages.

Without it we get FSharp.Data.Core.symbols.nupkg and FSharp.Data.symbols.nupkg correctly built but the file name extensions are different

Do you know if it matters either way?

[dsyme]

From https://docs.microsoft.com/en-us/nuget/create-packages/symbol-packages-snupkg

The legacy format .symbols.nupkg is still supported but only for compatibility reasons like native packages (see Legacy Symbol Packages). NuGet.org's symbol server only accepts the new symbol package format - .snupkg.

[baronfel]

Can you just embed symbols instead of the separate package? That's much less hassle for consumers. Separate packages make Sourcelink hard to use.

[dsyme]

@baronfel Thanks, I've done this now

[baronfel]

Thank you!

[dsyme]

I've updated the PR to split out the core pacakges

[dsyme]

@cartermp @baronfel This is ready (once green, just niggles with doc gen)

[cartermp]

Looks clean to me (pending docs changes)

[dsyme]

This is now merged and released as FSharp.Data 5.0.1