Discussion: Official guidance on how to use Paket with .NET Core?

It seems like users of Paket waited a long time to use it without the dependency on Mono, and we’ve been able to do so for a few months now. However, it’s not clear according to the docs whether there is a preferred method of using Paket in this new .NET Core world. Is it better to use it as a global tool? Or install it as a local tool in the /.paket directory and commit it?

My personal opinion is that we should encourage the use of Paket as a global tool. It seems like package managers in other language ecosystems don’t require committing the package manager to the repo. I also think that it makes for a better user experience (i.e. paket add blah vs ./paket/paket add blah).

Do you have any thoughts on this?

[NatElkins]

@slang25 Using it as a global tool does work for me. To get it to recreate the Paket.Restore.targets you need to run paket restore -f (if you’re already using Paket), which unfortunately does a full restore again in addition to recreating Paket.Restore.targets. Would be nice to have an option to ONLY overwrite the Paket.Restore.targets for this particular scenario.

What I’d like to see is lowering the friction of being able to use Paket immediately, from command line, with just a couple of one-liners (and not having to edit or download anything manually). A lot of the steps to get started with it now make sense if you’re coming from the .NET community, but aren’t obvious if you’re totally new to .NET/F#/MSBuild.

Here’s my experience using Paket as a global tool from command line on macOS:

(warning: the GIF is a little long/slow for some reason. Please bear with it for a bit).

You can actually see that it works okay. The only major snafu is that it doesn’t add a reference to FSharp.Core by default, which can cause issues. On the plus side though, the user experience is pretty good:

1. Install Paket with dotnet tool install -g Paket
2. Make your directory
3. dotnet console new -lang F#
4. Start using Paket with paket init
5. You can then do dotnet run, which will work.

If you add a package though using paket add {PackageName} and then do dotnet run, it fails. I wonder if it would be better for user experience to add a reference to FSharp.Core to *.fsproj files by default (but print an appropriate warning, similar to what’s printed today). And make this configurable via some configuration file.

A few open questions:

1. Do we think people would actually find this easier? I personally think so, but I’m Paket is used in a lot of different ways and this might not be compatible with them.
2. If this WERE to be recommended as the default way to do things with .NET Core, would we want any changes made to the way files are stored? There’s a paket-files directory, and also a .paket directory. If you’re using Paket as a global tool, the only thing stored in .paket is the Paket.Restore.targets file. Which seems kind of “wrong”/inefficient from an engineering perspective, but maybe it’s worth living with since it’s not that big a deal and changing it would be complicated.
3. Is it better to install Paket as a “local” tool, but using .NET Core? I personally don’t think so, because it adds a bunch of files and it annoys me to have to commit it to the repo. For example:

What do you think?

[Tarmil]

Regarding the startup friction, have you looked at https://github.com/thinkbeforecoding/paket.install? It creates a setup based on https://github.com/enricosada/paket-netcore-testing-as-tool that works quite well in my experience. It also adds the relevant bits to .gitignore so that having paket as local tool is not a problem:

.paket/*
!.paket/Paket.Restore.targets
!.paket/paket.bootstrapper.proj
!.paket/paket.bootstrapper.props