Potential breaking changes in .NET Interactive dependencies

[colombod]

With the las published packages a lot of big changes in command parsing. This might create issues at runtime.

The interactive extension should update to latest if possible, also adopting the .dib based approach to install extension is advised, the interface based discovery is not ideal and introduces more issues, this extension could be built without dependencies on .NET Interactive by using convention based formatting and .dib to load the extension.

[kMutagene]

Thanks for the heads-up.

this extension could be built without dependencies on .NET Interactive by using convention based formatting and .dib to load the extension

It must stop being its own package though if i understand the docs correctly, because there has to be an attribute on the type that gets the custom formatting, the formatting code must be in the source of the core lib?

[jonsequitur]

The extension isn't currently broken as far as I can tell.

[jonsequitur]

It must stop being its own package though if i understand the docs correctly, because there has to be an attribute on the type that gets the custom formatting, the formatting code must be in the source of the core lib?

As long as the only notebook behavior you want to customize is formatting (which appears to be the case with Plotly.NET), you don't need a separate assembly or a separate package at all, nor do you need to embed a .dib file to register formatters. You can follow the convention-based TypeFormatterSourceAttribute approach, remove the dependency on .NET Interactive libraries entirely, and therefore remove future version incompatibility problems.

You can see examples of this approach here.

[kMutagene]

@jonsequitur That's what i was thinking, thanks. I'll look into it

[jonsequitur]

Let me know if you want a hand or if you have feedback on the approach. And if you want to contribute F# sample code to document the convention-based approach, I'm sure others would find it helpful.

[kMutagene]

@jonsequitur I finally had a first go at this, and I'd love some guidance on how to actually test this. I have implemented the (I think) equivalents of the no-dependency attribute-based formatting shown for C# in your linked docs:

Plotly.NET/src/Plotly.NET/InternalUtils.fs

Lines 134 to 142 in ffe000b

	[<AttributeUsage(AttributeTargets.Class)>]
	type internal TypeFormatterSourceAttribute(formatterSourceType: Type) =
	inherit Attribute()
	let mutable preferredMimeTypes : string[] = [||]
	member this.TypeFormatterSourceType = formatterSourceType
	member this.PreferredMimeTypes
	with get() = preferredMimeTypes
	and set(v) = preferredMimeTypes <- v

Plotly.NET/src/Plotly.NET/ChartAPI/GenericChart.fs

Lines 592 to 608 in ffe000b

	and GenericChartFormatter() =
	let mutable mimeType = "text/html"
	member this.MimeType
	with get() = mimeType
	and set(v) = mimeType <- v
	member this.Format(instance:obj, writer:TextWriter) =
	match instance with
	| :? GenericChart as c ->
	writer.Write("LOL!")
	true
	| _ -> false
	and GenericChartFormatterSource =
	member this.CreateTypeFormatters() : seq<obj> =
	seq {
	yield GenericChartFormatter()
	}

but no formatting is applied in the notebook i test this in, and now i am not sure how to proceed/troubleshoot.

[jonsequitur]

As far as I can see the code looks correct. Have you confirmed that the formatter source is being called at all?

Here's an example test. There's no F# equivalent but adding one in this project might surface a bug.

[kMutagene]

@jonsequitur I tried to isolate the issue more and ported that test, however it just tests if the formatted string is correct, which we already know that it is not. How can i dig deeper and test whether the custom attribute is detected correctly?

For reference, here is the (failing) test

[jonsequitur]

If you can hit a breakpoint in the custom formatter source when it returns your formatter, then it's being detected correctly. If you can set a breakpoint in the custom formatter, then it's being recognized as valid for the type and MIME type you're requesting in your example code.

The easiest way to debug your code is to load a locally-built package and before you run any code in the notebook that would trigger loading of the formatter (which will happen lazily when it first sees a given type), run this:

System.Diagnostics.Debugger.Launch()
 ```