On 03/12/2014 11:23 PM, Trevor Vaughan wrote:
package_yum
package_gem
etc
This would probably be pretty quick work overall and, of course,
eliminates all of the conflict issues.
Butit doesn't feel like a good solution.
I agree that the implementation you sketched is messy, but
I think I just realized what I actually want to be able to do when creating
types in a generic sense.
newparam(:name) do
isnamevar
...
end
newparam(:provider) do
isnamevar
...
end
Now, in the catalog, what would happen is that *all* parameters that were
named as namevars would be
I am kind of interested in what you describe. I think for our environment,
keeping the package type as is and creating a new ³gem² type that inherits
from package would be just fine. If we only consider RHEL-based systems
for a moment, is there really a possible conflict scenario other than
Looking at the list of providers for file, on RHEL systems you'll probably
only run into conflicts with *native* (yum, rpm, up2date), pip, and gem.
I also am not opposed to this. As far as I can tell, 'package' is the only
type that doesn't follow the rules of the other types (manage one thing
On Thursday, March 13, 2014 8:02:22 AM UTC-5, Trevor Vaughan wrote:
Looking at the list of providers for file, on RHEL systems you'll probably
only run into conflicts with *native* (yum, rpm, up2date), pip, and gem.
I also am not opposed to this. As far as I can tell, 'package' is the only
SecondaryPackage wouldn't fix it if you wanted to install using pip and gem
on the same system.
I do think that native packages are what Package should manage and
everything else should be its own type/provider combo because they are,
indeed, *something else*.
This gets hairy with RPM since
On Thu, Mar 13, 2014 at 9:23 AM, John Bollinger
john.bollin...@stjude.org mailto:john.bollin...@stjude.org wrote:
That would work for me. Alternatively, there could be just one new
type, say SecondaryPackage, that rolled up gem, pip, fink, etc.
On 03/13/2014 02:50 PM, Trevor Vaughan wrote:
Yeah, after all this I think break out all of the subtypes, make the
suitable but default the native *package* statement to whatever it does now.
Then...admins be careful!
We can do some fanciness by mining the catalog when building the subtypes
and making sure there is no conflicting native
Cool, so it sounds like we have consensus on post_resources_eval? If so,
I'll take on putting together a pull request for the rename (unless someone
else would like to work on it?)
-Jeff
On Fri, Mar 7, 2014 at 1:12 PM, Trevor Vaughan tvaug...@onyxpoint.comwrote:
I think this hits the nail on
Hi,
we are just started to get more concrete on how to implement things for
4x and breaking it down into actionable items. If you have looked in
Jira, there are currently 5 big issues in the epic Biff the Catalog
Builder [1] - which is the goal (a new, better performing catalog
builder (what
Henrik,
All of this looks great to me. However, I was asked by someone recently if
the language had the concept of a private class scope.
We're seeing more patterns in the wild where people are creating classes
that are only meant to be used internally to the class and not exposed to
the rest of
Hi Trevor, this is tracked under PUP-523, please feel free to chime in on that
ticket if you have additional use cases/requirements it doesn't address.
https://tickets.puppetlabs.com/browse/PUP-523
--eric0
On Mar 13, 2014, at 5:59 PM, Trevor Vaughan tvaug...@onyxpoint.com wrote:
Henrik,
Got it. Just thought of it while reading the e-mail. I'll head over there
tomorrow to get it in.
Thanks,
Trevor
On Thu, Mar 13, 2014 at 10:01 PM, Eric Sorenson
eric.soren...@puppetlabs.com wrote:
Hi Trevor, this is tracked under PUP-523, please feel free to chime in on
that ticket if you
On 2014-14-03 1:59, Trevor Vaughan wrote:
Henrik,
All of this looks great to me. However, I was asked by someone recently
if the language had the concept of a private class scope.
Not yet.
We're seeing more patterns in the wild where people are creating classes
that are only meant to be
So, it sounds like we're getting everything we wanted! That's great to hear.
So, I suppose that I should have been clearer. We are starting to label all
variables and class calls with $::name to ensure that the full removal of
dynamic scoping works properly. While more verbose, I find it to be
On 2014-14-03 3:25, Trevor Vaughan wrote:
So, it sounds like we're getting everything we wanted! That's great to hear.
So, I suppose that I should have been clearer. We are starting to label
all variables and class calls with $::name to ensure that the full
removal of dynamic scoping works
16 matches
Mail list logo
