RFC: Changes in Paket Global Tool

[Krzysztof-Cieslak]

Problem

At the moment we can install Paket as a global .Net Core tool with dotnet tool install paket -g. It's really nice delivery strategy consistent with the direction in which whole .Net world is moving and consistent with the tool distribution strategies in many other ecosystems.

However it currently installs particular version of Paket which means

1. You can't pin version of Paket in the repo - it's not respecting Paket version pinning in paket.dependecies file
2. You don't get updates if you don't pin Paket - getting updates often was thing in Paket since I started using it - either by old school build scripts calling paket.bootstrapper.exe back in the days, or by using Bootstrapper in magic mode nowadays.

This is hugely problematic because it's different from the "normal" Paket behavior.

Proposed Solution

My proposal would be distributing Paket.Bootstrapper (in magic mode, called paket) instead of Paket as a global tool.
This would solve per-repo versioning problem we have right now - Bootstrapper in magic mode is either respecting pinning in paket.dependencies files or getting latest version. In such case updates of the Paket .Net Tool (dotnet tool update paket -g) would be necessary only when we have Bootstrapper update (which is not as often as Paket update)

Work plan

• Update Bootstrapper to .Net Core, pack as tool (Partially already done - https://github.com/fsprojects/Paket/blob/master/src/Paket.Bootstrapper.preview3/Paket.Bootstrapper.csproj)
• Distribute Bootstrapper on Core as a Global Tool called paket (due to behavior of the Bootstrapper Magic Mode this shouldn't be a breaking change for users)
• Update documentation to make Bootstrapper on Core as Global Tool suggested way to use Paket - I personally think it's step forward from current state, will ensure that Paket is working "as expected" in modern .Net ecosystem. Pushing global tools seems to be working well for FAKE too.
• Make some developer advocacy effort (blog post, talks on the conferences, etc) to promote this new way of distributing Paket. As shown by some recent twitter conversations people don't even know about Magic Mode and it's been introduced years ago.

CC: @forki @isaacabraham @baronfel @vbfox @enricosada

[matthid]

Shouldn't we just wait for SDK v3 which apparently introduces repro-local tools or something like that?

Would the bootstrapper download the mono/framework dependent tool as today? -> You still need mono/Windows?
If not which version of paket does it download and run?
If "portable", how does the bootstrapper find a dotnet runtime, and which version should we take?

[Krzysztof-Cieslak]

Shouldn't we just wait for SDK v3 which apparently introduces repro-local tools or something like that?

I think current proposal for repo-local tools has its own problems but, TBF, I think it's orthogonal issue - I'm worried about people using/wanting to use global installation and having bad behavior.

Would the bootstrapper download the mono/framework dependent tool as today? If not which version of paket does it download and run?

I think we should download Core version of Paket (something something "Core is new .Net Framework"). Latest or pinned, just like magic mode bootstrapper does it nowadays.

how does the bootstrapper find a dotnet runtime, and which version should we take?

We probably could use the same version of dotnet runtime that bootstrapper is running on, I guess we should be able to get this information (?)

[baronfel]

We probably could use the same version of dotnet runtime that bootstrapper is running on, I guess we should be able to get this information (?)

you also have the CWD of the user when they would run paket globally, and the bootstrapper should invoke dotnet paket from that directory so that the user's configured .net sdk preferences are adhered to.

[forki]

Ok let's do this!

[jbaehr]

On a build server, I have some concerns with the global tool. It may run different jobs, requiring different versions of paket. Honestly, I'm quite happy with the isolated, self-contained nature of the local paket. Allowing different versions of the .NET-Runtime in parallel as well as self-contained application deployment is also a huge benefit of .NET Core.

Regarding the two problems pointed out in this issues description:

1. You can't pin version of Paket in the repo - it's not respecting Paket version pinning in paket.dependecies file
2. You don't get updates if you don't pin Paket - getting updates often was thing in Paket since I started using it - either by old school build scripts calling paket.bootstrapper.exe back in the days, or by using Bootstrapper in magic mode nowadays.

I'd like to propose a different approach:

1. stay with the local .paket dir, containing the paket executable.
2. using the paket.bootstrapper.proj approach from @enricosada (see Full netcore #3183), simplified in that it dotnet tool install paket --tool-path . directly, instead of installing the bootstrapper. You don't need to check any executable into your repo any more, just the msbuild files.
3. Update http://fsprojects.github.io/Paket/paket-and-dotnet-cli.html to promote paket.bootstrapper.proj instead of paket.bootstrapper.exe/magic mode, as the later requires mono on Linux. This again prevents you from using Microsoft's NetSdk-docker images out of the box.

The first issue, of not being able to pin paket's version within the repo is addressed: Use a paket.bootstrapper.props instead of paket.bootstrapper.exe.config. Reading from paket.dependencies from msbuild should be possible, too, but I haven't look into it.
The second issue that comes from the global tool, not getting updates unless pinning paket's version, is addressed to: Just don't use a paket.bootstrapper.props (or at least, don't set the paket version in it) and each time no paket executable is present, the latest version with be downloaded during dotnet restore. For the local project only, i.e. not interfering with anything else on the system.

I have such a setup running on a mixed Windows/Linux environment and I'm quite happy with it.

• No global setups upfornt
• Isolated settings per repo/project
• Usable from Windows Worksations as well as Linux build agents, using vanilla .NET SDK docker images,
• usable with private/internal nuget feeds from machines without internet access
• one dotnet build to rule them all

I can prepare a PR with my bootstrapper.exe-free variant of paket.bootstrapper.proj (just tell me where to place it; needs to become an additional release artifact, too) and updates to the above mentioned docs (this is what #3516 is all about, right?)

[matthid]

Now that local tools have arrived and work reasonably well, I think we should get rid of the bootstrapper and if anything make Paket update/edit the manifest version.
Is there really any need to keep the bootstrapper?

[Krzysztof-Cieslak]

1. As far as I know they don't provide always update ('*' version) mode that bootstrapper does when used without pinning
2. They're not using pinning from paket.dependencies file which is obviously better than some random json file created by MSFT... and is breaking change for many users

[matthid]

As far as I know they don't provide always update ('*' version) mode that bootstrapper does when used without pinning

Users should get into the habbit of pinning the version anyway. We cannot keep telling people to use a lockfile and then use a floating version in paket.

They're not using pinning from paket.dependencies file which is obviously better than some random json file created by MSFT... and is breaking change for many users

It isn't breaking, we'd just change the recommendation at this point. The rest is not really an argument. Can you say "why" having a 'common'/standardized way to add dotnet based tools to your repository is a bad thing? Or "why" we should continue investing time building our own?

Having the version in the deps file was imho always a "hacky" way of doing things, as long as you have to manage the paket version by hand it wasn't really "that" useful (you could have used a bootstrapper argument just as well in build.sh for example). Now you can use dotnet sdk just like lots of other tools.