Get-Package -filter should use wildcards instead of contains

Jan 13, 2011 at 4:04 PM

By using implied "contains" it makes it difficult to isolate a single package from local or remote sources:

PM> get-package xunit -list | select id, version | format-table -auto

Id               Version   
--               -------   
NUnit            2.5.7.10213
Should           1.1.12.0  
ShouldFluent     1.1.12.0  
xunit            1.7.0.1533
xunit.extensions 1.7.0.1533

Unless I'm missing something, there's no way to obtain a specific package. This is a real PITA if you just want to install a package that you know the name of ahead of time. Instead you have to finagle with further where-object or -first and -skip parameters. I would rather see:

ps> get-package *xunit*

...if I want "contains" behaviour. This is more consistent with powershell and besides that, IMO, way more useable because I can now type:

ps> get-package xunit | uninstall-package

...and not have to worry about it also uninstalling nunit, should, shouldfluent etc also.

 

 

Jan 13, 2011 at 5:16 PM

I agree that using wildcard makes sense from the PS point of view. However, the get-package command makes an Odata call under the hood, and if I'm not wrong Odata doesn't support wildcards (natively). (Fowler and Ebbo can correct me if I'm wrong.)

The good news is that if you want to install a specific package, you can simply do:

install-package xunit

uninstall-package xunit

Developer
Jan 13, 2011 at 5:23 PM

The Get-Package -Filter parameter was meant to discover packages which is why it performs searches in the id and description (and now tags)

Maybe we need for a way to surface the functionality of Find-Package cmdlet via Get-Package and have it perform wildcard searches on the client.

Developer
Jan 13, 2011 at 6:57 PM

We don't have to do that. Ideally we'd translate the wildcards into the appropriate method calls (where possible) and send them to the repository (odata or local).

Developer
Jan 13, 2011 at 7:08 PM

@oisin if you know the exact package name why not just use the tab completion instead of piping?

Jan 13, 2011 at 7:16 PM

@dfowler:

get-package xunit | where-object { $_.version -lt "1.0.0.0" } | update-package

I don't know how contrived that seems to you, but it's just an example.

-Oisin

Jan 13, 2011 at 7:23 PM
Edited Jan 13, 2011 at 7:23 PM

Also, I really think -Filter should be -Name to be consistent with other commands. It's not really a filter in the style of the activedirectory or exchange (for example) powershell filters which are actually expressions that are translated into native queries:

ps> get-aduser -filter "Name -eq 'john'"

-Oisin

Developer
Jan 13, 2011 at 7:38 PM
Edited Jan 13, 2011 at 7:39 PM
oisin wrote:

@dfowler:

get-package xunit | where-object { $_.version -lt "1.0.0.0" } | update-package

I don't know how contrived that seems to you, but it's just an example.

-Oisin

I'm not sure if its just me, but I'd just type:

Update-Package xu{tab} {enter}

This is one of the huge benefits of tab expansion.

Jan 13, 2011 at 8:00 PM
Edited Jan 13, 2011 at 8:03 PM

Yes, but the problem with that particular syntax is that it's all or nothing: all projects using that package are updated to the latest version. My example shows how to update with a minimum version, not just updating everything to the latest which you may not want. Again, don't look too hard at the example. If we're hosting powershell, commands need to be powershell friendly. If everything is just a single command, we may as well just host cmd.exe and use batch files ;)

Another example:

# only update projects foo and bar and if they are using a "buggy" version (1.2.3.4) of xunit then update, else leave them alone.
get-project foo, bar | get-package xunit | where-object { $_.version -eq "1.2.3.4" } | update-package

Does this make more sense? I'm trying to highlight the advantages of enabling pipelining. Tab expansion is useful yes, but it is just a small part.

-Oisin

 

 

Developer
Jan 13, 2011 at 9:44 PM

We went from talking about Get-Package's -Filter command to talking about pipelining. We know that we have to improve pipelining but that's not what this topic is about which is why I had a hard time grasping what the complaint was based on the examples you provided.

Jan 13, 2011 at 10:10 PM

@dfowler - sorry for getting a bit carried away here and I understand where you're coming from. The version of NuGet that I have in my local repository supports pipelining fully ;) The original issue affects me much more than it would affect your version of the repository. If my push request goes through, then it will make more sense to you practically speaking.

-Oisin

Developer
Jan 14, 2011 at 1:42 AM

No biggie, can you send a review request for your changes on reviewboard?

Jan 14, 2011 at 4:25 AM

Yeah, I'd love to, only I can't get it working. The extension is totally broken (yes, I tried both the specified changeset for the extension and the tip) on HG 1.7.3 client which is what I'm using.

 

 

Developer
Jan 14, 2011 at 7:39 PM

We'll take a look at your review, but next time can you break unrelated changes into different changesets? It's pretty hard to review big changes like this with lots of little unrelated things.

Jan 14, 2011 at 7:55 PM

@dfowler - definitely, I'm sorry about that. I was still trying to get to grips with HG and made a couple of mistakes the first half dozen changesets - files omitted, etc. I started out intending to keep changesets isolated to atomic fixes/changes but I was still coming to terms with the codebase and the changesets weren't correct most of the time. From this point on, I should be good. Thanks for your patience.

Developer
Jan 14, 2011 at 8:11 PM

Don't sweat it, the changes you made are great :).

Jan 21, 2011 at 10:16 PM

So getting back to the original issue -- Get-Package should use wildcards -- it looks like we'd need to write some code to translate wildcarded expression to OData queries. Shall I take a stab at it?

-Oisin 

Jan 21, 2011 at 10:39 PM

Feel free to go for it.

Developer
Jan 23, 2011 at 1:33 AM

I don't think we want to do this for 1.1. Maybe for 1.2 unless the change is seemly small (but I doubt it will be).

Jan 23, 2011 at 1:37 AM
I agree. If I'm going to do it properly, I need to be constructing
odata queries to pass through to the repo. It touches a few different
areas and the need for tests etc make it non-trivial.

On Saturday, January 22, 2011, dfowler <notifications@codeplex.com> wrote:
> From: dfowler
> I don't think we want to do this for 1.1. Maybe for 1.2 unless the change is seemly small (but I doubt it will be).
> Read the full discussion online <http://nuget.codeplex.com/Thread/View.aspx?ThreadId=241648&ANCHOR#Post553801>. To add a post to this discussion, reply to this email ([email removed]) To start a new discussion for this project, email [email removed] You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe <https://nuget.codeplex.com/discussions/241648/unsubscribe/> on CodePlex.com. Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at CodePlex.com

--

---
404 signature missing