sorry to be pendantic, but ...

[jflorian]

This module is quickly shaping up to a real gem for dealing with CUPS, which is one of those services that just doesn't want to be tamed by puppet so easily -- witness its bizarre habit of rewriting config files immediately after a puppet File type is applied. With this module, it's now ridiculously easy. Congrats and many thanks for making it!

However, there's one minor detail I think (IMHO) would improve this module even further and that's the choice of naming. We're really not creating a printer here, but instead printer_queue. For example, I'm going to be using this module to create queues that are daisy-chained across a WAN such that a user submits a print job to queue X where CUPS forwards the job for X to another queue named Y on a distant host and the process may be repeated again to Z. It just seems weird to think of X and Y (and to some extent, even Z) as printers.

I see that the CUPS documentation liberally uses the two terms interchangeably, which is understandable. Perhaps the best solution would be to support an alias of some sort so that our puppet manifests could have something like:

printer_queue { 'X':
...
}

printer_queue { 'Y':
...
}

printer { 'Z':
...
}

[mosen]

Let me think about some of the parameter naming etc. I've seen mentions of printer, printer queue and printer destination from memory. Logically you are right, it isn't a printer at all. I named it that way because I thought maybe i'd gloss over the detail and give osx admins something that was easily identifiable.

Also, thanks for the patience!

[leoarnold]

@jflorian I see the technical validity of your remark, but I cannot imagine how the types printer and printer_queue could differ on the type implementation level. If you see a possible difference, please give an example.

@mosen I vote to keep calling the type 'printer' as the resulting entities will always be listed at

http://localhost:631/printers

[jflorian]

@leoarnold, I cannot imagine any difference at the implementation level, which is why I suggest that an alias might be best. In other words, it would only benefit the puppet manifests where either is used to help clarify the intent. Thus, in my OP, queue X forwards to queue Y which forwards to a genuine printer Z. X and Y are definitely not printers, although it wouldn't necessarily be wrong to think of Z as queue.

[mosen]

I'll take a look at aliasing the resource as printer_queue.