Update / Add / Remove a project does a full update

[isaacabraham]

When doing either an add of a new dependency or a removal or update of an existing dependency, Paket goes through lots more dependencies in the update path. When using just the official nuget feed it's not so bad, but if you're using external (slower) feeds it can take ages e.g. for the feed below it takes around 20 seconds but when I add in multiple sources it takes > 6 minutes. Perhaps that's a separate issue but there should also be a way to say "yes, this dependency is from Nuget but only look in a specific nuget repository" otherwise it massively increases the amount of searching that needs doing.

Sample dependencies file: -

source http://nuget.org/api/v2

nuget FAKE
nuget FSharp.Data.SqlClient
nuget Http.fs
nuget Microsoft.AspNet.WebApi.Owin
nuget Microsoft.Owin.Host.SystemWeb
nuget Microsoft.Owin.SelfHost
nuget Microsoft.WindowsAzure.Management.Scheduler
nuget OwinHost
nuget Stripe.net
nuget Humanizer
nuget WindowsAzure.Storage
nuget Deedle

[forki]

Ah I think I misinterpreted your tweets.
The current algorithm updates only the one single nuget package and keeps everything else as is. But it still does a complete resolver run since we could introduce conflicts.

The current algorithm works like this:

• Take all dependencies from the dependencies file.
• read the lockfile and add dependencies on all the packages in the lock file (fixed on the specified versions)
  • exclude the updated package
• run the resolver with this very narrow requirement set

I think I see a optimization opportunity. We don't really have to ask nuget feeds for all available versions here. This step is what takes the longest time.

[isaacabraham]

Yes. If you e.g. add a new package that has zero dependencies (or even some dependencies but all of which are new) then there is no need to go through the existing dependencies chain; the same applies to removal or update.

The only part of the graph that should receive an update is the section that is affected by the operation IMHO.

[forki]

that's not really trivial to do ;-)

let start with something simple and try to get rid of the some of the OData calls.

[isaacabraham]

Thought not, let's start out simple :-)

[forki]

does 0.12.1 improve things for you?

[isaacabraham]

Will test tomorrow, cheers.

[isaacabraham]

Yes seems to be quicker now for updates. :-)

[forki]

so the update took you 13 days?

[isaacabraham]

I went through my time-machine immediately after writing that and just came out this morning. So as far as I'm concerned it's only been one day.

[isaacabraham]

Seriously though - as part of the ongoing refactor, would it be useful to be able to parse the lock file into a proper tree structure to allow us to ask questions like "this dependency has changed, what other dependencies do I need to check"?

[forki]

yes that sounds like a good idea.