Now that #6527 is merged into master, it is possible to easily add support for virtualenvs and fully complete #3572.
A virtualenv argument could be added to the package type in order to instrument pip to install the requested package into the given virtualenv directory.
For example:
package { "my-python-package":
ensure => latest,
provider => pip,
virtualenv => "/path/to/virtualenv
}
The content of the virtualenv parameter will be passed directly to the --environment parameter of the pip install command
Some references:
You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account
To avoid new properties on package, it seems the ‘root’ property (currently read-only) could be adapted. It refers to the installation root of a package in the ‘sun’ provider, which sounds like the same thing as virtualenv.
Seems like a good idea (although less explicit than virtualenv).
I’ve already implemented the whole thing using a new virtualenv parameter, but changing it back to use root can be done quickly.
Is there a general consensus in avoiding new properties on existing resources?
And what about decision? Will be accepted in upstream?
Daniel – assigning to someone so a decision can be made.
Jonathan – apologies the ball was dropped on this ticket.
James Turnbull wrote:
Daniel – assigning to someone so a decision can be made. Jonathan – apologies the ball was dropped on this ticket.
Sorry – there have been a few tickets like this where code was submitted, but not as a pull request, and they got lost some time in the past.
I am a little concerned that this doesn’t touch what I think it needs to: it doesn’t look like it makes the environment part of the “identity” of the package type, so you couldn’t install “foo” into both the root, and an environment.
Ultimately, though, right now the team isn’t in a position to make a call on this: there are a pile of model problems – like this one – in the package type that we need to address. I have attached this ticket to our roadmap with a view to having us sit down and figure out what the model should look like. You can see that in the RoadMap