Hey everyone,
I was curious about the high-level roadmap for the fork—specifically if the vision is to re-architect the engine before the first release, or if the plan is to deploy under a new name first and refactor incrementally from there?
Just trying to get a sense of the project’s philosophy as things get moving!
There's no plan for rearchitecting at this point, although growing outward into other platforms might be appealing for some. I think those kinds of things will depend on who wants to invest their time and what their goals are.
What I will say is that .NET Interactive's design and architecture were guided by a significant amount of collaboration with folks at some of Microsoft's data and languages teams as well as educators and folks at Jupyter. That collaboration produced a lot of depth that isn't immediately apparent at the surface level of "notebook that can run different languages."
And so from that perspective, my take is that a lot of the value of a community continuation of the project is that people who've invested in this don't need to migrate their assets. If backcompat isn't a goal then I think a lot of the value of continuing the project is lost.
The idea of building a core kernel (equivalent to the dotnet-interactive tool) on another platform (say written entirely in TypeScript and targeting node) isn't a rearchitecture at all. It's just an extension of the existing architecture to other platforms.
A drop in replacement would go a long way and I think that's actually the cheapest thing to achieve. But please correct me if I don't seem to understand something.
Agreed.
I think swapping out a different VS Code extension that's 100% compatible* with existing notebooks is fairly straightforward.
The caveat there is that code in those notebooks that references packages whose namespaces will change will need to be updated.
e.g. using Microsoft.DotNet.Interactive etc. should potentially change. At least the package names need to. These ship as part of the tool itself though, so no #r nuget needed to load them. So we could keep the namespaces but rename (which is required) the packages.
