Forum: CFEngine Help
Subject: Re: conditional setting of a variable
Author: davidlee
Link to topic: https://cfengine.com/forum/read.php?3,23180,23206#msg-23206
Many thanks for looking at this.
BTW, whenever I send requests like this, I try to do so from two different
viewpoints:
(1) as a user: my immediate issue, as a user;
(2) as if I were a developer of the software itself: are there any general
opportunities for improvement.
I hope have done that in this request. (See also the bug reports I have
submitted in recent months.)
At present, the entirety of my cfengine3 work is using 3.1.4 in its distributed
RPM form. We're working flat out to be using this product for real (and making
good progress), so I haven't, at present, got the environment (including time!)
to start an installation driven by source-code. That said, when 3.2.0 becomes
available as an RPM for RHEL, I would be happy to give that a go. (And later,
when the local dust settles in a few months, I would hope to be able to do some
"check-out from source" work.)
For my immediate issue, simply knowing that my 3.1.4 observation (and its
seeming strangeness) is indeed reproducible, and similarly that the 3.2.0
observation (which appears to be better) is also reproducible. I can live with
that and work around it.
>From a developer-theoretic angle, merely knowing that 3.2.0 is both expected
>and reproducible is probably OK.
BUT... also from a developer-theoretic angle, please re-read the opening of my
initial query, which was user-focussed on what we're trying to achieve:
============
class:
"runtime_condition" and => { ...foo ; bar ... };
vars:
v string => "always1";
v string => "always2";
v string => "sometimes1"
ifvarclass => "runtime_condition";
============
and seems reasonably obvious. Contrast that with Mark's proposal.
I dare(!) to suggest that mine is considerably clearer to the end-user.
Promises are all well and good. But we mere mortals ALSO have to understand
them. If we cannot understand them, they are greatly devalued and, worse, much
more likely to be potentially flawed.
This doesn't have to be seen as an either/or; I'm suggesting a "both/and"
model, with my suggestion providing clarity, and Mark's providing the
quasi-assembler-language fine-detail control for those who really need it.
So, for the future, I would ask that consideration be given to something like
my suggestion, because of its relative clarity.
_______________________________________________
Help-cfengine mailing list
Help-cfengine@cfengine.org
https://cfengine.org/mailman/listinfo/help-cfengine
