Ionide-vscode-fsharp: Paket & FAKE vs Ionide

[Krzysztof-Cieslak]

CC: @matthid @forki @enricosada @isaacabraham

Hey

I have one big question about UX for Paket/FAKE and Ionide. At the moment we have separate extensions for FAKE and Paket suport - idea behind that (especially for Paket) was that it would enable users to get good Paket/FAKE experience even if they are not F# developers and don't want F# tooling installed on their machine - this was especially important in pre-SDK times, when getting F# installed was not always simple.

However, @matthid work in FSAC (https://github.com/fsharp/FsAutoComplete/pull/402) and his ideas for future improvements (https://twitter.com/matthi__d/status/1138403342516989955) show us that we can provide way better UX when we integrate tools. Working on things in FSAC also potentially allows other editors to implement similar support for those tools.

So the big question is - do we want to keep separate extensions for Paket and FAKE, or should we just bundle it together, and work on new features on FSAC side? Maybe we should bundle just FAKE - using FAKE without F# tooling installed is silly idea anyway, and keep Paket separated?

[matthid]

Maybe we should bundle just FAKE - using FAKE without F# tooling installed is silly idea anyway, and keep Paket separated?

yes indeed FAKE tooling is just duplicating a lot and conflicting as it works on the same files...

Regarding Paket I'm not sure. In theory it is completely separate, in practice FAKE 5 now depends on paket.core so the dependency is already there. So I'd say we could just use it and simplify our life?

From a users perspective I don't care too much but I'd prefer a single install and have all the stuff just work. If multiple extensions I'd expect them to work well together. So ...

[rojepp]

My 2 cents: Paket is not only used for F# projects. I use it in many projects that have no F# in them. Some users might not want to install Ionide to get Paket support?

[forki]

Why wouldn't you want to install ionide? It's not that huge dependency Imho

Robert Jeppesen [e-mail] schrieb am Mi., 12. Juni 2019,
07:41:

My 2 cents: Paket is not only used for F# projects. I use it in many
projects that have no F# in them. Some users might not want to install
Ionide to get Paket support?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ionide/ionide-vscode-fsharp/issues/1119?email_source=notifications&email_token=AAAOANGLXRHE5OY4IC3VUHTP2CEB5A5CNFSM4HW5L2QKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXPJ3AA#issuecomment-501128576,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAOANDYX7YOOZG4HVL3D3DP2CEB5ANCNFSM4HW5L2QA
.

[rojepp]

I was thinking a C# dev might not even know about Ionide?

[forki]

yeah, but maybe VS Code can recommend when you have .dependencies file in project

[vbfox]

I'd like to keep paket one separate, Ionide/FSAC loads, then uselessly hog memory (Because it trig on .sln files) when opening big C# projects.
The result is that I tend to disable the extension in folders with C# code only, but we still use paket everywhere and the extension is a nice to have.

The Fake & Ionide split is pretty artificial I agree, I don't see any use of one without the other.

VSCode support extensions that are bundles, I think the main F# one should be a bundle of paket + FSAC/Ionide + Fake (whatever the exact split of extensions is) so that there is no need to hunt for other extensions. It could also allow things like F# language coloring to be in separate extensions from the FSAC/LSP part for example.

[enricosada]

I tend to agree with Julian.

Paket should be a separate extension.
But ionide and paket extensions can communicate on events.
Probably paket should be an LSP too, with syntax and commands

Not sure about FAKE, but instead of include it in FSAC, it can be an external process to call to list targets, so no dep of FSAC.
Ideally FAKE should support a builtin way to list targets, and we read that (but external process allow to support older FAKE)

And favor a bundle if possible

From mobile

--
Enrico Sada
@enricosada

---

Da: Julien Roncaglia [e-mail]
Inviato: mercoledì, giugno 12, 2019 2:23 PM
A: ionide/ionide-vscode-fsharp
Cc: Enrico Sada; Mention
Oggetto: Re: [ionide/ionide-vscode-fsharp] Paket & FAKE vs Ionide (#1119)

I'd like to keep paket one separate, Ionide/FSAC loads, then uselessly hog memory (Because it trig on .sln files) when opening big C# projects.
The result is that I tend to disable the extension in folders with C# code only, but we still use paket everywhere and the extension is a nice to have.

The Fake & Ionide split is pretty artificial I agree, I don't see any use of one without the other.

VSCode support extensions that are bundles, I think the main F# one should be a bundle of paket + FSAC/Ionide + Fake (whatever the exact split of extensions is) so that there is no need to hunt for other extensions. It could also allow things like F# language coloring to be in separate extensions from the FSAC/LSP part for example.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/ionide/ionide-vscode-fsharp/issues/1119?email_source=notifications&email_token=AABD6KZWKNUXGTQL6VSPSBDP2DTEXA5CNFSM4HW5L2QKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXQHK4Q#issuecomment-501249394, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AABD6KZGFWCJCGMHLKZWJILP2DTEXANCNFSM4HW5L2QA.

[matthid]

Not sure about FAKE, but instead of include it in FSAC, it can be an external process to call to list targets, so no dep of FSAC. Ideally FAKE should support a builtin way to list targets, and we read that (but external process allow to support older FAKE)

Sadly it is not about listing targets but about basic tooling support (autocomplete and basic stuff is not working well today imho).

If there is a good way to communicate between plugins than I think having two extensions is OKish as long as the "default installation" installs a bundle containing everything (Paket & Fake & Ionide) just as suggested

I'd like to keep paket one separate, Ionide/FSAC loads, then uselessly hog memory (Because it trig on .sln files) when opening big C# projects.
The result is that I tend to disable the extension in folders with C# code only, but we still use paket everywhere and the extension is a nice to have.

That is imho not really a reason to split, more a reason to fix that particular issue ;)
Especially when working on C# projects there is no reason for Ionide to slow down the system. But I think that is off-topic here.

[Krzysztof-Cieslak]

Especially when working on C# projects there is no reason for Ionide to slow down the system. But I think that is off-topic here.

I don’t think it should - yes, it will start, read sln, attempt to parse project files, fail because those are C# files... and then do nothing, don’t think it will use lot of memory

yes indeed FAKE tooling is just duplicating a lot and conflicting as it works on the same files...

Huh? FAKE plugin is just bunch of helpers that are used to execute FAKE, it doesn’t provide any in-editor features

[matthid]

Huh? FAKE plugin is just bunch of helpers that are used to execute FAKE, it doesn’t provide any in-editor features

Yes. But logically https://github.com/fsharp/FsAutoComplete/pull/402 belongs to the FAKE extension. This is the reason for this discussion after all?

[MangelMaxime]

Sadly it is not about listing targets but about basic tooling support (autocomplete and basic stuff is not working well today imho).

The only strange thing I have when working with FAKE is that when updating the deps, I need to close and re-open the .fsx file other than that I have the same experience as when writing to a .fs file (inside a project).

Also, if the "autocomplete and basic stuff" doesn't work properly it's probably not specific to FAKE but more to scripting with .fsx files and so it belongs to Ionide extension and FSAC.

For me VSCode-FAKE extension, can/should be a standalone if it provides extra feature than editing support which belongs to Ionide. For example, if the VSCode-FAKE allow something like that:

1. User do Ctrl + P > "Run fake"
2. FAKE list all the possible target in a select box
3. User choose one target
4. FAKE run the selected target

[matthid]

@MangelMaxime I guess that is mainly because you have become used to the limitations. For new users this is just bad UX:

• I have to run fake before getting any tooling support
• I have to add #load "intellisense.fsx" for any tooling support
• I get tooling support for full framework while FAKE actually runs on netcore/netstandard
• I have to add #r "netstandard" to not have everything underlined with red squiggles. This workaround doesn't even work on all platforms.

It is not easy to solve those issues in the FAKE plugin

[MangelMaxime]

@matthid Oupsy indeed I totally forget about these issues and was thinking πart of them was required even for running FAKE.

So it's not that easy to categorise indeed :)

[Krzysztof-Cieslak]

It is not easy to solve those issues in the FAKE plugin

That's correct - those things need to fixed in FSAC. As I've mentioned FAKE plugin is just set of helper commands - it doesn't have any access to FSAC and it's hard to imagine good architecture where it would have access to FSAC/language features.

So my proposal would be:

1. Keep Paket plugin separated - it just makes sense to use Paket without F#, so one extension shouldn't require other
2. Deprecate FAKE extension and provide its features in F# extension - using FAKE in VSCode without F# installed doesn't make sense, we also need to make sure editor features powered by FSAC work well with F# script so there already exists coupling between both.

[Krzysztof-Cieslak]

FAKE integration improvements are tracked in https://github.com/ionide/ionide-vscode-fsharp/issues/1144