Please contribute any notes that made your contributions easier here.
Note that historically, the bulk of the development occured on Windows before dotnet got cross platform. Since Paket 12 only the .NET SDK is required, on every OS.
build.cmd and build.sh run build.fsx with dotnet fsi. FAKE is used as a library only: there
is no FAKE runner to install, and its version no longer has to match the .NET SDK. The FAKE modules
come from the BuildScript group of paket.dependencies and are loaded through the scripts that
the paket generate-load-scripts call in build.cmd / build.sh writes to
.paket/load/net10.0/BuildScript/, so running dotnet fsi build.fsx directly assumes one of those
entry points has been run at least once.
Targets and parameters are unchanged, so ./build.sh <Target> [key=value ...] keeps working as
before: the script turns the key=value arguments into environment variables itself, which is what
the FAKE runner used to do, and passes the target name to FAKE as --target through the execution
context it creates. Only one target name is accepted.
The build no longer needs Mono: Paket 12 runs as a .NET tool only, and the paket.exe stub of
src/Paket.LegacyStub builds against the .NET Framework reference assemblies package.
Some pointers to help efforts to foster the F# Interactive extension ecosystem:
- integrations in IDEs:
- Rider: take inspiration from how Rider does autocomplete for nuget package in
#r "nuget: " - Ionide setting to use FSAC path to pass as an extra
--compilertool:argument to FSI - Proposal to ship the paket extension with FSAC
- Rider: take inspiration from how Rider does autocomplete for nuget package in
- keeping the documentation refering to the extensions mechanism in shape:
- Discussion about a stable location / mechanism so extensions are loaded in a single place by all tooling and variants of F# Interactive
This is overall a stress free process, you can take example on previous PRs: