Re: [Puppet Users] package conflict resolution method:

2013-11-27 Thread Thomas Noonan II
I personally went the tiny class route, creating a module with a bunch of little classes for various packages. I opted for this route as it let me deal with naming differences between apt and yum, and let me do repo dependencies for stuff in Epel. Here is an example: https://github.com/TJNII/pupp

Re: [Puppet Users] package conflict resolution method:

2013-11-21 Thread jcbollinger
On Tuesday, November 19, 2013 1:48:26 PM UTC-6, Matt Simmons wrote: > > Hi John, > > I'm new around here, but I'm also in the same situation as Tom, who > started this thread. > > I was wondering if you could expound a little bit on the better solution > that you mention. I write what I could

Re: [Puppet Users] package conflict resolution method:

2013-11-20 Thread Jason Antman
Matt, I can't speak for exactly what John was implying, but I've been working on something similar recently, and facing more or less the same problems that you're implying below, so I'll give you my take on it. 1) Yes, it means factoring "all" possibly-shared resources out into discrete classes.

Re: [Puppet Users] package conflict resolution method:

2013-11-19 Thread Matt Simmons
Hi John, I'm new around here, but I'm also in the same situation as Tom, who started this thread. I was wondering if you could expound a little bit on the better solution that you mention. I write what I could refer to as "third grade puppet", but I'd like to get better. When you suggest f

Re: [Puppet Users] package conflict resolution method:

2013-11-04 Thread jcbollinger
On Monday, November 4, 2013 9:14:02 AM UTC-6, jcbollinger wrote: > > resource and class parameter overrides may fail to have the expected > effect on resources that are guarded by ensure_*() functions > > Sorry, I was a little too brief there. Class parameter overrides don't work anyway, but w

Re: [Puppet Users] package conflict resolution method:

2013-11-04 Thread jcbollinger
On Friday, November 1, 2013 4:16:29 PM UTC-5, Tom Noonan wrote: > > That looks like a good solution, thanks! > > If by "good" you mean "quick and dirty" then you are right. Relying on ensure_packages() and especially ensure_resource() may get you in trouble, however, and at minimum doing so

Re: [Puppet Users] package conflict resolution method:

2013-11-01 Thread Jason Antman
Tom, I've actually been working with similar issues lately (and am in the process of working on a virtualenv module). I have a python module that includes classes for the common dependencies (i.e. "require python::pyyaml") and have been pretty happy with that pattern so far, but if you want, I be

Re: [Puppet Users] package conflict resolution method:

2013-11-01 Thread Tom Noonan
That looks like a good solution, thanks! On Fri, 1 Nov 2013 14:11:44 -0700 Ryan Coleman wrote: > On Fri, Nov 1, 2013 at 2:03 PM, Tom Noonan wrote: > > > Can the list please advise on what best practice is in this > > case? > > > > Hi Tom, > > The puppetlabs/stdlib module includes the

Re: [Puppet Users] package conflict resolution method:

2013-11-01 Thread Ryan Coleman
On Fri, Nov 1, 2013 at 2:03 PM, Tom Noonan wrote: > Can the list please advise on what best practice is in this > case? > Hi Tom, The puppetlabs/stdlib module includes the ensure_packages() and ensure_resource() functions. Both are intended for expressing common resources which will onl

[Puppet Users] package conflict resolution method:

2013-11-01 Thread Tom Noonan
Hello, list: I have two puppet modules that are unrelated to each other, but both have (unrelated) Python scripts that parse YAML. As such, both have a block like the following in their manifests for the PyYAML script dependency: package { 'PyYAML': ensure => installed,