Weird scoping problem

[Hugh Cole-Baker]

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?

[jcbollinger]

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