Agreed about not adding *too* many parameters. I'd hoped to think up a name that was language/provider agnostic but conveyed the idea of an alternate root to install non-system-wide packages in. This could also be used by gem, npm (if we ever get a provider for it) and other languages/systems that support such things.

The issue here, which is going to come up soon (i.e. next in line for me after I get the pip provider itself straightened out, and maybe should be worked as part of this) is that the virtualenv root (this param) really needs to be part of the package identity. i.e.:

package {'requests': provider => pip, virtualenv => '/tmp/foo' }
package {'requests': provider => pip, virtualenv => '/tmp/bar' }

should be valid, and able to be applied. Yes, I just opened that can of worms...