I could have sworn I've said some of this before, but I'm not sure
where. So sorry if this is repetitive.
First, I think what your implementation is missing is a resource name
that's globally unique to the host. Let's say I want to install
different versions of sqlalchemy in /venvs/staging and /venvs/prod. I
need some resource name to distinguish those three resources. The
best option I can think of is to munge the virtualenv and package name
together into a string:
Package { provider => 'pip' }
package {
'/venvs/staging::sqlalchemy':
version => '0.8.6';
'/venvs/prod::sqlalchemy':
version => '0.7.9';
}
You could introduce a new type, or maybe shoe-horn this into the
existing type, where an unqualified package name would be installed
systemwide. You'd need to pick your delimiter carefully -- don't take
'::' as a recommendation :)
But another, entirely different approach may be to think of the
virtualenvs as the resources, with the packages just a property:
python::virtualenv {
"/path/to/virtualenv":
python => "/path/to/python",
packages => [ "package==version", "mock==0.6.0",
"buildbot==0.8.0" ];
}
In fact, that's exactly what the python module in PuppetAgain does[1].
More generally, I find it helpful to design puppety things from the
front back: start by asking "how do I want to use this from my other
manifests", then work from there to the best and simplest means of
implementing it.
Dustin
[1] https://wiki.mozilla.org/ReleaseEngineering/Puppet/Modules/python
/ https://github.com/mozilla/build-puppet/tree/master/modules/python
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/CAJtE5vQgX2uixE9cvM%2B9SNDp8zKBY1uUsgOM4w%2Bs_h5T2QGtdA%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.
