Paket depends now on .NET framework (win) and mono (unix/mac).
This is really good because the normal paket.exe console app can run xplat if mono/.net is installed.
For some scenario, like .net core development (or fable) with new dotnet/sdk (new csproj/fsproj), the mono/.net shouldnt be needed.
To remove that deps of paket in these scenario there are some points to address:
Atm ihmo boostrapping and auto-updates are the real issue
notes about console deployment options on .net core
notes about paket, dotnet/sdk, .net core
paket is a strange tool, because atm for restore process, need to be there BEFORE the restore.
But lots of challenges are shared with normal tools in .net ecosystem
There is no builtin
How now .net sdk support external tools? or custom execute code xplat.
Other package manager expect the dev sdk installed, and use that to boostrap:
My current ideas, not in preference order.
support tools at repo level natively in
Why: paket deps doesnt change a lot. paket does.
like now, using native app (SCD) but smarter update mechanism
Why: support and enhance .net cli tools. use that support for paket itself.
Add support of repo level tools to paket and .net cli tools. Use a built paket native (SCD) to boostrap paket (replace previous paket.boostrapper.exe).
Atm i prefer plan C, while is longer than B to implement, add a lot more value with less maintenance long term.
as a note, i volounteer to implement the choosen solution. if someone want to help, will be nice, because tasks can be split
The text was updated successfully, but these errors were encountered:
yes that's another way. two options afaik:
bundled in sdk, as app/package
Technically, yes. we have done that for fsharp.net.sdk, and put inside sdk is just a packaging thing (cli/sdk build script restore a pinned package and unzip in release dir).
Issue is, if there is an error in boostrapper, you need another release of sdk to fix that (and just sdk team can schedule that).
as Sdk attribute
Another possibility, the real issue, is if
Both mean will work only with new msbuild/cli/sdks versions.. and given the churn in sdk tooling and the need for stability, ihmo is not going to be implemented soon..
ok, dotnet cli is adding tools (sdk scooped) in v2.2 (ref https://github.com/dotnet/cli/issues/8067 )
we can use that later for boostrapper. meanwhile need another options for that
And paket can manage tools too, because should be easy. adding per repo tools (who can be used to self-update itself, if the boostrapper is just paket)
the tools are just .net core fdd app published in the
ref a nuspec
<?xml version="1.0" encoding="utf-8"?> <package xmlns="http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd"> <metadata> <id>global.tool.console.demo</id> <version>1.0.4</version> <description>test app</description> <authors>testauthor</authors> </metadata> <files> <file src="bin\Release\netcoreapp2.1\publish\*.*" target="tools\netcoreapp2.1\" /> <file src="DotnetToolsConfig.xml" target="tools\DotnetToolsConfig.xml" /> </files> </package>
and an xmlfile to read the entry points, so commands can be renamed and multiple
<?xml version="1.0" encoding="utf-8" ?> <DotNetCliTool> <Commands> <Command Name="demo" EntryPoint="consoledemo.dll" Runner="dotnet" /> </Commands> </DotNetCliTool>
There is nothing to do at the moment - but as soon as NuGet actually implements this stuff, we should also start so we don't hang behind.
From the empty checklists in both issues, I would expect this to land in 16.0 maybe.
The important question is how the resolving works when we don't control the host (VS or Rider, or VS Code, ...).
@aggieben yes, latest (just today, i was working on it these days), is in https://github.com/enricosada/paket-netcore-testing-as-tool/
should be somewhat done (minus known bugs). please review the PR
@dsyme Atm i think not, because with .net core sdk 2.0 there were some issues to install paket locally in the repo (
if really needed, afaik like https://github.com/enricosada/paket-netcore-testing-as-tool/ works sort of, but i dont reccoment it yet.
I am playing with .NET Core sdk 3.x who support local tools (two preview ago wasnt ok), i'll send a PR soon and that probably will be ok to use, based on prior experience with
You should be installing paket as a .net sdk tool. If you do, it fits right into a dotnet SDK based pipeline:
This is how I use it with all of my work and OSS packages, and it works great.
I should clarify here that this workflow is complete mono/.net framework-free, relying only on having dotnet sdk 3.0 or greater.