Skip to content
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

Ionide 4.0 roadmap #1108

Closed
Krzysztof-Cieslak opened this issue May 22, 2019 · 13 comments

Comments

Projects
None yet
5 participants
@Krzysztof-Cieslak
Copy link
Member

commented May 22, 2019

In dotnet/fsharp#6785 I've talked a bit about upcoming Ionide 4.0. In this issue I'll track main work items that will lead to the release. We will use experimental-fsharp extension to distribute previews. Version 3.X of Ionide is not officially feature-frozen, however it's hard to expect any new huge features in the current state. The work will be happening on 4.0 branch

Roadmap:

  • Use LSP version of FSAC (#1109)
  • Use netcore runtime of FSAC as default (#1114)
  • Remove multiple ways of workspace initialization - we will use only workspace method (#1114)
  • Use new unified project parsing in FSAC (fsharp/FsAutoComplete#347)
  • Use .Net Core version of Forge (#1113)
  • Update Forge scaffolding to use dotnet new under the hood Use .Net Core Forge templates (#1113)
  • Replace project parsing notification with status bar indicator (#1077)
  • Add support for .Net Core FSI (#1087)
  • Rethink the default settings - things like external autocomplete, simplify names analyzer or background project checking should probably be turned off by default
@MangelMaxime

This comment has been minimized.

Copy link
Contributor

commented May 22, 2019

Remove FSAC runtime option - we will distribute only .Net Core version of FSAC

Just a warning about this decision. I know that at least one of my project can't use .Net Core runtime anymore due to a SO in the F# Compiler.

I think that I have more than one project doing that but I need to check again.

Original issue: #1039

@baronfel

This comment has been minimized.

Copy link
Contributor

commented May 22, 2019

Same for us, the underlying stackoverflow still isn't solved for some of our projects.

@Krzysztof-Cieslak

This comment has been minimized.

Copy link
Member Author

commented May 22, 2019

Yes, I'm aware of the issue - if that won't be fixed when Ionide 4.0 will be ready, we will keep net runtime, but will use netcore as default.

@enricosada

This comment has been minimized.

Copy link
Collaborator

commented May 22, 2019

@Krzysztof-Cieslak @baronfel I am not sure if FCS .net core can fully support fsx script on .NET fsi. Or some .NET projects if that matter.
I seen small quirks who add up, i'll list these somewhere later, but is not just project parsing.

For sure, i agree that the .NET Core stack should be the default, for best experience for new and existing users, as @cartermp suggested.

.NET Core will be the future, but .NET is important, lot of libs atm.

I think a safer bet is have both stack, but an easier way to choose, not the multiple independent options ( (fsi/fsac/msbuild) we have now who are confusing like msbuild vs dotnet msbuild. We need to simplify:

users doesnt care about FSAC/msbuild version. just a bit more the fsi version

  • FSAC/FSI/MSBUILD are aligned. Or are .NET or .NET Core.
  • when .NET => fsac .NET + fsharpi + msbuild
  • when .NET Core => fsac .NET Core + dotnet fsi + dotnet msbuild

Default is .NET Core stack

FSI

As a note, the dotnet fsi is in preview.

Another stuff i am thinking can help:

  • fsx script are a bit strange, until dotnet fsi is out preview, but also after that.
  • each fsx script is isolated, is alongside the fsproj but usually have different references, etc
  • and maybe is a expected to run with fsi, the #r matter there.

So i think we should threat .fsx and .fs differently.

  • each FSI should start a new FSAC. so isolated. Easy to kill when FSI console is closed
  • because FSI is separated, it can run on .NET or .NET Core as needed, without switching main FSAC
@Krzysztof-Cieslak

This comment has been minimized.

Copy link
Member Author

commented May 23, 2019

msbuild vs dotnet msbuild

It doesn't depend on the FSAC runtime, tho - it depends on the project type, and both runtimes support both project types (i.e FSAC netcore can be run against MsBuild 14.0 file that needs to be build with msbuild). I feel we're doing good job in automatic detection of the msbuild host at the moment - personally, I haven't seen any case where I need to change host manually (but I'm not huge TP users, as far as I remember it was one of the cases where the change was needed).

I think that:

  • msbuild vs dotnet msbuild - stays at it is, it's independent from the FSAC, the flow around building/running projects is OK, we have automatic detection of host.
  • fsharpi vs dotnet fsi - controlled by option with dotnet fsi as default
  • fsac netcore vs fsac net - The SO bug is only reason I'll consider keeping net. If some other stuff is not working in netcore we should fix it, instead of distributing net as workarond
@enricosada

This comment has been minimized.

Copy link
Collaborator

commented May 23, 2019

It doesn't depend on the FSAC runtime, tho - it depends on the project type

It's not so easy, and we work a lot on that, so i understand is more complicated for users.

It's:

  • Old sdk project (verbose) = 100% .NET stack => msbuild
  • .NET sdk project (slim), can be better msbuild or dotnet msbuild, depends on the sdks/target/packages used. But dotnet msbuild as sane default

But if they choose .NET stack (so msbuild), is fine to use FSAC .NET because it's expected .NET to exists.

Again, the root issue is .NET stack vs .NET Core stack, we should add just an option for that, with a sane default who command the other three (msbuild,fsac,fsi)

As a note, VS/rider use .NET stack.
Ionide doesnt need to do the same, is better the .NET Core stack, but we need choice

fsharpi vs dotnet fsi - controlled by option with dotnet fsi as default

Because is a binary choice, and can vary from script to script, ihmo a config is more work and too hidden when ppl doesnt know about the difference between the two, less so know a config.

Maybe it's better having two commands, something like:

  • F# > Start Interactive (dotnet fsi) - runs on .NET Core [preview]
  • F# > Start Interactive (fsi) - runs on .NET/mono

Or we can add a F# > Start FSI (more info) where you choose the version (dotnet fsi vs fsi), and maybe can pass additional args

We can also default FSI based on the current stack (.NET or .NET Core) for the repo

Again, dotnet fsi is preview, forcing preview for everyone has default create more issues.
Like:

  • ppl load net461 libs and doesnt works
  • do #r of GAC'ed libs
  • follow tutorials (99.99% expect .NET, not .NET Core)
  • send references of net461 project to fsi and these doesnt work.
  • open fake v4 script

So a more explicit control with a command ihmo is less error prone.

If some other stuff is not working in netcore we should fix it, instead of distributing net as workarond

Is not so easy, otherwise all applications where already running on .NET Core only :(
There are limitatins based on .NET Core Runtime version.
Not everyone use latest 3.0 preview, and ihmo folks shouldnt use preview unless they know what they do, it's bad, it 99% better use latest LTS. Also Current have small niche usage.

Yes, we need to list and try to minimize differences, that's what everyone is doing, but take time, we are not yet there.

@Krzysztof-Cieslak

This comment has been minimized.

Copy link
Member Author

commented May 23, 2019

OK, it seems we'll keep net FSAC runtime for a time being, but use netcore as default. I'll update OP

@inosik

This comment has been minimized.

Copy link
Contributor

commented May 24, 2019

Update Forge scaffolding to use dotnet new under the hood

FYI, there's a new extension that provides a GUI for dotnet new. It won't work right now because the VSIX is missing the HTML file for the webview.

One issue I have with dotnet new though, is that we have to reinstall templates if we upgrade the .NET CLI. For example, if you're using .NET SDK 2.1.506 and do dotnet new -i SAFE.Template, you have to do this again after upgrading the .NET SDK to 2.1.507. We might be able to work around this if Forge would host the templating engine itself (dotnet/templating#1707) and configure the hive path in another way.

@Krzysztof-Cieslak

This comment has been minimized.

Copy link
Member Author

commented May 30, 2019

Latest update:

@Krzysztof-Cieslak

This comment has been minimized.

Copy link
Member Author

commented May 31, 2019

  • Use netcore runtime of FSAC as default - done in #1114
  • Remove multiple ways of workspace initialization - we will use only workspace method - done in #1114
@Krzysztof-Cieslak

This comment has been minimized.

Copy link
Member Author

commented Jun 8, 2019

@Krzysztof-Cieslak

This comment has been minimized.

Copy link
Member Author

commented Jun 8, 2019

  • Rethink the default settings - done in 6a83beb
@Krzysztof-Cieslak

This comment has been minimized.

Copy link
Member Author

commented Jun 11, 2019

  • Replace project parsing notification with status bar indicator - done in 66118a5
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.