RFC: Changes in Paket Global Tool

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

[forki]

Ok let’s do this!

[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.