On Wed, Mar 12, 2014 at 6:35 PM, John Bollinger
<john.bollin...@stjude.org> wrote:
> No, that's not really a difference at all. 'command' is the namevar of the
> Exec type (it has no 'name' property), and 'name' is the namevar of Package.
> It is the fact that 'name' is the namevar of Package that makes the package
> version not work. That the Exec version does work is the result of a
> special-case exception for that resource type; it has nothing in particular
> to do with the name of the type's namevar.
My question is why does $command or $pkgname (in my example) have to
be a namevar? I assumed $command actually wasn't a namevar. I
understand the problem now though (see below).
> I think Package and most other built-in types were designed around the idea
> that only one provider would ever be used on any given target system. And
> indeed, that's a superior policy, at least when it comes to packages. That
> it works -- up to a point -- for multiple package providers is a secondary
> feature. Now I'm not saying that's an ignorable feature or one that
> shouldn't be improved, but on the other hand I do not favor creating
> additional special cases for particular resource types.
That may very well be the historical reason. It's a totally arbitrary
restriction though. Once you support multiple providers on the same
system saying that "foo in gem conflicts with foo in apt" doesn't make
much sense.
> It is not a bug in Package, it is a natural consequence of Puppet's
> architecture. Resource providers cannot (reliably) be distinguishing
> characteristics of any resource type, because for the most part they are not
> assigned or known during catalog compilation.
>
> Consider this:
>
> package { 'foo_native':
> name => 'foo',
> }
>
> package { 'foo_gem':
> name => 'foo',
> provider => 'gem',
> }
>
> Do those declarations refer to the same resource or not? What if the target
> machine is some screwball system for which the default package provider is
> 'gem'?
This makes more sense. I'd just assume the user knows what he's doing
because he has to anyway. Asking for "Package[foo] from whatever
package system the target has" is not a useful thing to do because
there is no standardization of names between package systems. You
already have to know what package system you are targeting to be able
to select the package name. Enforcing the namevar constraint in this
case just hurts the user.
But if you want to keep it pure make this case conflict and only allow
the case where both Package declarations have a provider declared, so
you know the provider at compilation, it's less flexible but much less
of an issue than the current solution.
Cheers,
Pedro
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/CALprHx8bXHLiwWaUq3iSxqYw78OmmxA6FcDdF5O1C8jKo9fFRQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
