[RFC FS-1026 Discussion] FSI Reference Model and Extending #r

[cartermp]

This is the discussion for RFC FS-1027.

[cartermp]

From @forki:

how does fsi know which #r providers are available? In
the prototype we created a dll with the paket provider. If it's in same
path as fsi then it hooks in. The dll contains a type that's marked with
special attribute so that fsi can find it with reflection.

[smoothdeveloper]

The other strategy to look into is to also scan the assemblies that get #r'ed, but haven't been able to make that happen yet.

It would be good to add some clarifications in the RFC on expected behaviour with transitive loaded scripts (a.fsx loads b.fsx loads c.fsx), right now there is a test which fails in the PR because presumably FSI doesn't handle it the way we would expect for it to work without surprise: https://github.com/forki/visualfsharp/tree/4b42af3dc7470b3d837ac13c32892249feceb3df/tests/fsharpqa/Source/InteractiveSession/Paket/transitiveloadscripts

[cartermp]

@forki Here's how I see it:

For NuGet, the prerequisite will likely have to be one of:

• Visual Studio
• Visual Studio for Mac/Xamarin Studio/MonoDevelop
• .NET Core Tools

Since those install the bits in a known place where we can look. If we can't find it in those places, we'll likely have to spit out an error message.

For Paket, I'm inclined to say that we'll have to load a Script which will then download and install Paket if it's not already on the box, in the project or solution directory. I don't think that would be too complicated.

[dsyme]

Generate a set of Reference Assembly and Implementation Assembly references in the ephemeral script, using #r "path-to-ref-assembly" and #r "impl: path-to-impl-assembly""

It's possible we might need to know when something is "only" a reference assembly. Currently #r treats something as both reference and implementation. So I think we may need #r "refassem: ..." for those package loader script generators that know the distinction

[dsyme]

... When FSI encounters this script, it will: ...

It's important that the RFC capture that all this is relevant at design time, i.e in the IDE. Indeed the default behaviour of the IDE tooling in the presence of these #r "paket: ..." etc. is really crucial to get right.

[forki]

Don't make it too complicated. I don't suggest to put paket into the VS box. I suggest the following: we change the fsi / FCS like in my prototype so that it scans for dlls in local path + PATH + some other blessed path. When it finds a dll which contains the marker attribute then it will just load it via reflection. It will be the user's job to put the dll over there. For paket we are basically ready. This will work in ionide, fake, fsi,.... If one day someone will implement the search for nuget then it would work the same way. Users would need to put a specific dll into one of the scan paths and it's all set up. If we ship sich a paket dll or nuget dll in the VS box is not important, but the loading mechanism is. @dsyme please take a look at the PR and let us know if that's OK Am 07.03.2017 18:33 schrieb "Phillip Carter" <[email protected]>:

…

@forki <https://github.com/forki> I'm interpreting this as two questions: 1. What does FSI understand by default? 2. How does FSI access the bits needed to execute the correct #r directive? For NuGet, the prerequisite will likely have to be one of: - Visual Studio - Visual Studio for Mac/Xamarin Studio/MonoDevelop - .NET Core Tools Since those install the bits in a known place where we can look. If we can't find it in those places, we'll likely have to spit out an error message. For Paket, I'm inclined to say that we'll have to load a Script which will then download and install Paket if it's not already on the box, in the project or solution directory. I don't think that would be too complicated. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <https://github.com/fsharp/fslang-design/issues/167#issuecomment-284796678>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADgNBciYoA6PHFJUDhXV_e9s8v200DFks5rjZTjgaJpZM4MTPcG> .

[dsyme]

Don't make it too complicated. I don't suggest to put paket into the VS

