New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Nuget update should provide informative message when a higher version is restricted by allowedVersions constraint #3013

Closed
jainaashish opened this Issue Jun 21, 2016 · 5 comments

Comments

Projects
None yet
3 participants
@jainaashish
Contributor

jainaashish commented Jun 21, 2016

Issue:
I've a package with 1.0 and 2.0 versions where 1.0 is already installed and 2.0 is restricted by allowedVersions range define in package.config (allowedVersions="[1.0, 2.0)" ) now execute below command from PMC:

update-package -Id AashishTestPackage -Source https://api.nuget.org/v3/index.json -ProjectName ConsoleApplication1

Expected:

It should have throw error something "unable to resolve this package...." since available version was restricted by constraint.

Actual:

It simply said "There are no new updates available." and passed.

Workaround:
specify -Version attribute in update-package command, then it will successfully throw that error.

@emgarten

This comment has been minimized.

Show comment
Hide comment
@emgarten

emgarten Jun 22, 2016

Contributor

I believe this behavior is by design and was fixed not too long ago.

Contributor

emgarten commented Jun 22, 2016

I believe this behavior is by design and was fixed not too long ago.

@jainaashish

This comment has been minimized.

Show comment
Hide comment
@jainaashish

jainaashish Jun 22, 2016

Contributor

Not really this behavior is because of the fix of 1816, which is to prune disallowed versions first and then pick the highest. If you've multiple versions n some of your highest versions are disallowed then you can still get a version to update which should happen. Then another case, is you only have 2 versions where 1.0 is already installed and 2.0 is disallowed then you should throw error to communicate otherwise user might not be able to understand why it was not updated.

So I'll tweak this code a little, just to throw error in case no version is available to update after pruning all disallowed versions.

Contributor

jainaashish commented Jun 22, 2016

Not really this behavior is because of the fix of 1816, which is to prune disallowed versions first and then pick the highest. If you've multiple versions n some of your highest versions are disallowed then you can still get a version to update which should happen. Then another case, is you only have 2 versions where 1.0 is already installed and 2.0 is disallowed then you should throw error to communicate otherwise user might not be able to understand why it was not updated.

So I'll tweak this code a little, just to throw error in case no version is available to update after pruning all disallowed versions.

@emgarten

This comment has been minimized.

Show comment
Hide comment
@emgarten

emgarten Jun 22, 2016

Contributor

This will be problematic for users who set allowedVersions to restrict the package to the highest version of a certain set. For example if a user wants to stay on version 3.4.x of the NuGet packages today they could add [3.4.0, 3.5.0) to avoid the 3.5.x packages.

In the scenario the above the user is aware that there are higher versions, they added allowedVersions to avoid them. Taking the advanced allowedVersions feature and turning it into a non-advanced scenario will make this somewhat annoying.

See also this issue, it is for update all instead of updating a single package, but I think the same thing applies to some degree: #916

Contributor

emgarten commented Jun 22, 2016

This will be problematic for users who set allowedVersions to restrict the package to the highest version of a certain set. For example if a user wants to stay on version 3.4.x of the NuGet packages today they could add [3.4.0, 3.5.0) to avoid the 3.5.x packages.

In the scenario the above the user is aware that there are higher versions, they added allowedVersions to avoid them. Taking the advanced allowedVersions feature and turning it into a non-advanced scenario will make this somewhat annoying.

See also this issue, it is for update all instead of updating a single package, but I think the same thing applies to some degree: #916

@emgarten

This comment has been minimized.

Show comment
Hide comment
@emgarten

emgarten Jun 23, 2016

Contributor

Here is the behavior in 2.8.6

PM> install-package newtonsoft.json -version 6.0.1
Installing 'Newtonsoft.Json 6.0.1'.
Successfully installed 'Newtonsoft.Json 6.0.1'.
Adding 'Newtonsoft.Json 6.0.1' to ConsoleApplication1.
Successfully added 'Newtonsoft.Json 6.0.1' to ConsoleApplication1.

Add constraint

<?xml version="1.0" encoding="utf-8"?>
<packages>
  <package id="Newtonsoft.Json" version="6.0.1" targetFramework="net45" allowedVersions="[6.0.0, 7.0.0)" />
