FSharp.Core.md

Comments on https://github.com/fsharp/fslang-design/blob/master/RFCs/FS-1034-fsharp-core-package.md#today

Supposed reasons for split

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

Conclusion

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.

Not an issue, the compiler should do the optimisations needed.

It's not the compiler. Adding 100MB to the on-disk install size of the .NET SDK is a big deal.

Don't mess up the eco-system with a package split.

As explained in the RFC, the aim is to make it possible to depend on the smaller package, or the larger package (with a transitive reference to the smaller package), depending on your needs. There is an open question as to whether this works correctly for all package consumers.

So sign it?

Yes, that is a possible step. That would require it becoming a Microsoft-published package, since the F# Core Engineering group don't provide signed packages.

Expecto, Logary, Suave, Logibit.Hawk and a large number of other F# libraries

Thanks, I will add links to a set of libraries to the RFC to use as examples of package-based dependency chains.

It's not the compiler. Adding 100MB to the on-disk install size of the .NET SDK is a big deal.

Well, it's not for me, but YMMV. Why is it a big deal? Do you have a real use-case of someone having problems with the size of the nuget?

As explained in the RFC, the aim is to make it possible to depend on the smaller package, or the larger package (with a transitive reference to the smaller package), depending on your needs. There is an open question as to whether this works correctly for all package consumers.

I understand the rationale, but isn't this the same argument that was made to split sigdata from the DLL? Needlessly and painfully?

Yes, that is a possible step. That would require it becoming a Microsoft-published package, since the F# Core Engineering group don't provide signed packages.

Actually it doesn't require that. You can set up an encrypted sign key with e.g. AppVeyor or Travis, to avoid the problem of not getting it signed? That way Microsoft doesn't have to share the key, but it doesn't have to be Microsoft-published.

Also, the upside of this is that with a proper CI environment we can start talking about reproducible builds for F# core, which would be more of a security assurance than the ownership of the signing key.

Do you have a real use-case of someone having problems with the size of the nuget?

Yes, my understanding is that 100MB could well be a reason for the relevant decision makers to reject including F# support by default in the .NET SDK. Or at least a reason for them to later remove that support. For example, my understanding is that it would add to the overall size of docker images that support scripting or compilation with .NET Core (C# or F#). And enough relevant decision makers would raise questions over why this space is being spent.

@dsyme Right, but...

• the reason 100 MiB matters, is if it gets duplicated lots of times on disk, or is a required download to view a web site
• for docker images, as long as the 100 MiB is on a re-used image, it's not duplicated on disk. In fact, you should probably consider giving a response here https://github.com/fsprojects/docker-fsharp/issues/3#issuecomment-300536084 – in this case we wouldn't be duplicating it on disk, because it would be initialised from the building of the container.
• I'm a decision maker myself, and I don't have a problem with it and I have pretty extensive knowledge of how to build F# software in the cloud, having done it for half a decade now
• I understand that you're talking about internal politics here; but why can't F#'s package be downloaded on demand for the .Net SDK as a contingency if your internal decision maker rejects it as part of the installer?

@haf

Do you have a real use-case of someone having problems with the size of the nuget?

Yes. One of the largest sources of complains about .NET all-up is its size. .NET Core has taken great strides in reducing this as much as possible. F# adding an additional 68 MB will also raise multiple questions from different stakeholders, such as RedHat, who also have to distribute our assets.

Solve by setting up a CI server. (in response to The package is not easily buildable from a source-tarball (a requirement in some settings)

Could you clarify what you mean by this? From our end, there are still issues with our build which must be addressed so that we can produce *nix assets on a *nix machine directly from source. And our requirements are such that FSharp.Core itself must also be built this way. If the FSharp.Core package contains bits which are not built from source and require Windows to build them (e.g., PCL targets), then we cannot fulfill this requirement.

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

Added fsharp/fslang-design#201 to discsuss about file size.
afaik (with some data, more to come), the 86MB is not the size add to MS Sdk.

At most, Sdk will add:

• bundled fsc compiler (another discussion the 1034 is for fsharp.core, that's 1033, there too can be from nupkg (and execute from cache as FDD) or bundled as SCD)
• a FSharp.Core nupkg (so compressed). that's 7MB

but about size can we discuss with data in fsharp/fslang-design#201