cog_env special key for primitive commands about cog HOT 24 CLOSED

Are single and multi only available to primitive commands?

from cog.

No, any command can use single or multi, but only primitive commands are given access to the previous command's results.

from cog.

So, if we limit access to the previous command's results only to primitives, we no longer allow commands such as: ec2:regions | ec2:create --region=$region. Is that expected/acceptable?

from cog.

@lhaskins That would still work. The difference is that primitive commands have access to the entire json object returned by the previous command. Your example would work fine, but you would only have values for $region.

from cog.

Cool. Thanks for the clarification.

from cog.

What happens with single if you have multiple results? If we use @lhaskins example, is $region an array or what?

from cog.

Yes, it's the difference between multiple executions of:
ec2:create --region="us-east-1"; ec2:create --region="us-west-1"
as opposed to a single execution of:
ec2:create --region=["us-east-1", "us-west-1"]

from cog.

@lhaskins @imbriaco What @mpeck and I discussed yesterday was in the case of a single command all variables become arrays containing the relevant bound values. Up for debate on whether or not we should make all parameters arrays -- options and args -- to simplify input processing.

from cog.

I'm not sure I like the idea of always sending the calling environment to all primitive commands. It seems kind of wasteful. Feels like we want a way to differentiate between primitive commands which need the entire env and those that don't.

from cog.

I actually kinda like it being tied into primitive. We don't want commands that aren't primitive to be able to pull in everything do we? So if we add another flag to it, it would be something that you could only ever use with primitive. It's not really a major deal, just might get confusing if we ever have lots of options that only really work in certain combinations.

That said, I'm not adamantly apposed to it. What should we call the flag?

from cog.

If we do go that route, should we reconsider primitive? Change it to something like insecure or something?

from cog.

I meant differentiating between primitive commands like filter which do need the environment and sort which doesn't. {"primitive": true} vs. {"primitive": "with-env"}

from cog.

ah, I see. That makes sense. so we would have things like {"primitive": "with-env"} and {"primitive": "without-env"}?

from cog.

What about {"primitive": "basic"} (no env), {"primitive": "complete"} (with env), {"primitive": "secured"} (needs rules and permissions)?

from cog.

I think primitive implies that the command has no permissions. And personally I think "with-env" and "without-env" is more explicit.

from cog.

Yes, I was thinking that both "basic" and "complete" commands have no permissions, but you need a way to denote commands that do have permissions, thus "secured". This allows primitive commands to have different levels that can mean different things. Either way, a third indicator is needed. I'm cool with "with-env", "without-env", and "secured" if you think that's clearer.

from cog.

I see what you are saying. What do you think of this? Commands can be tagged with primitive: "with-env" or primitive: "without-env". We leave the primitive column in the db as a boolean and add another column, "with-env", as another boolean. If primitive is false then with-env is false. We can add some constraints on the db to enforce that.

from cog.

How about this?

execution: once | multiple*
enforcing: true* | false (indicates primitive command)
calling_convention: bound* | all (only if enforcing == false)

Asterisks indicate defaults.

from cog.

Looks reasonable to me.

from cog.

I like once even better than single.

Each of those should be optional with the following defaults, I think:

execution: multiple
enforcing: true
calling_convention: bound

So you only need to specify them if you're going to do something out of the ordinary.

from cog.

@imbriaco That's what I meant by "Asterisks indicate defaults."

from cog.

Derp.

from cog.

yes, I agree. I think once is definitely clearer. 👍

from cog.

Looks like we've found consensus on the semantics, let's move forward. @mpeck, @lhaskins if you run into anything that we haven't covered that you need input on, ping me or @kevsmith and we'll help sort it out quickly so we can keep moving.

from cog.