I totally agree with this (though the design-time behaviour just needs to be spec'd in the RFC)

When it finds a dll which contains the marker attribute then it will just load it via reflection

This is OK (it's like type providers) but we should note that it may potentially require restarts if conflicting versions of the DLL exist (unless Assembly.LoadFrom is enough to keep them distinct).

[cartermp]

Design-time is a bit interesting in my mind:

1. Look for the tool (NuGet, Paket) on the PATH (or some other blessed location). If it can't find it, error out.
2. Call out to the tool to fetch packages and resolve dependencies.

From that point, I think one of two things could happen:

1. Generate an ephemeral script which has the references and #load that script to get symbol information for IntelliSense.
2. Some implicit #r done in the background.

I'm more in favor of the first, because when the script is executed in FSI, we can just execute that script and have references.

[dsyme]

I think we do this:

"Generate an ephemeral script which has the references and implicitly add that as a #load'd script to the current script. Everything else stays the same as existing script editing"

Like all script editing this is independent of whether FSI.EXE is even active - for example one might be editing a script for use with Azure Functions or some other script execution engine, not even on the dev machine.

[forki]

I wonder why the RFC is for both package manager support and .NET core libs. We should split that and tackle both in different RFCs. Basically we can add dependency manager support for net461 right now, but the .NET core stuf with "#r ref" and "#r impl" will take a long time!

[smoothdeveloper]

I agree with this, I guess the concern was not to pick a design which would preclude netcore support later but this is not what is happening.

[dsyme]

I agree with this, I guess the concern was not to pick a design which would preclude netcore support later

I think that's exactly right. Though I also think it's important to do the whole deal and prove that this is "right" for .NET Core as well. Intuitively we know it is, but it feels like we should do this across both .NET Core and .NET Framework to be certain, and to drive the completion of the .NET Core scripting model in a clean way.

[smoothdeveloper]

@dsyme will we hold on F# 4.1.1 or F# 4.2 release until .NET Core enables support for FSI (and we implement it completely)?

It seems we could ship first iteration of this, useful to all clients running on full framework, and adjust remaining parts when .NET Core enabled FSI ships.

[dsyme]

@dsyme will we hold on F# 4.1.1 or F# 4.2 release until .NET Core enables support for FSI (and we implement it completely)? It seems we could ship first iteration of this, useful to all clients running on full framework, and adjust remaining parts when .NET Core enabled FSI ships.

I don't know. I know that Kevin Ransom is keen to use this as a forcing function to get F# .NET Core scripting sorted out, and since the Visual F# Tools repo is on the critical path for this (as it should be) then it might be that it's sensible to wait until at least a POC is done for .NET Core

[forki]

#r ref: and #r impl: are things that should be discussed with the C# team. csi.exe will have the same issues right? @KevinRansom did you already discuss it?

For the dependency manager support things are much clearer to me now. The only thing left (from my perspective) is where fsi / editor would scan for extension.dlls and wheter we want to use the marker attribute that @smoothdeveloper introduced.

[pr-yemibedu]

Hello,
Since some developers like to be lazy about some things they type, they may favor the one or two letter version:

• #ra - reference assembly
• #ia - impelementation assembly
• #pr - projects
• #pa - package
• #tp - type provider

They coincide with what has already been mentioned. Otherwise you can pull all those two letter mnemonics in the soft #r id:

• #r "ra ../A"
• #r "ia ../B"
• #r "pr MyProject"
• #r "pa paket"
• #r "tp CSV"

Hopefully something good will come of all these options. Thank you. Good day.

[realvictorprm]

I really want to see this feature and I'm glad that we discussed and partly implemented it already :) So thank you community!

Please keep this up!

[KevinRansom]

Me too ... it's next but one on my list of things to do.

[dsyme]

@KevinRansom Can you write out the steps that you think need doing? So we're not gated on you for this one? thx

[isaacabraham]

Just read the RFC.

I was more thinking along the lines that the project load would load in an entire project e.g `"#r project: myproj.fsproj" - scan the msbuild file, load in all dependencies and referenced assemblies, before loading in the files in the project in the correct order.

This is a common use case and would be very useful. In some ways this is similar to the project load described in the RFC except this wouldn't reference the compiled outputs of the project but rather the files on disk.

[dsyme]

A quick question on this RFC: - is there a way to use non-nuget.org nuget feeds in #r "nuget: ..."?

I checked the RFC and couldn't spot anything

https://github.com/fsharp/fslang-design/blob/master/tooling/FST-1027-fsi-references.md

[KevinRansom]

@dsyme, in the summary:

The following extensions to #r are proposed:

a) built-in:

#r "project: <project-name>"
#r "impl: <path-to-implementation-assembly>"
#r "ref: <path-to-reference-assembly>"
b) via .dll extension (see Handler resolution);

#r "[dependency manager]: <dependency manager command>" like
#r "paket: <paket command>"
#r "nuget: <package-name>, <package-version>"
This extends the "language" of #r to support implementation and reference assemblies, NuGet packages, Paket dependencies, and potentially more.

[KevinRansom]

and impl and ref are not a thing.

[dsyme]

Right but I want to use a different nuget feed?

Hmmm Diego says in .NET Interactive notebooks I can do this

#i "nuget:[the source or folder]"

[KevinRansom]

Oh you can do that in fsi

#r "nuget:RestoreSources=https://dotnet.myget.org/F/dotnet-corefxlab/api/v3/index.json"
#r "nuget:Microsoft.ML,version=1.4.0-preview"
#r "nuget:Microsoft.ML.AutoML,version=0.16.0-preview"
#r "nuget:Microsoft.Data.DataFrame,version=0.1.1-e191008-1"

[KevinRansom]

oh that should be nuget:

[KevinRansom]

notebooks can do it because they are using us :-)

[dsyme]

OK cool I'll edit it into the RFC.

[dsyme]

Well, this RFC is the general mechanism - @cartermp I guess we should have a separate section in it for the things supported by #r "nuget:"?

[KevinRansom]

@dsyme, we are going to have a different syntax in notebooks. Although it's not yet decided what that is going to be. Reasons ... C# and tool-building. Paket, similarly has an entirely different syntax.

currently the notebook uses:
#r "nuget:blah,version"
#i "some restore source"

But we don't really think we are going to stick with that.