Full netcore

[enricosada]

make paket and paket.bootstrapper as .net sdk tools.

idea is users can maintain the paket.bootstrapper (github download, etc) flow with minimal noise (one text file .paket\paket.bootstrapper.proj and installed as dotnet restore .paket).

but because paket is a sdk tool too, can be installed normally as dotnet tool install.
The bootstrapper is used to download locally the nupkg (needed by sdk) and install it locally as native executable (so bypassing nuget client as much as possible)

more info in https://github.com/enricosada/paket-netcore-testing-as-tool

TODO

• make the #ifdef just normal args, if make sense
• back appsetting if possibile with system.configuration like argu does
• reenable cache (now is doing bootstrapper -f)
  • disabled the cache by default, not yet implemented
• enable test from Support pack of global tools (PackAsTool) #3208

[matthid]

• I'd like to see the build-script changed in a way such that we push the next version including this with the netcore version (as I'm still a bit skeptical that this works)
• As mentioned in slack, I'd like to see a dotnet-paket cli tool (mainly for experimenting with fake)

[enricosada]

I'd like to see the build-script changed in a way such that we push the next version including this with the netcore version (as I'm still a bit skeptical that this works)

yes, i'll do that (i want this PR green :D).
mostly mean use .net core sdk 2.1.300-preview2 and pass /p:PackAsTool=true to dotnet pack

As mentioned in slack, I'd like to see a dotnet-paket cli tool (mainly for experimenting with fake)

I'll do that, but i want to choose if do a dotnet-paket.cmd/.sh or a .net exe.
In my idea, that will do just a wrapper to execute the real .paket/paket inside repo:

• find in the working directory hierarchy for .paket/paket.
• run that passing original arguments.

plus a paketg as global tool, for stuff like init (no need for dotnet paketg, just paketg will be enough)

[enricosada]

current status:

• sdk integration works
• dockerized app (as best i know to reuse layer) till the alpine

i have an issue with sdk 2.1.300-preview2 because packages dir is not used by references, but i think is related to sdk preview, not this netcore PR.
i'll open another PR to check the behaviour, maybe was changed from current stable 2.1.105

[ctaggart]

@enricosada, how is this going?

[enricosada]

I schedule some time Monday and Tuesday for it. Hope will be enough to finish it

[matthid]

@enricosada What's missing here and can I somehow help? I just started to update some of the old stuff here: #3324
After I'm finished it should be easy to create a dotnet tool, such that the following workflow would work:

1. fake build
2. the build script executes dotnet tool install --... paket
3. We have to hook the path into the targets file:

   Paket/.paket/Paket.Restore.targets

   Line 17 in 6ec1622

   <PaketExePath Condition=" '$(PaketExePath)' == '' AND Exists('$(PaketRootPath)paket.exe')">$(PaketRootPath)paket.exe</PaketExePath>

Note that this doesn't need updates to paket itself (besides the netcoredistribution) and is therefore a "simpler" approach than this.
Do we want direkt support for dotnet tool in paket for versioning? I guess the answer is yes, but we can add this later and make the above workflow easier.

Alternative to dotnet tool install would be to just add the nuget package to your paket.dependencies and then use dotnet <path to paket.dll> in the paket targets. We could have paket.sh and paket.cmd bundled in the package. ./packages/build/paket/paket.sh --help is a bit worse than .paket/paket.exe --help but at least everything is versioned in your dependencies file.

What do you think?

[nojaf]

Hi @enricosada, I've looked at your repo.

I like method 5:

dotnet tool install paket --version "[1.2.5-netcore]" --tool-path ".paket" --add-source https://www.myget.org/F/paket-netcore-as-tool/api/v2

and use paket as we always do.
How do updates fit in this scenario?

[forki]

Is this ready?

[enricosada]

@forki nearly done, working on it.
at first, will be making the current paket and paket.bootstrapper nupkg valid dotnet tool.
Current packages layout with paket.exe/paket.bootstrapper in tools doesnt change, so is backward compatibile.

in a following PR i'll add the boostrapper script.

[enricosada]

@nojaf the new bootstrapper script will upgrade paket too, to choosen version

[enricosada]

ready to review (/cc @matthid )

i built a local package and pushed to myget, and i updated https://github.com/enricosada/paket-netcore-testing-as-tool/ with it, so can be tested easier (before merge).

there are some minor issues (see the https://github.com/enricosada/paket-netcore-testing-as-tool#known-bugs ) but can be fixed later, having on github helps to test github download too

[enricosada]

latest fix unix/osx support

[enricosada]

disabled the cache by default

[enricosada]

added also the upload of Paket nupkg to github release.
That package will be used when download strategy is github

[enricosada]

test failures are unrelated, already exists in master.

As for now, i am satified with this (it's no more wip), the only thing missing are:

• proxy support (fails in @vasily-kirichenko environment)
• cache support. atm is disabled by code, but that's just an enhancement

While paket can be installed as cli tool to some dir with a command, ihmo that should be not the reccomended way.
The new proposed flow for repo is in https://github.com/enricosada/paket-netcore-testing-as-tool/ with a .paket\paket.bootstrapper.proj who will pratically replace the magic mode paket.exe or the commit of paket.bootstrapper.exe

That support:

• dotnet build et similar works from clean clone (it will automatically bootstrap, and do restore as usual)
• .paket\paket.bootstrapper.exe.config for customization (like pin the paket version, or feeds)
• dotnet restore .paket to just bootstrap paket as .paket/paket or .paket\paket.exe

as a note, flow currently do:

1. install paket.bootstrapper as cli tool in .paket dir (support only nuget feed as source)
2. run paket.bootstrapper to install paket as cli tool in .paket dir (support github/nuget sources)
3. from here, everything is as usual, just .paket/paket (or .paket\paket.exe) is a native binary instead of a .net assembly

we can discuss later if we want to just install paket as cli too, but we lose github releases and possibly cache (but maybe the global nuget cache it's used by dotnet tool -i)

/cc @forki @matthid

[matthid]

@enricosada Can we downgrade FSharp.Core for the Paket.Core library? I'm fine with updating Paket to 4.5.2 but Paket.Core gives me a headache right now in Fake :(

Also we have a problem in the dependencies:

[enricosada]

@matthid good catch, i'll check.

also with v4.5 i am a bit scared of issue with AsyncPrimitives not found

[matthid]

Just for the record this is what I saw:

Took me quite a while to realize that this was due to the paket.core upgrade.
I think what happens is:

• The Runtime is unifying dependencies to the highest (4.5.0.0)
• SDK thought 4.3 if fine (due to dependencies fulfilled

-> error at runtime with a completely unrelated stacktrace

[matthid]

Even worse with an older (2.1.2) runtime all you see is:

[enricosada]

@matthid sent PR #3373

Doesnt fix the nuspec for netstandard, but at least doesnt use fsharp.core v4.5

[jbaehr]

I just tried this /paket.bootstrapper.proj-approach as documented here and it works really nice! However, despite this branch being merged, there is no updated Paket.Bootstrapper package on nuget.org (latest version is 5.164.0 from 2018-05-17)
I used the 5.180.414 from @enricosada's MyGet feed.

@enricosada @forki Is there a reason not to update the "official" bootstrapper package?

[jbaehr]

Never-mind. I now use the paket.bootstrapper.proj approach as outlined by @enricosada (which is really great!) but I dotnet tool install paket directly, i.e. no separate bootstrapper at all; paket.bootstrapper.proj is the bootstrapper.