On 11/2/2013 3:31 AM, Jason Antman wrote:
[snip]
package installation - but the module (or at least our version of it)
doesn't handle requirements files, and uses a define to pip install
packages, so a given package can only be installed in one venv on a node.
I have a hacked-up python virtualenv module, since I hadn't seen any
when I started out. I got around the singleton define problem you've
outlined by adding an optional package name parameter, which defaults to
the name of the define. This way you can keep the old behaviour for
simple cases:
python::virtualenv::package {
'<packagename>':
venv => '<destination env>'
}
but in the case where you want the same package in two environments, you
use a globally unique resource name and use the optional param:
python::virtualenv::package {
'<env>-<packagename>':
venv => '<destination env>',
package_name => '<packagename>'
}
When these defines are called internally (as a side effect of installing
dependencies for an app, for example), I always use the latter format.
That doesn't fix the requirements.txt problem, of course. I've been
looking at that too, but I don't feel that a pure puppet DSL solution is
necessarily the right way to approach it. A custom ruby plugin might be
a better solution.
-Taj.
--
You received this message because you are subscribed to the Google Groups "Puppet
Users" 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-users/527494B5.60708%40gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.
