"paket update nuget XXX" should report why it decides not to

[et1975]

if paket decides not to update the package it was explicitly asked to update it should at least tell me why.
As it is, neither the return code nor the message tell me what happened - in my case dependency of the package was requiring an upgrade as well.

[forki]

Do you have a specific sample for me? Deps file + lock file + package you want to update? Would love to improve the output

[et1975]

Happened with some private packages, but I'll keep an eye out in my public projects for an opportunity to reproduce it.
It should be a fairly common scenario though, so I'm wondering what is the expected behavior in this case:

• solution S has a dependency on packages A and B
• package B also has a dependency on package A
• package B has had its A dependency upgraded and the new version of B is released
• solution S upgrades B to latest (or rather fails to, quietly)

In my case the A package was RabbitMQ.Client which happened to have a new revision released.

[forki]

Our current algorithm wasn't designed for such questions, but I'd love to
improve it in this direction. So I need good samples.
On Jul 30, 2015 22:48, "Eugene Tolmachev" notifications@github.com wrote:

Happened with some private packages, but I'll keep an eye out in my public
projects for an opportunity to reproduce it.
It should be a fairly common scenario though, so I'm wondering what is the
expected behavior in this case:

• solution S has a dependency on packages A and B
• package B also has a dependency on package A
• package B has had its A dependency upgraded and the new version of B
  is released
• solution S upgrades B to latest (or rather fails to, quietly)

In my case the A package was RabbitMQ.Client which happened to have a new
revision released.

—
Reply to this email directly or view it on GitHub
#946 (comment).

[et1975]

Incidentally, it does upgrade as expected if I specify the version explicitly.

[forki]

That is not unusual. Often there's more than one valid resolution.
Specifying more restrictions (concrete versions) leads to picking another.
On Jul 30, 2015 22:55, "Eugene Tolmachev" notifications@github.com wrote:

Incidentally, it does upgrade as expected if I specify the version
explicitly.

—
Reply to this email directly or view it on GitHub
#946 (comment).

[mrinaldi]

I have a repro case here:

paket.dependencies:

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

nuget Ninject.Extensions.Interception
nuget Ninject.Extensions.Logging.Log4Net

paket.lock

NUGET
  remote: https://nuget.org/api/v2
  specs:
    log4net (2.0.3)
    Ninject (2.2.1.4)
    Ninject.Extensions.Interception (2.2.1.2)
      Ninject (>= 2.2.0.0 < 2.3.0.0)
    Ninject.Extensions.Logging (2.2.0.4)
      Ninject (>= 2.2.0.0 < 2.3.0.0)
    Ninject.Extensions.Logging.Log4net (2.2.0.4)
      Ninject.Extensions.Logging (>= 2.2.0.0 < 2.3.0.0)
      log4net (>= 1.0.4)

paket update nuget Ninject.Extensions.Interception
Outputs:

Paket version 1.28.0.0
Updating Ninject.Extensions.Interception in D:\Projects\paket-test\paket.dependencies
Resolving packages:
 - Ninject.Extensions.Interception 3.2.0
 - Ninject.Extensions.Interception 3.0.0.8
 - Ninject.Extensions.Interception 2.2.1.2
 - Ninject 2.2.1.4
D:\Projects\paket-test\paket.lock is already up-to-date
3 seconds - ready.

It gives no clue at all of why it didn't update.

I was wondering if we should have a parameter to force the update of conflicting dependencies, like nuget does OOB.
If you think in this case specific, unless you update all packages, you are in a dead end.