</packages>

Update

PM> update-package Newtonsoft.Json
Updating 'Newtonsoft.Json' from version '6.0.1' to '6.0.8' in project 'ConsoleApplication1'.
Removing 'Newtonsoft.Json 6.0.1' from ConsoleApplication1.
Successfully removed 'Newtonsoft.Json 6.0.1' from ConsoleApplication1.
Adding 'Newtonsoft.Json 6.0.8' to ConsoleApplication1.
Installing 'Newtonsoft.Json 6.0.8'.
Successfully installed 'Newtonsoft.Json 6.0.8'.
Successfully added 'Newtonsoft.Json 6.0.8' to ConsoleApplication1.
Uninstalling 'Newtonsoft.Json 6.0.1'.
Successfully uninstalled 'Newtonsoft.Json 6.0.1'.

Update again

PM> update-package Newtonsoft.Json
Applying constraint 'Newtonsoft.Json (≥ 6.0.0 && < 7.0.0)' defined in packages.config.
No updates available for 'Newtonsoft.Json' in project 'ConsoleApplication1'.

It has extra info about why it didn't update, but it doesn't consider it an error. Maybe go with that behavior?

Contributor

emgarten commented Jun 23, 2016

Here is the behavior in 2.8.6

PM> install-package newtonsoft.json -version 6.0.1
Installing 'Newtonsoft.Json 6.0.1'.
Successfully installed 'Newtonsoft.Json 6.0.1'.
Adding 'Newtonsoft.Json 6.0.1' to ConsoleApplication1.
Successfully added 'Newtonsoft.Json 6.0.1' to ConsoleApplication1.

Add constraint

<?xml version="1.0" encoding="utf-8"?>
<packages>
  <package id="Newtonsoft.Json" version="6.0.1" targetFramework="net45" allowedVersions="[6.0.0, 7.0.0)" />
</packages>

Update

PM> update-package Newtonsoft.Json
Updating 'Newtonsoft.Json' from version '6.0.1' to '6.0.8' in project 'ConsoleApplication1'.
Removing 'Newtonsoft.Json 6.0.1' from ConsoleApplication1.
Successfully removed 'Newtonsoft.Json 6.0.1' from ConsoleApplication1.
Adding 'Newtonsoft.Json 6.0.8' to ConsoleApplication1.
Installing 'Newtonsoft.Json 6.0.8'.
Successfully installed 'Newtonsoft.Json 6.0.8'.
Successfully added 'Newtonsoft.Json 6.0.8' to ConsoleApplication1.
Uninstalling 'Newtonsoft.Json 6.0.1'.
Successfully uninstalled 'Newtonsoft.Json 6.0.1'.

Update again

PM> update-package Newtonsoft.Json
Applying constraint 'Newtonsoft.Json (≥ 6.0.0 && < 7.0.0)' defined in packages.config.
No updates available for 'Newtonsoft.Json' in project 'ConsoleApplication1'.

It has extra info about why it didn't update, but it doesn't consider it an error. Maybe go with that behavior?

@jainaashish

This comment has been minimized.

Show comment
Hide comment
@jainaashish

jainaashish Jun 23, 2016

Contributor

yeah additional info or warning seems right. But I'm just wondering why there isn't any issue logged so far on 3.3 or 3.4 or 3.5... until now it was throwing error in this case.

Contributor

jainaashish commented Jun 23, 2016

yeah additional info or warning seems right. But I'm just wondering why there isn't any issue logged so far on 3.3 or 3.4 or 3.5... until now it was throwing error in this case.

jainaashish added a commit to NuGet/NuGet.Client that referenced this issue Jun 28, 2016

jainaashish added a commit to NuGet/NuGet.Client that referenced this issue Jun 28, 2016

@rrelyea rrelyea added this to the 3.5 RTM milestone Jun 29, 2016

@rrelyea rrelyea changed the title from Nuget update doesn't throw error when a higher version restricted by allowedVersions constraint to Nuget update should provide informative message when a higher version is restricted by allowedVersions constraint Jun 29, 2016

jainaashish added a commit to NuGet/NuGet.Client that referenced this issue Jun 29, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment