Comments on https://github.com/fsharp/fslang-design/blob/master/RFCs/FS-1034-fsharp-core-package.md#today
- The package is not signed
So sign it?
- The package is now relatively large (68MB on disk unzipped) due to the large number of variations, and may get bigger (E.g. embedded PDBs)
Not an issue, the compiler should do the optimisations needed.
- The package was prepared and pushed in an adhoc way
Set up a CI-environment.
- The package contains some delay-signed DLLs (the Xamarin variations are delay-signed)
Not an issue if you don't build for those platforms, again the compiler is the point where you need suppleness here.
- The package is not pre-installed with tooling (preventing some offline development scenarios)
So either add some version of the package to the tooling, or download it when the tooling initialises. After all, nuget.org is a public source of packages and you'll have your signature on the package.
- The package is not easily buildable from a source-tarball (a requirement in some settings)
Solve by setting up a CI server.
NuGet package already include enough split-points, such as the different target folders inside lib, to let the compiler and infrastructure
and paket make the necessary choices about which DLL to reference.
Don't mess up the eco-system with a package split.
/Henrik, author of Expecto, Logary, Suave, Logibit.Hawk and a large number of other F# libraries.
@cartermp – I understand that a lesser size is better generally, but to me it seems the two different use-cases of building with .Net and running on .Net should be considered – in the case of building with .net, size isn't an issue because 100 MiB isn't, and when running the compiled code not all package contents will be present, so then size isn't an issue either.
The other way I can see forward in the build-on-.net-case is splitting the core package from the compiler and depending on FSharp.Core as-is. That way .Net Core can reference the compiler and bundle it, and all stake-holders are happy.