Is it that simple?
Brice Figureau
I was looking to #1907, and so had a look to the catalog, graph and
other part of the puppet code, which are still dark areas to me.
Now, I'm not sure I finally understood how the resource relationships
works, but anyway I said to myself, maybe that's as simple as adding and
edge between two resources.
Could it be as simple as the following mangled patch defining a new
function called require (which is an include + require)?
diff --git a/lib/puppet/parser/functions/require.rb
b/lib/puppet/parser/functions/require.rb
new file mode 100644
index 0000000..769511b
--- /dev/null
+++ b/lib/puppet/parser/functions/require.rb
@@ -0,0 +1,10 @@
+# Include the specified classes
+Puppet::Parser::Functions::newfunction(:require, :doc => "Evaluate one
or more classes, adding an auto require on them"
) do |vals|
+ send(:function_include, vals)
+ vals = [vals] unless vals.is_a?(Array)
+
+ # add a relation from ourselves to each required klass
+ vals.each do |klass|
+ compiler.catalog.add_edge(resource, findresource(klass))
+ end
+end
I suspect that's more complex than my naive approach. On the other hand
I couldn't really write a manifest that needs that feature, so go figure :-)
--
Brice Figureau
Days of Wonder
http://www.daysofwonder.com
Luke Kanies
Nope, you've hit the nail on the head.
And, really, we should just deprecate 'include', or add this
functionality to 'require' - probably deprecate rather than modify.
I *love* that you think this stuff is easy, btw - I agree, but you're
the only other one I can convince to join me. :)
--
Life isn't fair. It's just fairer than death, that's all.
-- William Goldman
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com
Brice Figureau
Not sure I'm following you.
The above patch doesn't deprecate include, it just adds the 'require'
function.
Are you suggesting we throw away include, and implement it only as
require?
Or do you mean we put the feature in the include function, and not a
require function?
Anyway, when I'll know what you want me to do, I'll send a proper patch
with unit tests of course.
> I *love* that you think this stuff is easy, btw - I agree, but you're
> the only other one I can convince to join me. :)
Yes, I find Puppet code well architectured and easy to understand. The
part that are the most difficult to get are obviously the the
indirector/REST, and the internal RAL DSL, which is a bit unusual for
someone like me who have a more standard OO background. But I'm used to
dig into pile of unknown code (doing this daily for 15 years really
helps) :-)
--
Brice Figureau
My Blog: http://www.masterzen.fr/
Luke Kanies
What I basically mean is, would anyone ever use 'include' once
'require' exists?
I can't think of a case where you'd want to evaluate a class but not
indicate that the evaluating class depends on the evaluated class. If
that's the case, it makes sense to provide this new 'require' function
and deprecate the existing 'include' (rather than change the behaviour
of 'include').
>
> Anyway, when I'll know what you want me to do, I'll send a proper
> patch
> with unit tests of course.
>
>> I *love* that you think this stuff is easy, btw - I agree, but you're
>> the only other one I can convince to join me. :)
>
> Yes, I find Puppet code well architectured and easy to understand. The
> part that are the most difficult to get are obviously the the
> indirector/REST, and the internal RAL DSL, which is a bit unusual for
> someone like me who have a more standard OO background. But I'm used
> to
> dig into pile of unknown code (doing this daily for 15 years really
> helps) :-)
I expect both of those to get better - the indirector is starting to
mature, and thus get easier, and the RAL, I think, will get heavily
affected by the coming work to support a pure-ruby DSL.
--
It is better to sleep on things beforehand than lie awake about them
afterward. -- Baltasar Gracian
Peter Meier
> What I basically mean is, would anyone ever use 'include' once
> 'require' exists?
>
> I can't think of a case where you'd want to evaluate a class but not
> indicate that the evaluating class depends on the evaluated class. If
> that's the case, it makes sense to provide this new 'require' function
> and deprecate the existing 'include' (rather than change the behaviour
> of 'include').
I just can speak for myself, but I use include a lot and as far as I
understood your discussion the change would cut my use case of include.
So for example I have a class apache which describes the package and
the service. Besides that I have a define vhost, which describes a
certain vhost and which might be used various time per node.
In the define I include the class apache, to be sure that I have the
necessary things around so my vhost can be sourced. However I don't
want to have everything already evaluated, as I simply require the
package for the vhost-file (so the necessary paths like /etc/httpd/ is
created due to the package install) but I'd like to notify the service
as a vhost have been changed.
So I'm somehow weaving my vhost-definition into the dependency chain
of my apache class.
As far as I understood your bugreport and your emails this wouldn't
work anymore as it would lead to a dependency cycle, not?
However I might be wrong and so simply didn't understand everything.
cheers pete
Luke Kanies
(Replying again to the list; apparently I replied to a direct mail
rather than the list mail, which meant there was no reply-to set.)
Nope, you're entirely right, that would be a dependency cycle, so
consider my deprecation proposal dead.
'require' becomes a superset of 'include', then.
Thanks for catching this before we got any further.
--
If two men agree on everything, you may be sure that one of them is
doing the thinking. -- Lyndon B. Johnson