Paket.Core.dll with uncached dependencies

[cgravill]

Description

When I used Paket.Core.dll to attempt to download new nuget dependencies on a machine that hasn’t seen those dependencies it failed with:

Unhandled Exception: System.Exception: Could not download Http.fs 4.0.2.
    Couldn't get package details for package Http.fs 4.0.2 on https://www.nuget.org/api/v2.
   at Paket.NuGetV2.download@968-43.Invoke(String message)
   at Paket.NuGetV2.download@885-40.Invoke(Exception _arg10)
   at Microsoft.FSharp.Control.AsyncBuilderImpl.callA@851.Invoke(AsyncParams`1 args)
--- End of stack trace from previous location where exception was thrown ---
   at Microsoft.FSharp.Control.AsyncBuilderImpl.commit[a](Result`1 res)
   at Microsoft.FSharp.Control.CancellationTokenOps.RunSynchronously[a](CancellationToken token, FSharpAsync`1 computation, FSharpOption`1 timeout)
   at Microsoft.FSharp.Control.FSharpAsync.RunSynchronously[T](FSharpAsync`1 computation, FSharpOption`1 timeout, FSharpOption`1 cancellationToken)
   at Microsoft.FSharp.Collections.IEnumerator.map@111.DoMoveNext(b& )
   at Microsoft.FSharp.Collections.IEnumerator.MapEnumerator`1.System-Collections-IEnumerator-MoveNext()
   at Microsoft.FSharp.Core.CompilerServices.RuntimeHelpers.takeOuter@713[T,TResult](ConcatEnumerator`2 x, Unit unitVar0)
   at System.Collections.Generic.List`1..ctor(IEnumerable`1 collection)
   at Microsoft.FSharp.Collections.SeqModule.ToArray[T](IEnumerable`1 source)
   at Paket.InstallProcess.InstallIntoProjects[a](InstallerOptions options, Boolean forceTouch, DependenciesFile dependenciesFile, LockFile lockFile, FSharpList`1 projectsAndReferences, FSharpMap`2 updatedGroups)
   at Paket.UpdateProcess.SmartInstall(DependenciesFile dependenciesFile, UpdateMode updateMode, UpdaterOptions options)
   at <StartupCode$Paket-Core>.$PublicAPI.Install@163.Invoke(Unit unitVar0)
   at Paket.Utils.RunInLockedAccessMode[a](String rootFolder, FSharpFunc`2 action)
   at IfSharp.Kernel.App.InstallAndStart(Boolean forceInstall, Boolean start) in E:\dev\IfSharp\src\IfSharp.Kernel\App.fs:line 251
   at IfSharpConsole.Program.Main(String[] args) in E:\dev\IfSharp\src\IfSharpConsole\Program.cs:line 14

I think it might be a caching issue compared to the paket.lock. Am I using Paket.Core.dll in a way I shouldn't be?

Repro steps

Clean machine
Use Paket.Core.dll to download a nuget your machine has never used
-> throw error

Code:

printfn "Installing dependencies via Paket"
let dependencies = Paket.Dependencies.Locate(System.IO.Path.GetDirectoryName(thisExecutable))
dependencies.Install(false)

(same occurs with dependencies.Install(true))

Investigation

Clean machine
Use paket.exe to download a nuget your machine has never used
-> fetches
Delete packages directory
Use Paket.Core.dll to download a reference your machine has never used
-> fetches

Clean machine
Use paket.exe to download a nuget your machine has never used
-> fetches
Delete packages directory
Use Paket.Core.dll to download the same nuget
-> fetches
run .paket\paket.exe clear-cache
Use Paket.Core.dll to download the same nuget
-> throw error

It's reproducible in the /github/IfSharp project on the Jupyter branch. I can construct a minimal reproduction if there's issue in reproducing.

Known workarounds

Shell to paket.exe first, but it's much cleaner to work via Paket.Core.dll

System details

Window 10
Visual Studio 2015
Paket.Core (3.19.3)

[cgravill]

I saw a recommendation to use paket.exe instead:
fsprojects/Paket.VisualStudio#73

Do you think that would be a better fit for F# in the Jupyter system (https://github.com/fsprojects/IfSharp)? We're planning to use Paket progressively more as it's generally much more reliable for us. I thought Paket.Core.dll would be intended way but happy to adjust. Letting the users update paket seems desirable as well.

[forki]

I tried to reproduce in an integration test but failed. can you please take a look at 37c2703 ?

[cgravill]

Thanks for looking into this. The integration test passes for me. Also now I've gone back to our repository it appears I fixed our usage of Paket.Core.dll by accident.

The root cause of our issue seems to have been we were using a very old version of Newtonsoft.Json i.e. 5.0.8. I separately updated to 9.0.1. How the the earlier version caused the above exception is unclear but it reliably works now.