Quick update workflow / .NET Core

Description

NOTE: this is about .NET Core. I believe, full framework doesn't have this problem, as framework assemblies are not queried.

I guess it's more like a question/feature request. Maybe there is already a way to do it I just didn't find it.

I have 2+ repositories, let's say Framework and ProjectA (ProjectB, ProjectC, etc). ProjectA depends on Framework. They are all in rapid growth phase so they both get updated quite frequently, we would like, in ProjectA, to use new version on Framework as quickly as possible.

We publish Framework to our local feed and update ProjectA with:

paket update Framework.* --filter

This works as expected it is just very slow (for now it takes ~8 minutes per project).

 - Resolver: 8 minutes, 25 seconds (1 runs)
    - Runtime: 6 minutes, 10 seconds
    - Blocked (retrieving package details): 2 minutes, 11 seconds (269 times)
    - Blocked (retrieving package versions): 4 seconds (5 times)
    - Not Blocked (retrieving package versions): 276 times
    - Not Blocked (retrieving package details): 12 times
 - Disk IO: 3 seconds
 - Average Request Time: 531 milliseconds
 - Number of Requests: 1074
 - Runtime: 8 minutes, 30 seconds

There are two sources of "slowness": runtime and retrieving package details.
I guess that runtime is actual resolution algorithm, while retrieving package details is contacting nuget and retrieving package metadata.

NOTE: It's actually quite interesting that Runtime takes that long.

My question/suggestion would be:

• option to update (--quick) only mentioned packages (Framework.*) without re-querying transitive dependencies as long as they didn't change
• caching package metadata responses from nuget (it does not change, right?)

I guess, to be sure it would require running "regular" update on the end of the day, but would speed up development in the meantime.

Repro steps

1. Unzip attached repo
2. Run "setup.cmd" (it will build "framework" and "project")
3. Update "framework" in "project": cd pkt3p && paket update pkt* --filter
4. NOTE: initial 'install' took less than 'update' (45s vs 2.5m on my machine)
5. NOTE: this time runtime took most of the time (2m)

NOTE: this is just ONE dependency.

Known workarounds

Updating lock file manually? (cringe)

Start with the attached repository and run setup.cmd, then reproduce the slowdown with cd pkt3p && paket update pkt* --filter. Compare resolver runtime and package-detail requests with the requested quick update and metadata caching behavior; done means the workflow updates the selected packages substantially faster without incorrectly skipping changed transitive dependencies.