On Wednesday, November 21, 2012 12:13:22 PM UTC-6, Hugh Cole-Baker wrote:
>
> Using puppet 3.0.1 I ran into an odd scoping problem - I've got a class
> called 'lettuce' in a module named testtools, like this:
>
> class testtools::lettuce {
> require pip
>
> Package {
> provider => pip,
> }
>
> package {
> "lettuce":
> ensure => installed;
> "lettuce-webdriver":
> ensure => installed;
> }
> }
>
> Then I've got a class 'pip' in a module named 'pip' (the class is in the
> module's init.pp):
>
> class pip {
> package { "python-pip":
> ensure => installed,
> }
> }
>
> When I included testtools::lettuce on a node, it tried to install the
> 'python-pip' package, *using* pip, i.e. trying to run /usr/bin/pip install
> -q python-pip
> The python-pip package is meant to be using the default 'apt' provider,
> but it looks like the Package { provider => pip } from a completely
> different module is overriding its default. I thought Puppet 3's removal of
> dynamic scoping wouldn't allow this?
>
As I understood it, the dynamic scoping changes were only about variable
references, but you are right that the scope of resource defaults is a
similar issue.
For your case, I would recommend just expressing alternative providers
explicitly instead of by setting a resource default. If you want to do
that without writing "package => 'pip'" on every package, then you could
wrap it in a defined type. That would also have the advantages of being a
bit clearer at the point where you declare pip packages, and of localizing
the pip dependency better:
define pip_package ($ensure) {
require 'pip'
package { $name:
ensure => $ensure,
provider => 'pip'
}
}
class testtools::lettuce {
pip_package {
'lettuce': ensure => installed;
'lettuce-webdriver': ensure => installed;
}
}
May I say, however, that I *strongly* recommend avoiding the use of
multiple package providers whose scopes overlap. On systems that provide a
built-in package manager (most systems these days), that implies using only
the built-in manager. Instead of using alternative package providers,
repackage software so that you can manage it via the native package
manager. It's all about ensuring that the package manager has all the
information it needs to do its job properly.
Exceptions can be made for systems, such as Windows, whose package
management is too rudimentary to be reliable anyway. (I'm talking about
the systems themselves, not Puppet's providers.)
John
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/s_sK2xdhq1IJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
