search

fsharp / fslang-design

RFCs and docs related to the F# language design process, see https://github.com/fsharp/fslang-suggestions to submit ideas
518 stars 144 forks source link

Update FST-1027-fsi-references.md #659

Closed smoothdeveloper closed 2 years ago

smoothdeveloper commented 2 years ago

Just clarifying the status on "Handler Resolution", for now.

Click “Files changed” → “⋯” → “View file” for the rendered RFC.

KevinRansom commented 2 years ago

This requirement is specifically about how fsi finds compiler extensions like the packagemanager handlers. It should be trivially possible today using the --compilertool: option.

Probably the most straightforward approach since having a developer specify that on the fsi command line is not easy we could probably add a #r command that downloads a package manager from nuget org and uses it.

However, the desktop compiler as shipped with VS needs to be deprecated, I've been trying for years, but it is hard because the desktop compiler is good. So the best solution is probably to allow dotnet global tools to contain package managers somehow. We probably need to think what the heuristic for that would look like.

As for the specific issue that didn't work. When VS went 64-bit we had to move the compiler tools from :

C:\Program Files\Microsoft Visual Studio\2022\Preview\Common7\IDE\CommonExtensions\Microsoft\FSharp

to: C:\Program Files\Microsoft Visual Studio\2022\Preview\Common7\IDE\CommonExtensions\Microsoft\FSharp\Tools

So if you drop the tool there then it will work again, at least for the desktop compiler,

smoothdeveloper commented 2 years ago

@KevinRansom

It should be trivially possible today using the --compilertool: option.

Confirming this works everywhere I tried, FSI, FCS, similarly it works everywhere (but in VS and also Rider) when you copy an arbitrary extension next to the one Microsoft ships for #r "nuget: ...".

However, the desktop compiler as shipped with VS needs to be deprecated

Does it have an impact with the extension system, which interpreter or runtime it is? Maybe the fine details about it could be reprecised with the current status.

In any case, I have been using extension system without issue with fsi.exe/fsiAnyCpu.exe that ships with VS and the one that comes with "dotnet sdk".

we could probably add a #r command that downloads a package manager from nuget org and uses it.

I refer to this in dotnet/fsharp#8880: Another approach would be for referenced assemblies to be probed as well, it would enable using...

So the best solution is probably to allow dotnet global tools to contain package managers somehow.

It would be consistent with efforts within MSFT that aimed to ship the feature for FSI & VS + Dotnet Interactive; agreed it would be a good move and a good first entry to the UX behind those extensions.

dsyme commented 2 years ago

@smoothdeveloper Are you happy with what's here as suitably clarifying, given Kevin's comments above? Thanks! :)

smoothdeveloper commented 2 years ago

@dsyme I am happy with update, it takes the RFC closer to the actual situation for handler resolution, and preserves the suggested approach, which hasn't been mulled over / implemented.

Main concern for me is still https://github.com/dotnet/fsharp/issues/12895

dsyme commented 2 years ago

Thanks!