--
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+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/naga6d%245r3%241%40ger.gmane.org.
For more options, visit https://groups.google.com/d/optout.
Would it be possible in this scheme to mark strict mode per class? I could mark my own code as being strict and therefore get compile time failures when I make a typo myself, but wouldn't have to enforce that on all third party code.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CAHTHiAE8pFAA-O0Zf6d_MJrgiyxqw72s_YcXizHAe%3Di9-2vBzg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
--
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+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/56CD0F8D.1010201%40puppetlabs.com.
I'm also a fan of per module which can override a global setting.If it could be part of the metadata.json, that would be ideal and would allow for attestation on the Forge if appropriate.
--
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+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/2a0bec94-ff66-4e0f-9930-a76a193a5f88%40googlegroups.com.
Statically we could possibly check if the outcome is statically known
or if there is a potential problem (i.e. where evaluation can lead to "empty thing in the middle"). But I am not sure what the quality of that would be and how expensive it would be to implement.
There are number of such cases where puppet is trying to be helpful and ends up with a messy situation that it silently ignores or goofs up on.
- henrik
--
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+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/56CE8764.2000703%40puppetlabs.com.
--
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+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/56CF12F3.2010808%40puppetlabs.com.
If you have a construct like this in your manifests:
Notify['left'] -> $stuff -> Notify['right']
I am following up with a runtime type strictness thing.
If you have a construct like this in your manifests:
Notify['left'] -> $stuff -> Notify['right']
Thansk for asking! For me, I would prefer the ordering to follow left -> right, and not error or warn.
If I have expressed Notify['left'] -> $stuff -> Notify['right'] then the ordering of left then right should be possible in all circumstances. Whether it is required or not when $stuff is empty is another matter, but it doesn't impact the user if all resources succeed.Technologically, the references could be explicit references or collectors, and collectors can produce zero references, and this is actually DESIRED by me, as recently as yesterday. My use case was chaining lots of collections of optional defined types Like `A <||> -> B <||> -> C <||> D <||>` where B/C/D are optional, but A must always come before B/C/D and D must always come after A/B/C. In minimal cases, only A and D may be declared, so I ended up doing A <||> -> D <||> ; A <||> -> B <||> -> D <||> ; A <||> -> C <||> -> D <||> which is overly verbose.
Hmm.....I think, as long as it is documented, then whatever behavior is deterministic is fine.'I think that there is value in the following resolutions:Notify['left'] -> [] -> Notify['right']* Noop since there is nothing in []Notify['left'] -> [] -> Notify['right']Notify['left'] -> Notify['right']* First == Noop* Second == Expected ordering
Notify['left'] -> $stuff -> Notify['right']
Notify['left'] -> Stuff<||> -> Notify['right']
Notify['left'] -> $stuff
$stuff -> Notify['right']
a = 0
b = 1
c = 2
print "oops" if a < b < c # NoMethodError
#include <stdio.h>
int main() {
int a = 0, b = 1, c = 2;
if (a < b < c) puts("ok");
return 0;
}
Notify['left'] -> Undef -> <Whatever>* Error since Undef is in the relationship
--
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+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/56CF80DD.7010200%40puppetlabs.com.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/56CF8A4D.3070004%40puppetlabs.com.
Sorry about that.What I mean is this:A -> [] -> B is not equivalent to A -> B since failures in A will not affect B.However, it would be equivalent to [A,B] which I am reading as A before B but not in an actual resource relationship.
On Thursday, February 25, 2016 at 7:45:46 PM UTC-6, Trevor Vaughan wrote:Sorry about that.What I mean is this:A -> [] -> B is not equivalent to A -> B since failures in A will not affect B.However, it would be equivalent to [A,B] which I am reading as A before B but not in an actual resource relationship.
On Thursday, February 25, 2016 at 7:45:46 PM UTC-6, Trevor Vaughan wrote:Sorry about that.What I mean is this:A -> [] -> B is not equivalent to A -> B since failures in A will not affect B.However, it would be equivalent to [A,B] which I am reading as A before B but not in an actual resource relationship.Just to be a little more clear, when declaring resources I never use a KNOWN empty-in-all-cases array in resource chains, so using "[]" is a leaky analogy.
Instead one example is:Thing[a] -> Thing <| name == $::something::i::want |> -> Thing[b]Some people assume that the Thing[$::something::i::want] is declared and if not then that is an error state.
Some people assume that the Thing[$::something::i::want] may be declared, but if not then that's fine.
But for all cases Thing[a] -> Thing[b] at most is desired, or at least is possible. The only case in which disjointed dependencies are logically different is when failures in Thing[a] do not skip the evaluation of Thing[b] if and only if Thing[$::something::i::want] is undefined.
Does that occur in the real world? Not afaik.
-----
The other example that comes to mind is:Thing[a] -> $might_contain_references -> Thing[b]This differs from above as variables are parse-order dependent and collectors are not (right?), and variables may be undefined or undef and collectors are... neither of those things (instead the graph is updated directly when collectors return resources, I believe).A thought on semantic differencs from collectors: the value of a variable is directly obveservable at evaluation time, and dependency chains can be created based on this evaluation. Therefore I would posit that undef or undefined variables in dependency chains are always an error state, whereas empty collectors may or may not be.