Installing Reactive UI in a net45 project doesn't resolve the correct version

vbfox commented 6 years ago

Description

Installing the ReactiveUI package on a net45 project (with the constraint in the paket.dependencies) paket resolve version 8.7.2 that isn't compatible with net45.

There is no listed version currently compatible but the unlisted 7.x series is compatible, in the original project a version in 7.x was locked but paket insisted on upgrading to a listed version (That isn't compatible)

Repro steps

source https://nuget.org/api/v2
framework: net45
nuget reactiveui

Then run paket install

A full git repo is at https://github.com/vbfox/temp_paket_reactiveui_bug

Expected behavior

Finding a compatible version (They are unlisted so I don't know if it's possible) or displaying an error.

Actual behavior

Paket say that everything is fine but NuGet resolved disagree :

C:\temp\paketreactiveui\Test.fsproj : error NU1202: Package ReactiveUI 8.7.2 is not compatible with net45 (.NETFramework,Version=v4.5). Package ReactiveUI 8.7.2 supports:
C:\temp\paketreactiveui\Test.fsproj : error NU1202:   - monoandroid80 (MonoAndroid,Version=v8.0)
C:\temp\paketreactiveui\Test.fsproj : error NU1202:   - net461 (.NETFramework,Version=v4.6.1)
C:\temp\paketreactiveui\Test.fsproj : error NU1202:   - netcoreapp2.0 (.NETCoreApp,Version=v2.0)
C:\temp\paketreactiveui\Test.fsproj : error NU1202:   - netstandard2.0 (.NETStandard,Version=v2.0)
C:\temp\paketreactiveui\Test.fsproj : error NU1202:   - tizen40 (Tizen,Version=v4.0)
C:\temp\paketreactiveui\Test.fsproj : error NU1202:   - uap10.0.16299 (UAP,Version=v10.0.16299)
C:\temp\paketreactiveui\Test.fsproj : error NU1202:   - xamarinios10 (Xamarin.iOS,Version=v1.0)
C:\temp\paketreactiveui\Test.fsproj : error NU1202:   - xamarinmac20 (Xamarin.Mac,Version=v2.0)
C:\temp\paketreactiveui\Test.fsproj : error NU1202:   - xamarintvos10 (Xamarin.TVOS,Version=v1.0)

Known workarounds

Pin a working version, adding the dependency manually if it's a transitive one.

matthid commented 6 years ago

Sadly this is by design, there is no way to know if a package is compatible besides downloading and inspecting ...

matthid commented 6 years ago

I don't think even NuGet will consider this while trying to resolve the version. So I'm pretty sure you can create a package where NuGet will just be unable to install/restore it with the above error for a transitive dependency (Ie NuGet will not try to find a different version when this error happens).

vbfox commented 6 years ago

Nuget doesn't try anything fancy but they never does (They also never have the direct problem as you always specify a version and it resolve lower)

But NuGet show the error at the end (Essentially that you reference a package with an incompatible TFM) if you ends up in this situation.

I'm just surprised that paket knowing that a direct package reference is compatible with nothing (it resolve it as the lock file contains version constraints per package when they are more complex) doesn't raise anything

matthid commented 6 years ago

I'm just surprised that paket knowing that a direct package reference is compatible with nothing

Not sure what you mean, paket doesn't know the package doesn't support net45 until it has been downloaded and extracted (which is AFTER resolution phase)

vbfox commented 6 years ago

Sadly this is by design, there is no way to know if a package is compatible besides downloading and inspecting ...

I understand that for now paket doesn't have such information during the resolution (And it might be a big undertaking to integrate it) but it's not for fault of availability, the v3 API exposes framework and per-framework dependencies (Yeah I know that paket was started long before v3 was there)

Not sure what you mean, paket doesn't know the package doesn't support net45 until it has been downloaded and extracted (which is AFTER resolution phase)

Even if paket doesn't know, after the resolution paket ends up with a package that was requested that can't work in any of the framework it was limited to.

Once arrived there I would have expect one of theses :

Noticing that the resolved graph can't work paket error before writing the lock file
Lock file is written but there is a warning that one of the package won't be installable anywhere
During install to a project paket realize that there is no package that can be referenced (as it wasn't written in the lock file, or written with it's constraints & none match the group/global constraints)

One thing to note there is that NuGet warned me because it's an SDK project, on non-SDK projects paket would have been the sole resolver and the error would have been a compilation time error because some types can't be found, letting me search in the dark for why the types disappeared

matthid commented 6 years ago

but it's not for fault of availability, the v3 API exposes framework and per-framework dependencies

No that reasoning depends on the assumption that a missing framework-dependency group means that the package doesn't support this framework. I don't think this is true. Packages can have "missing" dependency groups (ie when they don't have dependencies for the given framework) and still contain a framework folder or dll for this framework.

after the resolution paket ends up with a package that was requested that can't work in any of the framework it was limited to.

Yes a warning at install time might be reasonable, please note though that even at install time we might not know the target framework for new-style sdk projects, which would move it to build time anyway. At build time you already get the error from NuGet.

matthid commented 6 years ago

Regarding old-style projects: I don't think it's worth fixing. Afaik that is how paket always behaved, and yes I encountered those compiler errors myself before.

vbfox commented 6 years ago

No that reasoning depends on the assumption that a missing framework-dependency group means that the package doesn't support this framework. I don't think this is true. Packages can have "missing" dependency groups (ie when they don't have dependencies for the given framework) and still contain a framework folder or dll for this framework.

Fuck yes, true 😭 we can never have nice things. Don't they show only compatible projects in Visual Studio ? Didn't use their selector for years but it would be an enhancement to suggest especially if it accidentally put the information in the API.

Yes a warning at install time might be reasonable, please note though that even at install time we might not know the target framework for new-style sdk projects, which would move it to build time anyway.

Yes I realize that if paket find a possible compatibility but the project framework is actually different than the constraints it will be back to nuget. But csproj being a turing complete format there is nothing to be done here that would be perfect.

fsprojects / Paket