Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Depending on package framework restriction is not respected #2564

Closed
s952163 opened this issue Jul 27, 2017 · 3 comments
Closed

Depending on package framework restriction is not respected #2564

s952163 opened this issue Jul 27, 2017 · 3 comments

Comments

@s952163
Copy link

s952163 commented Jul 27, 2017

Description

I was looking at reproducing [https://stackoverflow.com/questions/41236933/paket-framework-restriction-differences/](Paket Framework Restriction Differences), but with current paket version (5.81.2) this is not reproducible. However depending on the packages installed the framework restriction will still be ignored.

Repro steps

  1. Use the following paket.dependencies:

source https://www.nuget.org/api/v2
#framework: >=net46

nuget FSharp.Core
nuget FAKE 
nuget Fsharp.Data 
#nuget Expecto 
#nuget Expecto.BenchmarkDotNet 
#nuget Expecto.FsCheck
#nuget Expecto.VisualStudio.TestAdapter
#nuget Argu 
#nuget FileHelpers

This will result in 370MB and 72 packages.

  1. Now remove the comment from the framework restriction: This will result in only 4 packages and about 100MB downloaed.

  2. Remove the comment from Expecto.BenchmarkDotNet: This will download 60 packages, at ca. 400MB

Expected behavior

Respect framework restriction. However I suspect this depends on the actual package spec.

Actual behavior

Framework restriction depends on packages downloaded.

@forki
Copy link
Member

forki commented Jul 27, 2017

ok. ;-)

so let's analyse situation after step 3:

  • Expecto.BenchmarkDotNet depends on BenchmarkDotNet and that on BenchmarkDotNet.Toolchains.Roslyn
  • BenchmarkDotNet.Toolchains.Roslyn depends on Microsoft.CodeAnalysis.CSharp for net46 and that one on Microsoft.CodeAnalysis.Common for all frameworks
  • Microsoft.CodeAnalysis.Common has only deps for netstandard1.3 so we need to assume these are the correct ones for net46 -> you win ALL the transitive packages on the internet

/shrug

@matthid
Copy link
Member

matthid commented Jul 27, 2017

Ah @forki was faster, yes that is exactly what happens. Usually you can change your framework restrictions to a higher framework. In this case you can only ask the package authors of Microsoft.CodeAnalysis.Common to provide a package with a full netframework build.
Or try another version like maybe https://www.nuget.org/packages/Microsoft.CodeAnalysis.Common/1.2.0 (you probably get older versions of your current dependencies in that case or no resolution at all)

Closing this for now as I think paket is doing the correct thing.

@matthid matthid closed this as completed Jul 27, 2017
@s952163
Copy link
Author

s952163 commented Jul 27, 2017

thx. will try it out.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants