Henrik, you 100% nailed everything that I wanted.
In my mind, I was envisioning the system of callbacks that you described as
a stack with pointers (file:line?) portions of the code. When the catalog
pass is complete, refer back to the callback stack(s) and process them down
until empty.
Basically, partial evaluation of all files and then recursive evaluation
until complete.
It seems to me, not having studied the compiler, that this would be more
straightforward to implement due to the way that Puppet uses very clear
resource stanzas that can be atomically parsed.
It does get hairy when you mix the callbacks with the reverse dependencies.
I can see having to iterate over the stack (mesh?) and check for loops and
correctness while doing so. It could certainly turn into quite the
recursive memory hog if not done properly.
However, I really do think that this is needed in the language as it seems
to be a place where people frequently stumble when putting together what
should be a straightforward thought process.
Thanks!
Trevor
On Tue, Jun 17, 2014 at 9:39 PM, Henrik Lindberg <
henrik.lindb...@cloudsmith.com> wrote:
> On 2014-17-06 22:14, Trevor Vaughan wrote:
>
>> Do you like dead threads? like dead threads....
>>
>> Only some of them (like this one)...
>
>
> So, I was looking back over this and there's one thing that we
>> desperately need as a community.
>>
>> We need defined(Class['foo']) and it needs to know about ALL classes in
>> the catalog at compile time, not just the ones that got included before
>> it.
>>
>> By ALL classes I assume you mean all the classes that will have been
> evaluated and included in the catalog at the time the catalog compilation
> is finished?
>
> This would save a TON of heartburn in a lot of cases.
>>
>> For instance, right now, I have to do:
>>
>> # Don't reverse these two!
>> include 'foo'
>> include 'bar'
>>
>> Where bar has something like:
>>
>> if defined(Class['foo']) {
>> do something that happens if bar has foo
>> }
>>
>> In theory, this also rides into unmangling some of the roles/profiles
>> configurations that I've seen posted around where people twist
>> themselves in knots using variables to make sure that their classes are
>> included properly when a simple if defined(Class['foo']) would make all
>> of that disappear.
>>
>> I would like to suggest that this get fixed in the future parser and
>> that it be singled out as something like 'has_class'..
>>
>>
>> if has_class('foo') { stuff }
>>
>> Thoughts?
>>
>
> It is quite difficult to achieve as a general "see if it is defined now"
> since an inclusion can take place in conditional logic, from logic in ruby
> code (using define_resources), classes can be parameterized and
> instantiated with resource creation syntax (which makes them unknown to the
> system until the class / resource type that realizes them is evaluated.
>
> In other words - close to impossible to do this accurately given all the
> ways classes can be added to the catalog during the evaluation. At least as
> a simple lookup of Class['foo'].
>
> I can imagine a mechanism that kicks in towards the end of the compilation
> but that is also complicated - one part of the logic has a rule that if X
> is missing it does Y, and another rule adds X if it is (directly or
> indirectly missing). We can also add callbacks - say when a class is added
> to the catalog - can trigger a code block that is then evaluated. (This is
> harder to trigger for something that is not in the catalog), but maybe this
> could be another set of callbacks, and they keep triggering until nothing
> more is triggered).
> (PROLOG anyone? Constraint solver?)
>
> I can also imagine being made more aware of when things do occur and only
> take action when certain things are known - a sort of orchestration of the
> composition of the catalog. This would enable stating things like "include
> this in the catalog when these conditions hold / when these other things
> are done". This is not much unlike the callbacks / constraints scenario
> above, but in a fashion where it is possible to reason about what is going
> to happen (starving, deadlocking, endless looping). (This is an idea that I
> think is very powerful and that can extend to agents as well)
>
> Maybe we can find some compromise. One area that has been discussed is the
> domain of queries. The do run after the rest of the compilation has been
> made, but they can currently only do certain pre-defined tasks (like
> realizing resources). Maybe a better query and more powerful query
> mechanism is enough. (Again very similar to registered callbacks with
> predicates that trigger at the end - that is basically what the query
> mechanism is now (i.e. the spaceship operators).
>
> I do also think that there are other fundamental compositional mechanisms
> missing - say the ability to extend things in a fashion that the extended
> party is aware of how it is extended (or will be extended because someone
> promised / declared this). Naturally, the reverse is also needed; if module
> X is included and A, B are in the catalog, then X will do something without
> A, and B being aware (a reverse dependency if you like).
>
> Just some thoughts on the topic.
> - henrik
>
>
>> Thanks,
>>
>> Trevor
>>
>>
>> On Thu, Feb 20, 2014 at 4:17 AM, Daniele Sluijters
>> <daniele.sluijt...@gmail.com <mailto:daniele.sluijt...@gmail.com>> wrote:
>>
>> I like a constrains style solution much better myself to, wasn't
>> aware of it at the time.
>>
>> I think with Puppet 4 we could introduce some additional pain,
>> semver wise we'd be
>> allowed to do that. If that helped fix this issue once and for all
>> I'm pretty sure the
>> community would support it too.
>>
>>
>> On Wednesday, 19 February 2014 23:31:24 UTC+1, Markus wrote:
>>
>>
>>
>> > I'm not very fond of the idea of hardwiring special support for
>> > Package resources into Puppet (nor for resources of any other
>> specific
>> > type). I still like my "constraints" idea, to which Felix
>> directed
>> > your attention, but if something like that is ever
>> implemented then
>> > adopting it will require (smallish) modifications to be made
>> to a lot
>> > of manifests.
>>
>> +1 to a constraints style solution. Figuring how to do it without
>> causing a lot of widespread minor pain would be an added plus. :)
>>
>>
>>
>>
>> --
>> 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
>> <mailto:puppet-dev%2bunsubscr...@googlegroups.com>.
>>
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/puppet-dev/d680773d-
>> 57bb-49e5-9875-f543ace773b0%40googlegroups.com.
>>
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>>
>> --
>> Trevor Vaughan
>> Vice President, Onyx Point, Inc
>> (410) 541-6699
>> tvaug...@onyxpoint.com <mailto:tvaug...@onyxpoint.com>
>>
>>
>> -- This account not approved for unencrypted proprietary information --
>>
>> --
>> 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
>> <mailto:puppet-dev+unsubscr...@googlegroups.com>.
>>
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/puppet-dev/CANs%
>> 2BFoV3th5f-uHM7wqL6LOPoJf-%2BxWUhB%2BJAAhh7Tua2rA8Pw%40mail.gmail.com
>> <https://groups.google.com/d/msgid/puppet-dev/CANs%
>> 2BFoV3th5f-uHM7wqL6LOPoJf-%2BxWUhB%2BJAAhh7Tua2rA8Pw%
>> 40mail.gmail.com?utm_medium=email&utm_source=footer>.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> --
>
> Visit my Blog "Puppet on the Edge"
> http://puppet-on-the-edge.blogspot.se/
>
>
> --
> 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/lnqqkl%245ai%241%40ger.gmane.org.
> For more options, visit https://groups.google.com/d/optout.
>
--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699
tvaug...@onyxpoint.com
-- This account not approved for unencrypted proprietary information --
--
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/CANs%2BFoW%2BhSNAoCoyP8Tx9Bc8V4nsS75WRnLHAHpykLSqeL9_Tw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
