Is it possible to tell NuGet where to store packages for a solution?

I haven't been able to find an answer to this question. I used Nu previously and had the ability to identify where the "gems" were to be installed. For instance, I like to keep my project structure like this:

MyProject
    |-MyProject.build
    |-MyProject.sln
    |-doc
    |-lib
    |  |- ... my packages/gems ...
    |-sql
    |-src
    |  |-app
    |  |-test
    |-tools

As you can see I like to keep a "lib" folder for third party libraries being used in my solution. Using Nu, while in the root d开发者_开发问答irectory of my project, I could simply use the command:

nu install log4net --location=lib

Doing so would grab the requested package and place it in my "lib" folder for referencing later.

So, is this possible using the "Package Manager Console" in VS.NET? Would I have to use some other method? Thank you for your help!

Sebastiens post is all nice, but I just really care where the packages go. Nuget (or any package manager) shouldn't assume it knows best.

And it shouldn't assume solution == complete source tree. To clarify: my source tree contains 80+ solutions all in different locations, a package repo relative to the solution folder results in 80+ clones of all packages, this is slow and wasteful.

for now (nuget 1.3) an undocumented hack is to put a nuget.config file next to your solution with a relative path to the repo in it like so

<settings>
    <repositoryPath>..\..\lib</repositoryPath>
</settings>

this may or may not work for you as it is a hack.

Sebastien Lambla wrote a recent blog post concerning OpenWrap, but also talking about NuGet. In it, he opines that people asking to put packages in other locations are really asking the wrong questions:

When the question “can I change where packages go”, usually the underlying, real question, is one of two: “I want them in /lib with the rest of my traditional libraries”, or “In my corporate environment I don’t want to check-in all the dependencies because I don’t care about xcopy deployment”.

And then goes on to explain how the libraries "owned" by your package manager really aren't the same kind of beasts as other libraries that you depend on.