-
Notifications
You must be signed in to change notification settings - Fork 144
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[F# Tooling RFC-1032] Discussion: Support for F# in the dotnet sdk #188
Comments
Replaced by successive commentwhateverI'd like to give an overview of current status first, some context, and finally some tradeoff choices to evaluate The question about how to support F# in the .NET Core world is a long argument, because it is not just about the .NET Core/NETStandard but also affects:
AFAIK this new tooling (new fsproj) should completely replace old F# tooling (the old fsproj). So it will also be used to build net40 or Xamarin mobile apps etc , we the tooling is finally available and all projects converted. The new fsproj will support multiple target framework in same project (crossgen).
Current statusI'll start from the user experience, because is easier to see the main goal: default templates of lib/console should give the best practices, and not cripple integrations. Templates are the starting point (
The template engine and the default templates (lib/console/etc) should be shared (they are just nuget pkgs), but the bundling may change (so VS has these in a different location than dotnetcli). The hard choices for the templatesFor templates, the actual SDK used is an implementation detail (FSharp.NET.Sdk+Microsoft.NET.Sdk or just Microsoft.NET.Sdk). But I want to highlight that there other very real choices lurking here which we shouldn't avoid:
These shape both templates and the implementation. Tradeoff choices (whether to have FSharp.NET.Sdk or not)FSharp.NET.Sdk positives:
The bad with FSharp.NET.Sdk, with possible solutions:
The other issues:
Base assumption i used in my work:
How i understood things works in .NET (so easier for c# interoperability and sdk/tooling integration/maintenance)
Currently how things work in new fsproj (based on current templates, and i repeat:
Also, both packages ARE already normal
the so
|
@enricosada I edited your comments above to remove spelling mistakes. If it is possible for you to reduce the comment a bit to get right down to the essentials that would be great. |
@enricosada I rearranged your comment a little to bring the real questions under discussion closer to the top, and put some of the background information/assumptions at the bottom. |
I'll trim it, i am always too verbose writing these retrospectives. Thx a lot for cleanup @dsyme |
@enricosada :) no problem, my pleasure :) |
From an engineering perspective: Having the dotnet cli build test and deploy F# means that, before they check-in stuff that breaks us they will have to fix it or give us a heads up. Crossgen is goodness. What we have needs to work well under CPS, following the C#/VB model ensures that F# will always feel just as first class as those two languages. Because we are a smaller, much more distributed team, we need to follow their model on most of these things. Except when we have a clearly superior approach of course. The SDK, the CLI and the templating projects are all open source, and will welcome contributions aimed at improving our F# support. From a third party developer perspective: Having the same project structure as C# and VB means that a C# developer can easily reason about what an F# project will do when compiled. The major differences between F# and C# in the SDK will be the requirement to list source files. C# and VB developers are spared that duty. The work that you did on the FSharp.Sdk was trail-blazing and significantly improved the F# coreclr story, however, C# and VB were significantly better integrated into the coreclr and msbuild dotnet eco-systems, the new approach aligns us more closely. To close, Kevin |
This is the first really good news in this year. Thanks you. |
With the old fsproj, I currently use https://www.nuget.org/packages/FSharp.Compiler.Tools. Will I still be able to override the compiler? You mentioned somewhere that this checks for Basically, I want to be able to use the "nightly" compiler with any version of Visual Studio / dotnet cli. Edit: I read enricos post again, and am I correct that I could just continue to reference |
I'll update my comment as @dsyme request, because was more feedback driven and not actionable enough. I'll convert it to a question list for vf# team (@dsyme @KevinRansom @cartermp etc.) so i hope it is easier to discuss and answer. Let's focus on the how and details, because is just another PR for me, who can improved (not just by myself) and enhance final deliverable. First to automatically copy c# or vb only is, IMHO, not enough because we are a different community and repo. Many things can be best handled if split as single discussions not using a big one (il.e. it's not just all about "in band" v "bundled" - this is too generic and minimizes the opportunity for discussion, with lot of noise). Let's try to separate the issues. If "in band" mean bundles like VS/mono/dotnetcli CANNOT release a new version if fsc is not ready, otherwise is exactly the current situation. Otherwise is just bundle fsc and target and is ok too. The .net teams are really collaborative already (and dotnet/cli contains test for F# projects in CI since preview2 , go figure), and they are proactive to maintain and enhance, to ask, point to issue and they communicate a lot (see https://github.com/dotnet/netcorecli-fsc/issues who contains examples), so thx a lot to @livarcocc @eerhardt @piotrpMSFT @dsplaisted @mlorbetske @nosami @mrward @mmitche, and previous owners/menbers . Personally, while i value a thing like parity, that doesnt matter it cannot be adapted a bit to help with current f# situation: we have a required lib, a special community and lot more OSS effort than others (focused on grumpy tooling too) |
I'd like to give an overview of current status first, some context, and finally some tradeoff choices to evaluate The question about how to support F# in the .NET Core world is a long argument, because it is not just about the .NET Core/NETStandard but also affects:
AFAIK this new tooling (new fsproj) should completely replace old F# tooling (the old fsproj). So it will also be used to build net40 or Xamarin mobile apps etc , we the tooling is finally available and all projects converted. The new fsproj will support multiple target framework in same project (crossgen).
Current statusI'll start from the user experience, because is easier to see the main goal: default templates of lib/console should give the best practices, and not cripple integrations. Templates are the starting point (
The template engine and the default templates (lib/console/etc) should be shared (they are just nuget pkgs), but the bundling may change (so VS has these in a different location than dotnetcli). The hard choices for the templatesFor templates, the actual SDK used is an implementation detail (FSharp.NET.Sdk+Microsoft.NET.Sdk or just Microsoft.NET.Sdk). But I want to highlight that there other very real choices lurking here which we shouldn't avoid:
These shape both templates and the implementation. These two are the two big categories (lib and console). And tradeoff doenst need to be the same. FSharp.CoreA lib in modern .NET (unless is a bcl assembly) is packaged as a nuget Package (nupkg). I think of Using Also with new sdk (new fsproj/csproj), nupkg are first class, so easy to add (as The open questions about FSharp.Core.dll
These questions shape the best pratices, and resilience. Fsharp.Core in template options
Both are ok for FSharp compilerA console in .NET is usually deployed as FDD (and SCD for netcore and probably mono) I think of An fsc built for the msbuild host runtime is needed. Each runtime has additional feature (ngen, SCD) and constraint My Q: With fsc, shoud be more deterministict in the template? if a tradeoff is choosen (use bundled fsc), can anyway leverage nuget for discovery, versioning, updates? The open questions about fsc
fsc in template options
Both are ok for TargetsThe msbuild need target/task. Targets doesnt change a lot, and are better if near sdk (or inside it), so i agree a lot. While there is value to have an upgradability there too to fix bugs withtout a new sdk drop. (see for example the bug in nuget pack with dapper), doesnt happen often, So i just add feedback. Feedback about targets
|
Questions: Desktop compiler The will be an msbuild only deployment mechanism, similar to the VS installer but for msbuild and build tools. F# and the dotnet SDK will be an install option with that, this will enable the build server scenario. For RedHat there will be a build from source mechanism. |
i'll add my final reply to this RFC, because while i was interested to see this as RFC so discussion before action and final decision (the So doesnt matter for me to continue to discuss, i'll wait for the final artifact. Or use other issues/PR if exists in vf# repo, but i think i wrote all my feedback in this issue and this reply. FSharp.Core@KevinRansom you skipped all the This matter a lot because you (vf# and MS) control (or you will override easly anyway) the templates for all runtimes bundled (now are shared in In the RFC definition (and committed code) i see lot of scary public props. These may be just WIP or your final design. I dont know. So i can trust you (Kevin/Phil), but communication atm is a bit low. fsc
ok, which one? i understand
publish as SCD, so to .exe. But FDD, like now is used for netcore, doesnt work (set
Because you probably choose to use As a note, as tradeoff possibility (what i was writing) is possibile to have a SINGLE package, who contains ALL fsc for ALL runtimes. like
Because, i assume to continue discussion, you want to do separate compiler package by target runtime (coreclr in Desktop compiler
What mechanism? info? just a link or codename? OR is just a closed source not announced thing for 15.3? link for MVP if possibile under NDA? just curious. That said: Personally, I really really hate vsix alike install mechanism for build server. Is not feasible (depends on install workflow) for deterministic build, if i need a specific installed bit in the server to work. Is like sdk now. New sdk/msbuild15 support extensibility by nuget packages. BOTH TARGET/TASK AND TOOLS. i use that atm in fshar.net.sdk implementation, and not just me, other .net teams too (see test sdks) support FSharp.NET.Sdk and migrationSo, skipping the communication issue about the "in-banding" notice of Atm is just needed to repackage a About the workaround to support it in MS.FSharp.Sdk.targets are not needed probably, need to check. For sdk2.0 i can just add a condition in |
@enricosada I'm starting to a separate RFC to discuss the FSharp.Core package issues. I think that should be separated - and we need to discuss this as a joint community. |
@dsyme agree, is important. And please, add a point about Ihmo if vf# team need tradeoff for VS, they need to spec their needs (not their current choosen implementation, like discussion in this RFC, but is their product so ok), so templates can be adapted to continue to use best pratices ootb and not create friction with existing ecosystem or VS users or VS supported scenarios. Good news is we have:
So maybe we can start with a difference comparison. I summarized in my previous comment the open Q, but i explicit the choices as matrix |
I do agree this is a risk. Historically the Visual Studio "logic" for FSharp.Core has been real pain point. We should try to make sure it becomes simpler this time around (while still maintaining compat) @enricosada The RFC focuses on the question of packages more than .NET SDK templates etc. I can only deal with one thing at a time :) thanks! |
Updated w/ comments in gist. |
@dsyme this can be closed afaik. The .net sdk is updated. Summarizing:
|
@enricosada @cartermp Great to know that the changes are coming through the pipe. Could you work together to update docs and entry points so they have the correct information? thanks |
I'll leave the thread open for disucssion until we're sure we've landed the whole overall experience |
Does this include |
@neoeinstein the latest dotnet/cli runs fsc without requiring a 1.0 runtime download. fsc is a coreapp2.0 app in the dotnet cli. Kevin |
@neoeinstein while i can fix Yes adding fsc 2.0 (just copying That's my current problem. In your scenario, your are running the
Next I am updating the https://github.com/dotnet/netcorecli-fsc/wiki now about |
@enricosada Sounds good. I just was prospectively trying out the preview and ran into that issue. If changes are coming, I'd prefer not to be spending time on supporting the deprecated path. Thanks. |
Closing old discussion |
Discussion thread for F# Tooling RFC- FST-1002 - Support for F# in the dotnet sdk
Despite being a tooling issue rather than a language issue, this is being treated as an F# RFC to facilitate discussion and transparency. Discussion should please be de-personalized and focus only on the technical details involved.
The text was updated successfully, but these errors were encountered: