search

fsprojects / Paket

A dependency manager for .NET with support for NuGet packages and Git repositories.
https://fsprojects.github.io/Paket/
MIT License
2.02k stars 524 forks source link

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

Open NatElkins opened 5 years ago

NatElkins commented 5 years ago

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?

slang25 commented 5 years ago

I've just been digging through the docs and commit history to try and figure this out. It looks like it's doable at the moment, but the docs aren't clear.

I would have expected there to be a section in Getting Started that outlines what to do with .NET Core projects. I'm happy to help put together the docs and test things, just need to know what the guidance should be.

forki commented 5 years ago

cc @enricosada

slang25 commented 5 years ago

Currently using paket as a global tool isn't working for me (without extra steps, it's not creating the Paket.Restore.targets file I expect under .paket). What does work is installing it as a local tool under .paket, then running .paket/paket restore.

I wouldn't check this in as we have developers on Windows and macOS, and the tool shim is platform specific. So at the moment I'd have a build script that installs a local tool and calls paket restore, this creates the Paket.Restore.targets file I need. However, if you then delete the paket local tool and do a clean, you can do a dotnet restore and it just works.

So is it that we just need to explain how to acquire the Paket.Restore.targets in the Getting Started section and the thing to do is just dotnet restore?

NatElkins commented 5 years ago

@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).

paket

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:
image

What do you think?

NatElkins commented 5 years ago

I also see that the SAFE stack docs suggest using Paket as a global tool: https://safe-stack.github.io/docs/quickstart/

Tarmil commented 5 years ago

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