Fsharp: Incredibly painful development experience

[varon]

See also: #7395 - Ran into this as well today - almost identical setup.

Downloaded and installed the SDK 3.0.100-preview6-012264 using the Windows x64 installer.

Restarted VS, re-ran the build script from the developer command prompt which allowed it to progress a bit further.

Build script got stuck here:

VisualFSharp.sln:
  Restore completed in 46.32 sec for C:\Users\v\.nuget\packages\microsoft.dotnet.arcade.sdk\1.0.0-beta.19412.1\too
  ls\Tools.proj.
C:\Program Files\dotnet\sdk\2.2.401\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.TargetFrameworkInference.targets(137,5
): error NETSDK1045: The current .NET SDK does not support targeting .NET Core 3.0.  Either target .NET Core 2.2 or low
er, or use a version of the .NET SDK that supports .NET Core 3.0. [I:\work\github\fsharp\tests\fsharp\FSharpSuite.Tests
.fsproj]

Tried opening Visual Studio also asked for gigabytes of extra downloads when I opened the solution. I installed all of the required items. Still did not work.

Tried updating Visual Studio. More gigabytes of extra downloads. Still did not work.

It's rare I ever encounter libraries that are this hard to build. This was an incredibly painful experience.
What should have been a simple clone + fix + build + PR is now a multi-hour struggle.

While I can no longer offer the contribution I was intending to make due to the inability to build this, I hope that this experience report might be useful to the development team.

A few questions came up as I was doing this:

1. Why is this not just a normal dotnet core library?
2. Why is all of this (presumably irrelevant) visual studio stuff included? (What does visual studio have to do with the F# compiler at all? Surely it should be downstream from this?)
3. Why is the core library tied directly into the compiler? Is it not possible to make a contribution to the core library without having to build literally everything?
4. Why is this tied to a specific version of dotnet preview?
5. When last did the bootstrapping process work? Is there any kind of test for it?

[realvictorprm]

Same problem for me these days with the same questions these days :(

[jingle1000]

I too have had trouble with the support around F# as well. Microsoft support of F# is not up to par...

[cartermp]

Closing as dupe of #7395

Unfortunately, despite a ton of work we did to remove machine dependencies and have a clone + build contribution process, internal requirements that are necessary for us to ship have since prevented that. The amount of work to get it back to a sane contribution state is small, but the internal compliance with our build system is required.

Sorry that this caused such an inconvenience; you'll notice I've labeled #7056 as a regression and that's sort of the canonical issue tracking the, "we've regressed the ideal contribution experience" problem.

As for your specific questions:

Why is this not just a normal dotnet core library?

It's unclear what you're referring to. This repository contains a compiler, compiler service, multiple test suites, FSharp.Core, and Visual Studio tooling. This is not a library targeting netcoreappXX.

Why is all of this (presumably irrelevant) visual studio stuff included? (What does visual studio have to do with the F# compiler at all? Surely it should be downstream from this?)

Also, it's unclear what you're referring to here. The repository contains all of what I mentioned above. And because this is a monorepo, where everything F# - soup to nuts - is tested together, it's in the same codebase. You can use FSharp.sln to develop without Visual Studio, since that doesn't contain the visual studio tooling. And the -noVisualStudio flag in the build script can also be used.

Why is the core library tied directly into the compiler? Is it not possible to make a contribution to the core library without having to build literally everything?

The core library is not a library in the traditional sense. It is both a core F# runtime and a library, the factoring of which I am not a fan of. But there's more than a decade of history behind that factoring and we won't be ripping apart right not.

Everything is together because everything needs to be tested together. Your change could break binary compatibility. If your change was in one place in FSharp.Core, it could also break the compiler. It could introduce a source incompatibility that only our tests can catch. It could potentially negatively affect all F# editor tooling, and F# editor tooling is one of the primary benefits of using F# over other functional languages. Changes in something as central as FSharp.Core can have very wide-reaching implications that need to be verified.

Why is this tied to a specific version of dotnet preview?

An unfortunate, and awful, dependence on some internal stuff that we require for shipping. Failure to have this means we'd need to go back to manually integrating and testing F# into both the .NET Core and VS release trains, something that was so time-consuming an error-prone that it caused us to _miss_ releases that we could have otherwise made.

When last did the bootstrapping process work? Is there any kind of test for it?

A while back, earlier this year. It's not a bug, it's by design (unfortunately),

[varon]

@cartermp Thank you for taking the time to answer in such detail.

This issue focused more on the general pain of contributing rather than the specific failure point that caused this. Ultimately it's your library so your call to structure/close things as you see fit.

I think you've answered most of the questions I had. From a lay developer's perspective, this seems incredibly crazy to have the entire thing built in such a fragile way.

Just to re-iterate on the experience:

I wanted to add a function to FSharp.Core. This is a function to just do nothing with a given format string in the Printf module. Super easy, and something we need - see https://stackoverflow.com/questions/31442608/how-to-wrap-sprintf-conditionally-in-f as it can't be done externally without reflection.

But instead of just cloning, editing two lines and making a PR like any normal repo, I'm somehow forced to run headlong into the entire compiler toolchain and the jungle of things related to it.

This is a nightmare scenario as a first-time contributor.

Are there any plans to fix what appears to be a pretty flawed design? Perhaps a Roslyn of F# or something? Is there anything you guys can do to make contributing simple things simple?

[cartermp]

No, the factoring of the repository such that changes in a core component can be verified across the product is highly unlikely to be adjusted.

I also believe quite strongly that had your experience been what we had prior to the requirement for a global MSBuild and global .NET Core 3.0 SDK (again, internal compliance here) then you'd be able to do exactly what you're after.

The only requirements from VS are those that are required for .NET development already, so if you lack those or are somehow required to download many more GB of things, your VS install is either not configured to do .NET development, or you've selected significantly more components to install than the required set for developing in this repository.

[varon]

Thanks for the time and answers.

[forki]

@varon I think if the current issue with dotnet core 3 is resolved then things are back to tolerable. It was never really great for newcomers to contribute here, but things improved steadily. As a long time contributor I can confirm that. It is getting better over time. Which is all we can ask for. BTW we as community outside of Redmond are part of that process. We report concrete blockers and try to make things better with stuff like the current push to get rid of the perl tests. But it's an gigantic code base. It takes time.

Unfortunately it regressed and usually this happens right before big releases so that the team is snowed under. But I am certain it will be dealt with asap.