Future F# project system #1193
Comments
|
My 2 cents: As far as I know, this CPS is somehow incompatible with MPF/SPS model, and I hope Microsoft will provide clear roadmap on this. Also using CPS might have impact on existing F# tooling, including current F# project system. |
|
It's still very early on the project system side, but we've done a little bit of investigation on the CPS to side (which is not open source) to figure out what it would take to support F#. Explicit file ordering isn't yet supported, but we believe we could add the right extension points to enable it. However, I think the most important thing to focus on, is the move to the Roslyn workspace model (#913) - this would mean that the majority of the shared layer between C# and VB could be just reused for F#. Are there are requirements that F# has that above and beyond language service/file ordering? It would be great to identify those early. |
|
@davkean I think that's the only real extra feature. The ordering can interact with folder support so you have to be a bit careful there (Visual F# Power Tools does a pretty good job of this). Various project system features can require the results of code analysis (e.g. features that inject or adjust code, like the WinForms or WPF designers) - for F# these might indeed come from the Roslyn workspace implementation (basically implemented on top of FSharp.Compiler.Service results). Open sourcing this work would of course be awesome. |
|
To clarify, while CPS (Common Project System) isn't open source, the C#/VB layer on top is: http://github.com/dotnet/roslyn-project-system. Any F# implementation, I imagine, would naturally be open source. |
|
FSharp will likely move to CPS for it's project System. We don't yet have a schedule for it's implementation but we are confident it will happen. |
|
@KevinRansom silly question maybe, but how will this affect other (non-VS) tooling? |
|
@isaacabraham How do you mean? Like Emacs, VSCode, Atom etc? Or VFPT? |
|
The former. |
|
I guess @isaacabraham's question is to know if parts of Roslyn workspace will be reusable for other editors or if those will be tightly coupled to Visual Studio? Is Roslyn workspace actually something which can live outside Visual Studio? Are there longer term plans in terms of evolution on top of FCS and how it is integrated with Roslyn workspace (I assume indexing of symbols / locations in a language agnostic way)? |
|
@smoothdeveloper @isaacabraham I don't think any of this has been decided. Basically as far as I can see the story is very simple: implementing Roslyn Workspaces is necessary to put the Visual F# Tools on the same modern engineering path as the rest of the Managed Languages Team. It also seems like it will be very useful precursor to modernizing the Visual F# Tools project system too. So that's why the Visual F# Tools team are doing it, and that's the full explanation. Whether the F# Roslyn Workspaces implementation then gets a useful life outside of that context is TBD - there's no master plan beyond the above. Certainly it won't hurt to have the implementation around at high quality and it will almost certainly be useful in some form. But let's get to square 1 first. |
|
@dsyme my main point was that we don't make decisions on the project system / format that couples us to reliance on VS-specific tooling. |
|
@isaacabraham In terms of formats I don't think there's any danger of that. |
|
Great - then I have no concerns :-) |
|
I've heard there are plans at MS to introduce upcoming |
|
Regarding the longer term target of getting on CPS, @KevinRansom mentionned (#2400) that CPS explicit ordering isn't not yet on the radar on the owners of CPS. Can we workaround that fact in a simple maner: have a pages in project properties where files can be ordered for compilation. We would display the actual physical file structure in solution explorer but the compilation order can be arbitrarily defined under that page. The thing is that with current VS project system, you also can't have interspersed files in repeted folders (not that it is a great layout), while the command line tooling, I assume, supports that. |
|
The current F# project system, builds the project and submits the files to the compiler in the order they are specified in the project file. The presence of folders does not impact that .... although authoring that is a bit tricky. the problem that CPS gives us right now is that loading an F# project with the files in the right order, would immediately sort them into alphabetical ordering. If the project is then saved ... then it wouldn't even build from the command line. The main advantage of using the CPS project system, is that we can leverage all of the Roslyn workspaces knowledge that is built on top of CPS for C# and VB. We don't really want F# projects to be in any way weird ... so we need the bug fixed. Anyway .... I am working on the pressure to get it fixed, it's not like I haven't worked with the CPS guys before .... they know me quite well. |
|
CPS won't reorder via the virtue of saving a project. CPS only manipulates pieces of the project that have changed, so manipulating of items (such as excluding, or adding an item) via the Solution Explorer will cause issues. It won't, however, change the order of the other items. Given that we let you manipulate the project file - early bits could just let you manipulate via the project file while it's loaded, until the F# tools team works with CPS to get the right extension points in CPS to enable F# scenarios. |
|
Another thing, while the project tree itself is sorted alphabetically - the MSBuild items that are passed to components (such as language service, etc) are not, and appear in the order they were specified. |
|
@KevinRansom /@davkean thanks. Although having the display order "messed-up" (plain alphabetical/file system structure) would be confusing, assuming the order in fsproj remains stable (that requires some amount of logic in F# project system handling) it seems having a separate windows with ability to see / edit order for the project would be a good first milestone, not for release but to get a CPS prototype working. It would be easier with such prototype for people interested to start looking at CPS and further things that can be implemented on top, while also providing useful feedback for Microsoft teams to figure out issues. Are there specific things about linked items (link to files in project, not matching physical location)? I know current VF# solution uses those a lot. |
|
@davkean I thought the |
|
IVsHierarchy determines the ordering of constructs in Solution Explorer, it however, is just a wrapper around CPS's (physical) IProjectTree, which itself is just a consumer of data coming from the project file, the same data that the language service consumes. In CPS (and unlike other project systems) Solution Explorer is just a by-product of changes in the project file. When you add a file to Solution Explorer, we really just manipulate the in-memory project file, publish that data and a bunch of components react, one of them being the Solution Explorer/IProjectTree. Because of above, a service that propagates between Solution Explorer and the fsproj - isn't at the right layer. Solution Explorer isn't the source of truth, the source of truth is the project file. Solution Explorer is just a read-only view of it. I think we'd be better off adding a couple of extension points at a couple of CPS layers that 1) let's you control the order things are displayed in Solution Explorer and 2) one that lets you control the order in which items are persisted in the project file. |
|
@davkean cool, is a netcore release of the I've been working on a netcore fsharp workspace as part of an xplat tooling backend for all of the non VS editors and being able to couple that with the host-agnostic CPS layer seems like it'd be very useful (or am I misguided about that?) It'd probably be pretty useful for Omnisharp too. |
|
Yeah, we've had the same thoughts. Right now, we're not in a state that consumable outside of VS (though it already has a VS and non-VS layer), it's (CPS itself) also not open source. Baby steps though... |
|
Sorry if these seems an obvious question but I couldn't find an answer (#1095) that I could be certain of anywhere. Will VS F# 2017 support folders thanks to being on Roslyn workspaces? Sorry again for the dumb question. |
|
@chaotic-butter No, currently VS 2017 will not support folders in the project system for F#, at least not at release. Perhaps folder support could come into play in a future update, but there aren't any plans for that specific feature. |
|
Oh ok, thanks. What's the recommended way to use folders in an F# project? |
|
@chaotic-butter Unfortunately there is no ideal answer. In VS2015 you can install the Visual F# Power Tools and use the Folder organization feature , however this has some limitations, and at the moment the Visual F# Power Tools are not compatible with VS2017 and I am not sure what the plans are. Another possibility would be to install Forge and use a combination of features from the command line, but this also has its own limitations. The traditional approach and the approach I keep finding myself coming back to -- and I suspect most others as well -- is to edit the fsproj file by hand in combination with working with the file system directly. |
|
@cartermp This is going to be a bit long winded but I really think that folder support is more important than what seems to have become the status quo. With every interaction where I introduce F# to an individual, I become more and more convinced that lack of full support for folders in tooling really does hurt impressions. Regardless of how interesting an individual finds the features of F#, the lack of normal folder support (something which people didn't even consider a "feature" until they came across F#) can't help but be seen as a commentary on quality and completeness, even if technically it does not have anything to do with the language per se. Now, I recognize and really appreciate the work that has gone into the Visual F# Power Tools, however, the maintainers themselves say the following about the "Folder organization" feature:
Independent of VFPT, I also know that there are points to be made on how code organization in F# is different from other languages, but even when I take the time to show how you can express structure through ordering and the benefits of that ordering in terms of avoiding cyclical dependencies, I get the impression that it comes of as if I'm reaching because ordering and folders are not necessarily mutually exclusive. File and folder management is such a basic part of editing code and it keeps coming up again and again. Yet because it is not a big obstacle for the more capable F# developers who tend to be the more active community members, it does not resonate as much in the various channels that the community uses to communicate and therefore the impression is that it is not that big a deal and that whatever methods to deal with the issue that exist at the moment are sufficient. But for many who are new to F#, my impression is that it IS a big deal but that they will walk away from the language before reaching a point where they feel comfortable making their thoughts heard within the community, or they will suffer in silence until they too become as proficient in working around folder support limitations because they believe that speaking up will highlight their inadequacy as an F# developer, because after all "no one else of any note is saying anything". But if you dig deep you will find that there is a long and consistent trail of this being an issue. This has come up in so many other forums over the years that it is hard to track down all the times it has been discussed, but below are just a few examples:
Please take a fresh look at the issue of folder support as a part of any efforts on the F# Project System. |
|
@lambdakris it's really that there are so many other things that need to come first that it's not even worth considering at the moment. Once F# has been moved to CPS after CPS allows project tree ordering it could be implemented.
You misunderstood this. The folder feature was broken, it could go terrible wrong and scramble your fsproj, the more complicated the structure the more horrible of a mess and the longer it'll take you to fix, not to mention the error messages you get in VS don't help you understand what exactly is going wrong. It's a warning against creating a frustrating disaster for yourself, not an admonition against using folders. Personally I'm a big fan of using folders, I use the VFPT feature all the time, but it's gotta sit on the backburner for vs2017 for a while. If the folder functionality is so important you we'll gladly accept a PR to VFPT fixing it and then it can be on by default. |
|
I'm dual sided regarding folder support: For me also, editing fsproj by hand is actually less hassle, even in csproj the GUI tooling is sometimes so slow that getting the change done outside VS in text editor is faster
For users of other languages, file organization (leave alone folder support) in F# is always a controversial topic, I don't feel that folder support alone will drastically change the perception from newbies. The quote on VFPT and feature could be removed, just direct users to create their files in explorer and edit fsproj, this always work. In general, F# projects do benefit from having files organized in folders, although not as much as C# which tend to have a hierarchical matching with namespaces. IMHO we should try to identify the other major points people trying out F# at the beginning face, but folder support would not be the main pain point, given that experienced F# user can diffuse the anxiety about the topic (explain that file ordering is a pro in terms of dependency cycles, and that it will make more sense after using the language more that we don't have a file per class etc.). It seems we should move that part of the conversation to #1339. |
|
@cloudRoutine I actually meant for the third paragraph (about VFPT) and fourth paragraph (about code org) to be read as disconnected. The argument I characterize in the fourth paragraph was not inferred from the VFPT warning/disclaimer, rather it is an argument I had seen characterized on Stack Overflow on occasion and in CodePlex back in the day. Edited my original comment to hopefully be more clear and neutral. |
|
So there's still a task "Update OSS all FSharp.Core builds to use project.json" listed on F# for CoreCLR Status, which is linked directly from readme.md file displayed at https://github.com/Microsoft/visualfsharp. I assume that's no longer accurate? |
|
@davisnw Yes, it's no longer accurate. |
|
@cartermp |
|
@dsyme i find wiki really useful for projects. but:
Well, it's write enabled for everyone. so just click edit. PR give more confidence to send contribution, because ppl (me too) are scared to directly edit someone else work. But state on wiki "IT'S OK" help, and tell usual contributors to do so (the one who will probably edit that) too. @dsyme @cartermp that said, wiki alone doesnt help to show current work to be done, roadmap etc (that's hard to know in vf# repo). There is roadmap issue, but github issue are lots in comments and always stale (because just the author or admin can update it). So @cartermp @KevinRansom maybe now that vs is rtm'ed, can we improve that communication stuff a bit? A wiki page with short/long roadmap linked to sigle issues help a lot. we can help maintain that. Or use github project/roadmaps too but that not help a lot, because it become a bit container soon, not showing future work, if not really really used (afaik you do your prioritization/todo list internally) |
|
Part of the issue with using the Wiki is that our roadmap has been changing quite rapidly recently. Things we may have initially been on the hook for implementing may shift to other teams, or something else which is a higher priority comes up (e.g., setup authoring for VS, which basically sucks the air out of the room due to the amount of work involved). I prefer a model of fairly regular announcements about what we're working on and what our priorities are, because remembering to update a wiki is a bit more difficult, and it's also harder to spread the message that way. Communicating engineering status is also a bit less useful via the wikis as well - a tracking Issue is more effective there. |
|
@isaacabraham No external tools use the project system. So I would assume not at all, however, if external tooling for C# starts to use the project system directly then F# tooling could follow suit. |
|
@KevinRansom since the host agnostic layers of CPS are netcore compatible I already plan on using the roslyn-project-system for xplat F# tooling regardless of whether C# does or not. The inability to effectively manage project configuration state is currently a big shortcoming of the non VS/monodevelop F# editor tools. |
|
@cloudRoutine You need to separate http://github.com/dotnet/roslyn-project-system from CPS. The former is the C#/VB extensions on top of CPS. CPS itself is not (yet) usable outside of Visual Studio. |
|
@davkean i thought the maybe I got some of the nomenclature wrong, it's hard to keep track of all of these APIs I started working on a prototype splitting the layers using the roslyn-project-system as reference, but the lack of netcore support is disappointing. Xplat (w/ mono) is an unfortunate caveat |
|
CPS is made up of more than those dlls. Microsoft.VisualStudio.ProjectSystem is only a reference dll containing interfaces and helper classes. |
|
@davkean Then CPS was wrong term, I was trying to do a core project system implementation that could work as a part of a language server to provide F# tooling to a variety of editors. And then the connection to all of the VS layer APIs would be in a layer built on top of that. That way all of the F# tooling could leverage the same system. But if you think that's not feasible I'll have to upgrade the bespoke system I wrote before so I can integrate it with F# roslyn workspace I wrote. It's been hard to figure this stuff out since the docs are sparse to non existent for all of this stuff. |
|
Given the current state - I don't see as feasible. Some of the dlls you need (ie the actual implementation of Microosft.VisualStudio.ProjectSystem), only ship as a part of Visual Studio. We want to get it to where people can do exactly what you are trying to do - but we're >1 year away from that. |
|
cool thanks, focusing on only using the |
|
You might want to hook up with @DustinCampbell I think he may have some ideas about using workspaces in other editors from his vscode work. |
|
Closing old discussion; the VS project system which loads .NET SDK-based projects is implemented and supports F#. |
Since project.json is off the table and https://github.com/dotnet/roslyn-project-system is the new rising star, I wonder what the plans for F# are. The new project system only talks about C# and VB. How can F# fit into the picture given that this language has a bit different requirements?
/cc @davkean @enricosada @KevinRansom @isaacabraham @dsyme
The text was updated successfully, but these errors were encountered: