The -Filter parameter should be more like Get-WMIObject's

Apr 28, 2011 at 5:01 AM

With over 2000 packages in the main nuget feed, we need to be able to do our filtering server-side. The current filter parameter only supports a case-insensitive string comparison against both Id and Description.

I've been complaining about it on Twitter, so I figured I'd offer a constructive suggestion and implementation option:

Use the DynamicExpression parser from the Dynamic LINQ sample, and let users pass in full expressions to -Filter which would be inserted into the DynamicQueryable .Where() clause. 

Then we'd be able to write complex queries, including filtering on tags and matching just the Id (instead of the Id and the description), etc.


Apr 28, 2011 at 5:49 AM
You can also construct an OData query and make it a nuget package. I constructed one recently for NHibernate as an example to a buddy who was wanting to trigger builds in TeamCity with the UrlTrigger (when a new version of NHibernate or something else came out).

Apr 28, 2011 at 4:34 PM
ferventcoder wrote:
You can also construct an OData query and make it a nuget package...

Huh? I don't get it.

I originally suggested we could just pass the -Filter parameter straight to the $filter parameter on OData, and I was told that can't work because not everything is OData, so the solution has to work with LINQ...

But how does making a new nuget package out of an OData filter help? What does it do?

Apr 28, 2011 at 5:51 PM
Sorry, I meant to type more. Got a little click happy on the send button.

What I meant to say is that you could create a nuget package that imports a powershell module function that does a query for you. Something like:

Get-PackageFiltered nhibernate /includeTags /includeDescription

and in the background it could execute a query similar to the above. Of course that would only work against OData feeds. Of course it could have a fallback to just calling Get-Package -remote -filter nhibernate if the OData query fails (like in the case when you are not hitting an OData feed).

Does that make sense?

The idea itself is good. I was just offering a solution that could be done in the interim (or as a solution if the idea is not accepted).

Apr 28, 2011 at 5:54 PM

Just to clarify and answer an earlier question, NuGet works against two types of feeds, an OData feed and a folder containing files.

In the second case, you can drop a set of package files into a folder, add that folder path to your package sources, and run all of our NuGet PS commands against them.

That’s why we can’t just pass –filter to the OData URL, because there is no URL in that case. Instead, what our commands do is build up an IQueryable. We have implementations of IQueryable for the folder approach and for OData.

However, if you know you’re querying an OData package source, you could do the approach that dotnetjunky and ferventcoder mentioned.

Apr 28, 2011 at 5:56 PM

wait a minute, I didn't mention anything in this thread. :)

Apr 28, 2011 at 5:56 PM
The point I'm really trying to make here is that nuget is a framework that you can extend to make it do exactly what you said you you were complaining about. If it's a good enough idea, it will eventually make it back into the framework itself.

NuGet is extendable with powershell modules, so you can make it do just about what ever you want with the right packages.
Make sense?

Apr 28, 2011 at 5:58 PM
I believe he is talking about an earlier question.
Apr 28, 2011 at 9:45 PM
Edited Apr 28, 2011 at 9:46 PM

Yes, well ... nuget is also open source, so I can just rip out the Get-Package cmdlet and apply my DynamicExpression patch and stick *that* in a new module ...

I'd rather convince the core team that it's the right approach and get it in the product so I don't have to maintain my scripts/forks/patches.

On top of that, I'm trying to deploy a NuGet server for PowerShell modules on -- and I don't want to have to serve up the full list of thousands of modules (and scripts) every time someone wants to look for something! To avoid that, I need the fix to go into the core :-)

Apr 28, 2011 at 9:49 PM

Sure, we’d love to have something in the core. We just need to figure out how. Did you understand my explanation why we can’t just append -filter to the OData URL?

When you run the PS commands, we don’t know that you’re running against OData or the file system, or something else in the future. What we’d need to do is come up with a way to translate the –filter string into a queryable expression.

That would make a great contribution to NuGet! J

Apr 28, 2011 at 10:24 PM

My bad if I came across salty. Not intentional. :P

"Be passionate in all you do"

Apr 28, 2011 at 11:06 PM

Mmm... Salty.


Apr 29, 2011 at 1:52 AM

Yeah, I totally understand that you need to work against IQueryable -- that's why I'm suggesting the use of the DynamicExpression parser.

Apr 29, 2011 at 4:56 PM

I haven't looked into what that will take. So the expression would have to be a LINQ expression as a string in this case, right?

Get-Package -filter 'Description.Contains("Hello") And Id.StartsWith("X")'

Seems like an interesting suggestion, but could take us a while to get to. Maybe if we can find someone willing to take a crack at it.

Is there a bug logged on this?