right way to use body classes on class promise

13 views
Skip to first unread message

Martin Gehrke

unread,
Sep 1, 2015, 9:32:32 AM9/1/15
to help-c...@googlegroups.com

classes:

    "sometimes" expression => "any",

        classes => always("always_defined");

 

doesn’t work as you can’t use classes => on a class promise.

 

What is the right way to do something like this?

 

If this looks contrived here is a more real world example

 

“has_file” expression => isplain(“/path/to/some/file”),

classes => always(“checked_has_file”);

 

thoughts? thanks

Nick Anderson

unread,
Sep 1, 2015, 9:46:31 AM9/1/15
to Martin Gehrke, help-c...@googlegroups.com
On 09/01/2015 08:32 AM, Martin Gehrke wrote:
> If this looks contrived here is a more real world example
>
> "has_file" expression => isplain("/path/to/some/file"),
> classes => always("checked_has_file");
>
> thoughts? thanks

You could do:

"have_plain_file" expression => isplain("/path/to/some/file");
"not_have_file" not => fileexists("/path/to/some/file");
# You could also check to see if it is or isnt a directory if necessary
as well as any other checks
"checked_for_file" or { "have_plain_file", "not_have_file" };

It's kind of weird. Can you open an issue for not being able to use
classes bodies on classes promises. I don't see any reason why that
should be specifically disallowed. Plus there is no error message so I
would expect it to work.

Neil Watson

unread,
Sep 1, 2015, 9:48:54 AM9/1/15
to help-c...@googlegroups.com
On Tue, Sep 01, 2015 at 01:32:29PM +0000, Martin Gehrke wrote:
>
> classes:
> "sometimes" expression => "any",
> classes => always("always_defined");

I do not think that classes, or vars promises create result classes. I
can't think of a way to define a class if a vars or classes promise has
been attempted. What's your end goal?

--
Neil H Watson
Sr. Partner, Architecture and Infrastructure
CFEngine reporting: https://github.com/evolvethinking/delta_reporting
CFEngine policy: https://github.com/evolvethinking/evolve_cfengine_freelib
CFEngine and vim: https://github.com/neilhwatson/vim_cf3
CFEngine support: http://evolvethinking.com

Neil Watson

unread,
Sep 1, 2015, 9:56:08 AM9/1/15
to help-c...@googlegroups.com
On Tue, Sep 01, 2015 at 08:46:29AM -0500, Nick Anderson wrote:
>"have_plain_file" expression => isplain("/path/to/some/file");
>"not_have_file" not => fileexists("/path/to/some/file");

Good idea. This brings up an important point. Not_have_file:: is not the
same as !have_plain_file::. The former is it explicit that said file
does not exist while the latter means that the file may not exist or
that the check may not have run. Using ! has cost me debugging time
before.

Nick Anderson

unread,
Sep 1, 2015, 9:57:26 AM9/1/15
to help-c...@googlegroups.com
On 09/01/2015 08:56 AM, Neil Watson wrote:
>
> Good idea. This brings up an important point. Not_have_file:: is not the
> same as !have_plain_file::. The former is it explicit that said file
> does not exist while the latter means that the file may not exist or
> that the check may not have run. Using ! has cost me debugging time
> before.

Negative knowledge is pesky.

Nick Anderson

unread,
Sep 1, 2015, 10:13:42 AM9/1/15
to Neil Watson, help-c...@googlegroups.com
I went ahead and created the ticket
https://dev.cfengine.com/issues/7537

Acceptance Test: https://github.com/cfengine/core/pull/2311

On 09/01/2015 08:56 AM, Neil Watson wrote:

Aleksey Tsalolikhin

unread,
Sep 1, 2015, 10:19:52 AM9/1/15
to Neil Watson, help-cfengine
On Sep 1, 2015 6:56 AM, "Neil Watson" <cfen...@watson-wilson.ca> wrote:

Good idea. This brings up an important point. Not_have_file:: is not the
same as !have_plain_file::. The former is it explicit that said file
does not exist while the latter means that the file may not exist or
that the check may not have run. Using ! has cost me debugging time
before.

Same!  Thanks for point that out, Neil.

Aleksey

Ted Zlatanov

unread,
Sep 8, 2015, 1:18:27 PM9/8/15
to help-c...@googlegroups.com
On Tue, 1 Sep 2015 08:57:23 -0500 Nick Anderson <nick.a...@cfengine.com> wrote:

NA> Negative knowledge is pesky.

No it's not.

Ted

Reply all
Reply to author
Forward
0 new messages