Allow FAKE to reference/restore tool-packages (packages containing `.exe` / `dotnet tool`)

[StanleyGoldman]

👋 I asked this question in gitter the other day..

I was trying to include xunits console runner as a dependency in my .fsx file

#r "paket:
nuget Fake.IO.FileSystem
nuget Fake.DotNet.MSBuild
nuget Fake.DotNet.Testing.XUnit2
nuget Fake.Core.Target
nuget xunit.runner.console 2.4.0 //"
#load "./.fake/build.fsx/intellisense.fsx"

...

Target.create "Test" (fun _ ->
    !! "**/*Tests.dll"
    |> Fake.DotNet.Testing.XUnit2.run (fun p -> { p with
                                                    HtmlOutputPath = Some "xunit.html"
                                                    ToolPath = System.Environment.ExpandEnvironmentVariables("%HOME%/.nuget/packages/xunit.runner.console/2.4.0/tools/net452/xunit.console.exe")
                                                    })
)

I'm unfamiliar with packet, I'm expecting it to installed xunit's console runner to %HOME%/.nuget/packages/xunit.runner.console/2.4.0/tools/net452/xunit.console.exe, but that does not seem to be happening.

I noticed the storage on the packet dependencies file is set to none. I take it that means my dependencies aren't being saved in the standard location (if at all?)

What should I be doing differently?

[matthid]

Storage none means the packages are only stored in the nuget cache (instead of a folder in your repository). the nuget cache is exactly the .nuget folder you wrote so I'd expect the package to be there once you delete the lockfile and run fake again.

Note that currently the easiest way is to use an external paket.dependencies file instead of in-script dependencies, see the docs. And introduce a new paket group to make the download go into the packages folder within your repository.

We definitely need a good story for this eventually and some recommendations to make this scenario straightforward, but we are not there yet. Please feel free to suggest options

[StanleyGoldman]

👋 @matthid thanks for the help.

I struggled for a little bit. I had to learn a bit more about paket and I had to go back in forth through Fake documentation.

This is what I came up with and it seems to work. Let me know if there is something better/clearer I could do.

paket.dependencies:

source https://www.nuget.org/api/v2

// [ FAKE GROUP ]
group FakeBuild
  source https://www.nuget.org/api/v2
  framework: netstandard2.0
  storage:none

  nuget Fake.IO.FileSystem
  nuget Fake.DotNet.MSBuild
  nuget Fake.DotNet.NuGet
  nuget Fake.DotNet.Testing.XUnit2
  nuget Fake.Core.Target 
  groupref FakeBuildResources

group FakeBuildResources
  source https://www.nuget.org/api/v2
  framework: net472, netcoreapp2.1
  storage: packages

  nuget xunit.runner.console

Build.fsx:

#r "paket: groupref FakeBuild //"
#load "./.fake/build.fsx/intellisense.fsx"

[matthid]

Yes indeed that's what I meant you can remove the groupref line from paket.dependencies and you can either use the groupref feature in the script or the magic fake comment (as you can see both work as well but you can remove one if you want)

[valmaev]

You can still use inline paket dependencies in your case. Here's an example from my build script:

build.fsx

#r "paket:

storage: none
source https://api.nuget.org/v3/index.json

nuget FSharp.Core 4.5.0.0
nuget Fake.BuildServer.TeamCity
nuget Fake.Core.Target
nuget Fake.DotNet.AssemblyInfoFile
nuget Fake.DotNet.MSBuild
nuget Fake.DotNet.Testing.DotCover
nuget Fake.DotNet.Testing.XUnit2
nuget Fake.IO.Zip
nuget Fake.Tools.Git
groupref Tools

group Tools
    storage: packages
    source https://api.nuget.org/v3/index.json

    nuget JetBrains.dotCover.CommandLineTools 2018.3.2
    nuget xunit.runner.console 2.4.0 //"

[matthid]

@valmaev This issue is still open as I have not yet decided if storage: packages should be "officially" supported and if .fake should be the location (if we indeed decide to support it). So we might break your scenario in the future (but yes it should work)

[matthid]

I renamed the issue to be more general.

Currently, I'm thinking about something like this:

• Add support for dotnet tool like packages to paket
  • New syntax and simple resolve (like other packages)
  • Call dotnet tool install on a local toolpath (like paket-files/.bin)
• FAKE Runtime forwards group -> packageName -> version information to the script
• FAKE provides APIs to run tools of packages (will resolve to the correct version in the NuGet cache)

Related: https://github.com/fsharp/FAKE/issues/2043

[matthid]

I think mid to long term this will be replaced by the new "local" tools of the dotnet sdk, so I think we can close this?

[github-actions[bot]]

There has not been any activity in this issue for the last 3 months so it will be closed in 14 days if there is no activity.