joerdav/xc

Require environment variables to be set

a-h opened this issue · 6 comments

a-h commented

In C projects (and others), it's common practice to require an environment variable to be set to inject things like WIFI SSIDs.

https://gitlab.com/slimhazard/picow-http-example

$ cmake -DPICO_BOARD=pico_w -DWIFI_SSID=my_wifi -DWIFI_PASSWORD=wifi_pass \
        -DHOSTNAME=picow-sample -DPICO_MBEDTLS_PATH=${PWD}/../lib/mbedtls ..

It would be awesome if XC could require that an environment variable is set from outside, or could pick up a file that could be .gitignored to load that.

joerdav commented

This would be useful, how do you think the syntax of this could look? A new Attribute, or modify the syntax of the Environment Attribute?

joerdav commented

Required env vars

The current syntax for environment variables is:

## Tasks
### Task1
Env: ENVIRONMENT=PRODUCTION, VERSION=1.2
```
echo $ENVIRONMENT
echo $VERSION
```

If we were to expand those attributes the syntax could be:

Env: ENVIRONMENT=PRODUCTION, SOME_PARAMETER

Or

Env: ENVIRONMENT=PRODUCTION, !SOME_PARAMETER

Alternatively it could be a new attribute:

Env: ENVIRONMENT=PRODUCTION, VERSION=1.2
Parameters: SOME_PARAMETER
joerdav commented

Arguments

Another concept I've previously thought about is arguments:

## Tasks
### Task1
Env: ENVIRONMENT=PRODUCTION, VERSION=1.2
Args: SOME_PARAMETER
```
echo $ENVIRONMENT
echo $VERSION
echo $SOME_PARAMETER
```

The following would be the behaviour:

$ xc Task1 "hello world"
PRODUCTION
1.2
hello world

And:

$ xc Task1
Missing argument SOME_PARAMETER.
Usage: xc Task1 <SOME_PARAMETER>

And you could have multiple:

## Tasks
### Task1
Env: ENVIRONMENT=PRODUCTION, VERSION=1.2
Args: SOME_PARAMETER, ANOTHER_PARAMETER
```
echo $ENVIRONMENT
echo $VERSION
echo $SOME_PARAMETER
echo $ANOTHER_PARAMETER
```

The following would be the behaviour:

$ xc Task1 "hello world" "goodbye"
PRODUCTION
1.2
hello world
goodbye
a-h commented

I like that! That's exactly what I was thinking.

I don't think there's a need to add positional handling of args though, since you can set env variables on the fly for the process. I don't like positional args, since if you change the order, it messes things up.

This works without having to parse the extra args in the CLI:

SOME_PARAMETER="hello world" ANOTHER_PARAMETER="goodbye" xc Task1

In terms of documentation, then the Env: configuration in xc is used to set environment variables to specific values, while the Args: configuration is used to ensure that specific environment variables are present (even if they're an empty value?).

Args is probably not the most understandable name though.

joerdav commented

Yeah I'm torn between adding a new attribute, or modifying the Env: attribute:

Env: DAY=MONDAY, TIME

Could mean:
DAY is set to MONDAY
And TIME is required as an input.

I want it to be as human readable as possible though so maybe a new attribute called Parameter/Param