Fsharp: Q: mono support in visualfsharp

[forki]

Since coreclr support has landed in master and Microsoft bought a whole company with tremendous mono know how I think it's time to ask that question again.

When can we merge fsharp/fsharp and visualfsharp?

A lot of the important F# projects like mbrace can't be ported to coreclr since important bits are missing there. We assume that it will still take a couple of years until mono support is not that important anymore.

If we want to have that FSharp.Core NuGet package that contains coreclr, Windows and mono we should make this step now.

What do you think?

[dsyme]

@forki My feeling is that this repo is in continued danger of becoming the "logjam" for F# - it now combines two flavours of the compiler/library toolchain (.NET Core and .NET Framework), one flavour of project build support (FSharp.Build) and half of one flavour of editing tools (the Visual F# IDE Tools).

I personally feel that undoing this logjam is important and regardless we have to avoid increasing the problem. So I'd be loathe to bring F# + Mono bug tracking into this repo when it can currently be done on different cadence and in a way that has zero interference with work here.

I've also noticed the including CoreCLR support is now dragging the repo in two directions:

• a "vertical, single-platform, single-editor IDE tools stack for F# in Visual Studio on Windows" (what it's been until now)
• a "horizontal, cross-platform, multi-editor substrate" for the F# language (CoreCLR, Mac, Linux, proj.json)

Re FSharp.Core - the plan is to continue to publish a joint nuget package for FSharp.Core from http://github.com/fsharp/fsharp. AFAIK this will incorporate the Microsoft FSharp.Core CoreCLR packages as a package dependency.

[forki]

yes my concern is mainly about FSharp.Core and FSharp.Compiler.Tools packages.
My dream is that we see daily builds (and PR builds) of these packages on myget and releases on nuget.org. If we would have such artifacts it would make it easy for us to test compiler/core in real-world projects.

Things like "Microsoft.FSharp.Core.netcore" package shouldn't exist. I know it's meant as temporary thing, but tbh I fear that if we don't be careful then some day this package will be a real release.

I completely agree with you that a splitting by separate concerns (IDE/tooling vs. compiler/core) would be even better.

[enricosada]

same, my annual comment:

cant' we split responsabilities?

fsharp/fsharp: fsc/fsi/Fsharp.Core/Fsharp.Compiler => build nuget packages with all supported frameworks (net46, netcore, mono, etc)
visuafsharp: vs extension => vs extension and consume nuget packages of fsharp/fsharp

ref https://github.com/fsharp/fsharp/issues/566 about a single fsharp.core

if the scope of repo is smaller, it's possibile to manage it more easy, easier to develop, build, test, evolve

[forki]

I think we discussed this on other places as well, but now we start seeing issues with the new Microsoft.FSharp.Core.netcore package (see https://github.com/fsprojects/Paket/issues/1815)

As I said before it's really unfortunate that this package even exists. @cartermp, @KevinRansom please comment on the issue. How should we handle this? Will the new package die eventually?

I proposed earlier that I think we can hand over FSharp.Core package ownership to Microsoft. I personally have no problem with that as long as mono is still supported.

Whatever you think will work: we need to act now.

[isaacabraham]

I'm really worried when I start seeing two versions of FSharp.Core bleeding into the main Nuget repository chain. This is what is known as forking the ecosystem. I can only see pain up ahead.

[dsyme]

@forki @isaacabraham The plan of record (at least in the interim) is to make the FSharp.Core package a super-package of Microsoft.FSharp.Core.netcore, either via a dependency or a merge. That seems reasonable.

Having Microsoft build the full FSharp.Core package (including the Xamarin binaries) could also be possible, especially now the Xamarin acquisition has gone through, it's now just work. Before the acquisition it wasn't really feasible.

[forki]

making it one single build would be best, but we need at least a hacky
intermediate solution now. Maybe it's enough to make paket work around it.
I don't know yet

On Jul 18, 2016 9:44 AM, "Don Syme" [email protected] wrote:

@forki https://github.com/forki @isaacabraham
https://github.com/isaacabraham The plan of record (at least in the
interim) is to make the FSharp.Core package a super-package of
Microsoft.FSharp.Core.netcore, either via a dependency or a merge. That
seems reasonable.

Having Microsoft build the full FSharp.Core package with the Xamarin
binaries as well could also be possible, especially now the acquisition has
gone through, it's now just work. Before the acquisition it wasn't really
feasible.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/visualfsharp/issues/1054#issuecomment-233256190,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADgNK1PPYXQPmOVvebAhAghovagwb6mks5qWy7fgaJpZM4IDzsC
.

[enricosada]

@isaacabraham is not that bad, it's not a fork.
it's possibile to release an FSharp.Core.netcore as metapackage, that mean it only reference the FSharp.Core package (no assemblies inside).
Like that it's just an alias, and fix all issues when we want to use only FSharp.Core.

But yes, only one package pls :smile: ( and only one repo for fsharp.core/fsc :+1: )

[cartermp]

I'm not sure if we've investigated this yet, but with the .NET Standard we can eventually just have one single package which will run anywhere. There isn't a date set in stone yet, but .NET Standard 2.0 will be the "mscorlib-based"[0] version which has most of the APIs made cross-platform. I don't know how feasible it is now, but eventually we won't need to be clever with packages since the code will "just work" on .NET Framework, Xamarin-flavored Mono, Mono proper (I lthink?), and of course .NET Core.

[0] Note that although it will _appear_ to have the same surface area as most of mscorlib, it's actually a bunch of type forwarding into different packages. You just get more API support out of the box. We don't want to thrust the monolithic mscorlib on everyone, and we still want the ability to update specific APIs without needing to ship a brand new version of mscorlib again.

[forki]

Tbh this sounds a bit too optimistic. ;-) Reality is that we should be
really carefully to not break the existing mono stuff. I'm not sure what
parts are still missing and are only in fsharp/fsharp but AFAIK there are
still couple of things. But I don't know the details.

On Jul 18, 2016 5:22 PM, "Phillip Carter" [email protected] wrote:

I'm not sure if we've investigated this yet, but with the .NET Standard we
can eventually just have one single package which will run anywhere. There
isn't a date set in stone yet, but .NET Standard 2.0 will be the
"mscorlib-based"[0] version which has most of the APIs made cross-platform.
I don't know how feasible it is now, but eventually we won't need to be
clever with packages since the code will "just work" on .NET Framework,
Xamarin-flavored Mono, Mono proper (I lthink?), and of course .NET Core.

[0] Note that although it will _appear_ to have the same surface area as
mscorlib, it's actually a bunch of type forwarding into different packages.
You just get more API support out of the box. We don't want to thrust the
monolithic mscorlib on everyone, and we still want the ability to update
specific APIs without needing to ship a brand new version of mscorlib again.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/visualfsharp/issues/1054#issuecomment-233361440,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADgNLowMgKBmKS5WmDq0ob-tXEOHCFOks5qW5opgaJpZM4IDzsC
.

[dsyme]

@forki For .NET Framework and the PCLs, FSharp.Core is the same everywhere - the Microsoft signed FSharp.Core is the one included in the FSharp.Core nuget package. There are a couple of additional Xamarin buids of FSharp.Core DLLs in the FSharp.Core nuget package.

[dsyme]

Closing as we now CI with Mono. There are bugs, but the basic support is there