search

NuGet / Home

Repo for NuGet Client issues
Other
1.5k stars 252 forks source link

Ability to skip unavailable package sources in nuget.exe #7015

Open dusk0r opened 6 years ago

dusk0r commented 6 years ago

We use a local NuGet source in addition to nuget.org. During an internet outage NuGet restore tried to use nuget.org and failed with return code 1. The package was available on the local source.

Can we add a way to first try all sources (event if they fail) to restore a package and only fail if we can't find a source?

NuGet.exe 4.6.2

jainaashish commented 6 years ago

Thanks for the issue. It's already supported for dotnet.exe restore via --ignore-failed-sources so you can unblock yourself by switching to dotnet.exe.

StingyJack commented 6 years ago

@jainaashish - is there an option in the PM UI for this? Switching to .net core is not an economically viable option.

jainaashish commented 6 years ago

@StingyJack there is no option in PM UI for this. And it may look like a simple thing to do but there are lot of implications because it will start effecting your restore graph randomly. For example, availability or unavailability of a specific source can easily change the restore dependency resolution which will create more trouble then solving some specific asks. So for time being, I'll recommend disabling a specific source or select a specific source to do install/ update/ or restore.

Once we've repeatable build using lock file then we can look into enabling this feature as well because then consumers will have an explicit option to fail or succeed restore when dependency graph changed based on NuGet feeds.

StingyJack commented 6 years ago

"Repeatable build" and "lock file" seem like unrelated concepts. And I'm not sure I understand why its currently not repeatable. I'll poke around here and see if there is any issue or docs that explains why the dependency resolution would not be repeatable, or would require locking the filesystem in any way.

jainaashish commented 6 years ago

I'll give a very simple repro..

  1. Lets say you have 2 feeds, feedA and feedB.
  2. FeedA has packageA 3.0.0 and feedB has packageA 4.0.0
  3. Now manually add a nuget dependency for packageA 3.0.0
  4. Make feedA unavailable and restore your project... You will see it will resolve to packageA 4.0.0 because that's what available at this time (although it will also raise a package upgrade warning but most likely you'll just miss it)
  5. Now make feedA available again, and restore. This will resolve to packageA 3.0.0

Like-wise there are other scenarios where unavailable feeds can simply change the restore behavior. Also, NuGet itself cant figure out if a specific source can be ignored during a operation for the same fact that different resolution can come from different sources.

StingyJack commented 6 years ago

Why would it pick 4.0.0 when I specified 3.0.0? Nuget should not be automatically taking package versions I didnt specify. Thats way worse than VS "helping" me by finding a reference instead of erroring out.

Also, if you follow SemVer (I cant) that's a breaking change version update too.

I can take this up on a new issue if @dusk0r prefers, I don't mean to be a thread pirate.