Version and IVersionSpec

May 25, 2011 at 9:45 PM

I'm playing with adding support for VersionSpec in the command line install command. If the behavior through the codebase for VersionSpec("[" + version.ToString() + "]") was the same as Version, it'd be easier. Has there been prior discussion on the code smell with the duplication around the code paths that service Version vs. IVersionSpec?

For example, PackageRepositoryExtensions.FindPackage - the implementations of 

FindPackage(this IPackageRepository repository, string packageId, Version version, IPackageConstraintProvider constraintProvider)


FindPackages(this IPackageRepository repository, string packageId, IVersionSpec versionSpec)

are very similar.

May 26, 2011 at 4:35 AM

Similar but different, we do alot of optimization based on exact version or version range. It's definitely something that could be done, but I'd be careful trying to make a big change like that (we have alot of tests though so you'll see if there's any cases you missed if you did want to change something of that nature).

May 26, 2011 at 4:52 AM

No, a big change like that would require a bit of coordination with y'all - I was just wanted to raise the point, see if there was some discussion about it elsewhere already. I am curious what it would look like if you could remove Version from a lot of the core processing and simply push in an instance of VersionSpec with the exact spec when starting with Version. I presume functionality should match in those cases?

I meant to mention some praise of the tests in place in my first post, they definitely helped bring attention to some things I would've overlooked in trying to consolidate some code.

The downside is my pull request isn't quite ready yet because I'm not sure of the best way to try and add support for VersionSpec to the install command. Any thoughts on that?

May 26, 2011 at 2:12 PM

I was hoping to re-use the Version switch and allow the user to specify either an exact version or a spec and figure it out by parsing it. The problem is Version "1.0" does not equal VersionSpec "1.0", it equals VersionSpec "[1.0]", meaning there'd be no way to specify VersionSpec "1.0". And if you could live with that, the behavior internally is different between Version "1.0" and VersionSpec "[1.0]" (maybe, I'm getting failing tests and seeing different code paths, but some of the failures are due to improperly setup mocks when swapping in VersionSpec for Version). 

So, for now, I'm going to add a VersionSpec switch, with Version superseding VersionSpec should both be provided. That's the only thorough option I can see right now.

May 27, 2011 at 2:17 AM

Was working on this today and noticed the allowedVersions attribute in the packages.config. Seemed fitting, I renamed my VersionSpec switch to AllowedVersions and got both working with Install command. I'm struggling with the reviewboard process right (on another thread). Fork is here for anyone following along:

May 27, 2011 at 2:21 AM

Just send a pull request. And we'll review it there.

May 27, 2011 at 2:33 AM

Done, thx. 

May 27, 2011 at 2:47 AM

I added comments to the review.

May 27, 2011 at 3:27 AM

Thx, that was quick. :-)

You mentioned wanting to discuss support for allowedVersions in packages.config?

May 27, 2011 at 3:46 AM

Yep. Right now packages.config is for restoring exact versions. Making allowedVersions work could impact that and I'm not sure if it makes much sense (also because we never update the project outside of visual studio). Also, we don't install dependencies when restoring packages from packages.config for that same reason. 

May 27, 2011 at 4:03 AM

I hadn't seen allowedVersions mentioned in the docs - was it a recent addition? What is it used for?

Does it make sense to call the new switch on InstallCommand AllowedVersions? When I ran across the allowedVersions in the source I thought I'd found a nice way to tie things together, but I'm still new to the details here.

Having either allowedVersions in config or the switch is useful to me because I'm wanting something similar to Maven's snapshot feature for use with an internal artifact repository where packages may be updating frequently. In my world, I'm only setting up packages.config manually and not even using the Visual Studio add-in - along the lines of the discussion here: (ah, and this spec, hadn't seen that yet:

If I only have the switch, then I'll have to set up a .bat file or something else to run NuGet.exe for each package - I think it'd be cleaner if I could use allowedVersions in the packages.config and just feed that once to the command line tool.

Oh, and skipping dependencies -- I was thinking it'd be nice to have an extra setting to force dependencies here.

Is there a better approach here? Seems I'm now shoehorning too much in here.

May 27, 2011 at 4:12 AM

"allowedVersions" is in 1.4 (which is currently in development) the docs out there are currently for 1.3. That feature is for updates. It allows you to specify a range to look for updates when using the VS client. You can update to a specific version of a package but that feature is more relevant when updating all packages within the solution/project.

People have asked for the maven like support but if we make the command line and VS plugin diverge, it will cause confusion. Updating packages from outside visual studio is something we're looking at (, but for now anything we hack together without thinking about the end to end will just be half baked. Right now as it is, install packages from packages.config means "restore the packages folder for everything I have installed in my project" and nothing else.

Packages.config isn't meant to be authored as it is today. That said it doesn't mean we can't think about this in the future.

May 27, 2011 at 4:26 AM

Well, now I feel like my contribution is quarter-baked :) as I get caught up reading I should've done earlier this week. That's what I get for "I'll browse the code and see how hard ... hey, let's change that ... ooo, and that ... and ...." ... lost myself in the IDE.

This work item and discussion (and related fork) appear very similar:

Thx for your patience and feedback. 

May 27, 2011 at 2:20 PM
Edited May 27, 2011 at 2:41 PM
dfowler wrote:

Right now as it is, install packages from packages.config means "restore the packages folder for everything I have installed in my project" and nothing else.

Can you include some examples of packages.config as written by the VS plugin where allowedVersions is included?

(Thinking out loud here...) As far as I can tell from the sources now, you'll only have two options with allowedVersions:

<package id="Foo" allowedVersions="(,2.0)" />

<package id="Foo" version="1.5" allowedVersions="(,2.0)" />

In the latter case, the InstallCommand could do what I coded it to do if both -Version and -AllowedVersions switches are provided, which is to ignore AllowedVersions. But then if it ignores AllowedVersions, why have it there? It'd be more mature to attempt to find the exact version first then use AllowedVersions as a fall-back, though I'm not sure that'd be a very common use case, "I really want 1.5 and only 1.5, unless it's not there, then I'm okay with whatever version you find up to version 2.0." 

In the former case, there'd be nothing else to do.

So ... I guess the desire then is to store allowedVersions for a different command? Install means use version, Upgrade means use allowedVersions and write the new version to the version attribute? Should the command line go in a similar direction? Or is there another direction here?

Jun 10, 2011 at 3:02 PM

Been following the progress in the commits since I submitted the pull request - looking like I'll be getting what I'm wanting in the next release. Thx again!