Paket Cannot Unify Packages

[matthid]

Description

We currently have this unfortunate situation that multiple nuget packages actually describe the same package.
For example Microsoft.FSharp.Core.netcore and FSharp.Core are actually the same package.
A lot of other packages have the same problem.

I think we should have a paket feature to workaround this for the time being. This really hits me hard in fsprojects/FAKE#1281.

Repro steps

I created a new Fake.Runtime package with

  "frameworks": {
    "net46": {
      "dependencies": {
        "FSharp.Core": "4.0.0.1",
        ...
      },
    ...
    },
    "netstandard1.6": {
      "dependencies": {
        "Microsoft.FSharp.Core.netcore": "1.0.0-alpha-160629",
        ...
      }
    }
  }

Later when I'm trying to pull this package and try to get all references for netstandard1.6, I get:

• "C:\PROJ\FAKE\src\app\Fake.netcore.fake\reference_fakelib.fsx\packages\FSharp.Core\lib\portable-net45+netcore45\FSharp.Core.dll"
• "C:\PROJ\FAKE\src\app\Fake.netcore.fake\reference_fakelib.fsx\packages\Microsoft.FSharp.Core.netcore\lib\netstandard1.6\FSharp.Core.dll"

Which is correct AFAICT. Problem is that now I get error FS0215: Multiple references to 'FSharp.Core.dll' are not permitted from FCS.

Expected/Actual behavior

No idea, I think the behavior is correct.

Known workarounds

Using different groups with framework restrictions "might" work.

Related information

I think we should have a syntax to tell paket that those two packages are actually the same package?
maybe something like:

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

nuget Fake.Runtime 1.0.0-alpha4
unify Microsoft.FSharp.Core.netcore FSharp.Core

unify would unify the package while preferring the first listed item if the package supports a given framework.

Maybe this suggestion is complete nonsense, but I think there should be a workaround for now (I agree that the correct solution is to have a single package). Maybe we should print a big warning when unify is used.

/cc @forki

[forki]

What would unify mean? What would it do? How do we match versions?

[forki]

I assume something like the following dependencies file might work as well:

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

nuget Microsoft.FSharp.Core.netcore framework: coreclr
nguet FSharp.Core framework: >= net40

(but we don't have the coreclr moniker yet)

[matthid]

Ideally I don't want to list FSharp.Core its an indirect reference of Fake.Runtime...

After discussion on twitter I do not longer think we need this. This is probably just a bug (if someone stubles over it)

[forki]

we will look at the concrete repro case that @matthid will create. Maybe we find a temporary solution for the FSharp.Core case (see also dotnet/fsharp#1054).

[enricosada]

@matthid your packages is ok for netcore sdk, if you do build should use only one of the two.
How do you reference these to get two different FSharp.Core? never happened to me. how do you "try to get all references for netstandard1.6"?

coreclr tfm doesnt exists, it's netstandard1.6 (and doesnt mean only coreclr).

[matthid]

Paket seems to be doing the correct thing... Sorry for the confusion.

[matthid]

FYI: I had the same problem again after updating to chessi 0.6, because now FSharp.Core actually was used in Netstandard. I fixed this by updating everything to latest FSharp.Core alpha ...