The Puppet Labs Issue Tracker has Moved:

This issue tracker is now in read-only archive mode and automatic ticket export has been disabled. Redmine users will need to create a new JIRA account to file tickets using See the following page for information on filing tickets with JIRA:

Bug #10848

When is "class { foo: }" not equivalent to "include foo"?

Added by Lars Kellogg-Stedman over 4 years ago. Updated almost 3 years ago.

Status:DuplicateStart date:11/15/2011
Priority:NormalDue date:
Assignee:-% Done:


Target version:-
Affected Puppet version:2.6.0 Branch:

We've Moved!

Ticket tracking is now hosted in JIRA:


If I have:


And in autofs/manifests/init.pp I have:

class autofs {

And in virtcluster/manifests/autofs.pp I have:

class virtcluster::autofs {
  include autofs

This works as intended. However, if I replace include with a new-style class directive:

class virtcluster::autofs {
  class { autofs: }

This fails with a “duplicate definition” error:

Duplicate definition: Class[Virtcluster::Autofs] is already defined; cannot redefined at ...

Is this expected? I thought that class { foo: } was supposed to be equivalent to include foo, but obviously the semantics are different.

I’m using 2.7.6 right now, but I’ve seen this with earlier versions as well.

Related issues

Duplicates Puppet - Bug #5046: Mixed invocation of parameterized classes leads to order ... Needs Decision 01/13/2011
Duplicates Puppet - Bug #2053: Relative namespacing of class/define names results in big... Accepted 03/06/2009


#1 Updated by Matthaus Owens over 4 years ago

  • Status changed from Unreviewed to Rejected

If you replace

class virtcluster::autofs {
  class { autofs: }


class virtcluster::autofs {
  class { ::autofs: }

it works fine. In your example the lookup happens in the following order…

virtcluster::autofs, then ::autofs

Because an autofs class is found at virtcluster::autofs, that is what puppet uses.

In the updated example, lookup starts at ::autofs and as autofs is found there, that is what puppet uses.

Namespace lookups are relative to the current namespace (virtcluster::autofs), so it starts there and works toward top level. Adding leading colons will use absolute namespace lookup rather than relative lookup. This is the way namespaces are looked up during compilation and while counterintuitive, this is the expected behavior.

Also see for more details.

#2 Updated by Matthaus Owens over 4 years ago

  • Status changed from Rejected to Re-opened

#3 Updated by Matthaus Owens over 4 years ago

  • Category set to plumbing
  • Status changed from Re-opened to Accepted
  • Affected Puppet version set to 2.6.0

Sorry, I gave you a fix to make your class statement work, but you are correct, the include and class statements should be consistent in their behavior in this regard.

#4 Updated by Lars Kellogg-Stedman over 4 years ago

So maybe this is a documentation bug? I’ve been through the documentation at several times, and there’s nothing there to indicate that including classes via “class {}” is any different from using “include”. Maybe a note in the “Parameterised Classes” section? E.g:

While the class {} syntax with no parameters is largely equivalent to include, name resolution will start in the local scope rather than the local scope. In other words, class { ::foo: } is equivalent to include foo.

#5 Updated by Nigel Kersten over 4 years ago

  • Status changed from Accepted to Needs Decision
  • Assignee set to Anonymous
  • Keywords set to devtriage

I suspect that our changes in behavior for Telly where we’re removing dynamic variable lookup may affect this and make this actually work.

I need developer input on that one though.

#6 Updated by Nigel Kersten over 4 years ago

  • Target version set to 3.x

#7 Updated by Nick Fagerlund over 3 years ago

The OP on this issue is an unholy combination of #2053 (relative class names are teh suck) and #5046 (order-dependence of resource-like class syntax and include).

Those two dragons aside, the docs make the distinction between the syntaxes mostly clear, and the rewritten language guide I’m posting in a few days will make it even more so, with notes about historical context and all that rot. Closing this as a dupe of both #5046 and #2053.

#8 Updated by Nick Fagerlund over 3 years ago

  • Status changed from Needs Decision to Duplicate

#9 Updated by Nick Fagerlund over 3 years ago

  • Keywords deleted (devtriage)

#10 Updated by Anonymous over 3 years ago

  • Target version deleted (3.x)

#11 Updated by Anonymous almost 3 years ago

  • Assignee deleted (Anonymous)

Also available in: Atom PDF