Support package restore to work with "highest" while following constraints #1360
Comments
|
This is possible already by adding the dependency to project.json and specifying the version as 1.* |
|
I think @giggio is saying that he wants the package author to specify that the is going to get bumped on restore. Did I get right? |
|
It depends. Does Also, if I use Also, can we do |
|
So to answer your questions: in project.json 1.* means literally a wildcard match so it will match 1.1, 1.2 and 1.3 etc. There is no way to specify greater than 1.3 and smaller than 2.0, and I agree that's something that should be added. You cannot specify 1.* for a dependency only on the project.json level (so not in the nuspec). 1.2.* means, 1.2, 1.2.1, 1.2.3, etc |
|
For package dependencies, we discussed this at length and at this point we don't believe this is something we are going to support. A user can make that choice by including the dependency in project.json, but the package author will not be able to do that without revving his package version to ask for a new dependency. The desire is to keep a constant experience when installing a package. This is a common decision we repeated in a discussion with the DNX team today. CC // @lodejard @davidfowl |
|
The problem with not supporting a way to configure installation of highest version by default is that we have to manually update our dependencies all the time. This can be time consuming as our dependencies grow, which is likely to happen. Why not allow me to control how I want to update my dependencies? If I want a constant experience I can use a lock file, or not specify a range. That should be the way to get the constant experience. If I am ok with minor or patch automatic updates, than I need to be able to specify that. I should be in control of that, not nuget or dnu. Please don't take that decision from me. It is not clear to me yet if the |
|
1.* floats to the highest version. 1.2 will be selected at restore time in your example. |
|
@emgarten excelent! 👍 |
|
Would you mind sharing examples for your setups with specific packages/projects to help understand your scenanarios a bit better? From: Giovanni Bassimailto:notifications@github.com @emgartenhttps://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2femgarten&data=01%7c01%7cyigalatz%40microsoft.com%7ccfbf28affb5a46d9f79b08d2bbad6072%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=AfH%2fDp1Xy362XTFcpV%2b3cOQxgLr2crGvh30CsgkDRLw%3d excelent! [:+1:] — |
|
Sure. I am developing a set of libraries, and I would like that people using this libraries to be automatically updated to a determined patch, but not minor, versions, automatically. So, I have another question, if they already have |
|
If I'm reading you right, That does not happen for dependencies, you can only specify it as a user for your top level dependencies. The reason this doesn't work is that restore is a step needs to be 100% repeatable, generating the same result. The suggestion right now is for a package author to rev his whole package graph rather than edge nodes. So say your package is named A 2.3 depending on B 2.3, when you rev B to 2.4 you also rev A to 2.4. Now a user though can depend on A 2.* (and not yet 2.3 through 2.*) Does that make sense? From: Giovanni Bassimailto:notifications@github.com Sure. I am developing a set of libraries, and I would like that people using this libraries to be automatically updated to a determined patch, but not minor, versions, automatically. So, I have another question, if they already have 2.3.2, and they nuget restore, does that mean that now they will get 2.3.3 on the packages directory, replacing the old version? Would this work on nuget 2 and 3? And would project.lock.json be automatically updated when you nuget restore, same as on dnu? And is there a lock file for nuget 2? — |
|
The idea that a restore should be 100% repeatable is debatable. Yes, it should be if that is what I want. This is usually true when we are releasing, but it is usually not true all the time when we are developing. So, if during development, a dependency is updated, on the next restore, very often, I want to get the new version, no the old one. Back to some questions: Assuming we have published package
|
From: Giovanni Bassimailto:notifications@github.com The idea that a restore should be 100% repeatable is debatable. Yes, it should be if that is what I want. This is usually true when we are releasing, but it is usually not true all the time when we are developing. So, if during development, a dependency is updated, on the next restore, very often, I want to get the new version, no the old one. Back to some questions: Assuming we have published package A, version 2.3.3. If a user specifies his dependencies for package A as 2.3.*, and had already nuget restored and had version 2.3.3 already installed. When I release 2.3.4:
— |
|
Ok, so I will restate that so it clear to me. I write anything incorrect, please point the error. Both nuget 2 and nuget 3 support package.config, but package.config does not support stars (*), which is the only way to float dependencies at the moment. Ok, I think I get it now. Thanks for all the help, everyone. |
|
Very accurate! Sent from my Windows Phone From: Giovanni Bassimailto:notifications@github.com Ok, so I will restate that so it clear to me. I write anything incorrect, please point the error. Both nuget 2 and nuget 3 support package.config, but package.config does not support stars (*), which is the only way to float dependencies at the moment. Ok, I think I get it now. Thanks for all the help, everyone. — |
|
@giggio closing, as I believe this is now resolved in your mind. If you have a specific follow up, lets discuss a more targeted new issue |
Note: This is coming as a parallel request to an update on
dnu. See aspnet/dnx#2657We need to be able to tell nuget (and VS) to restore the highest available version from a dnx package. Right now it always resolves to lowest.
For example, if my app dependes on "[1,2)", this means I depend on at least version 1, and I accept anything up to version 2. But if 1.0.0 and 1.1.0 exist, nuget will always get 1.0.0.
There is no config at this moment that allows nuget to get the highest available version that works with a version spec. A higher version will only be selected if there is another package restricting the dependence to a higher range.
This is really important for package authors for fixing security issues, releasing minors, etc.
Node is a good example on how to work this.
Node allows patch updates with
~, like~1.0.0(anything from 1.0.0 to 1.1.0 - not included) and minor updates with^, like^1.0.0(anything from 1.0.0 to 2.0.0 - not included).Node also allow for wildcards with the
x, like1.x(anything greater or equal to 1.0 and lower than 2).The text was updated successfully, but these errors were encountered: