How to check that system environment variables are set with SCons?

[abitrolly]

When porting shell scripts to SCons, what is the best strategy to replace this validate.sh script that checks for build configuration in environment variables?

#!/usr/bin/env bash

set -e

echo "GITLAB_DOCS_REPO: ${GITLAB_DOCS_REPO}"
echo "GITLAB_DOCS_REPO_REF: ${GITLAB_DOCS_REPO_REF}"
echo "GITLAB_DOCS_CLONE_DIR: ${GITLAB_DOCS_CLONE_DIR}"
echo "GITLAB_DOCS_JSONL_EXPORT_PATH: ${GITLAB_DOCS_JSONL_EXPORT_PATH}"
echo "GCP_PROJECT_NAME: ${GCP_PROJECT_NAME}"
echo "SEARCH_APP_NAME: ${SEARCH_APP_NAME}"
echo

if [ -z "$GITLAB_DOCS_REPO" ]; then
    echo "GITLAB_DOCS_REPO is empty!"
    exit 1
fi

if [ -z "$GITLAB_DOCS_REPO_REF" ]; then
    echo "GITLAB_DOCS_REPO_REF is empty!"
    exit 1
fi

if [ -z "$GITLAB_DOCS_CLONE_DIR" ]; then
    echo "GITLAB_DOCS_CLONE_DIR is empty!"
    exit 1
fi

[mwichmann]

The external (calling) environment is in Python's os.environ. So something like this could reproduce a test:

repo = os.environ.get("GITLAB_DOCS_REPO")
if repo is None:
    print("GITLAB_DOCS_REPO is empty!")
    Exit(1)

There's a bit more to it, potentially. When SCons executes a command, it uses a restricted environment which does not include environment variables from the calling environment (that's a very specific policy decision), so if these variables you are checking for are needed in that context, you need to set them there. That would usually look like env["ENV"]["GITLAB_DOCS_REPO"] = repo.

(sorry, some sloppy editing, I've updated this)

[abitrolly]

This is no different from raw Python.

I thought maybe there are helpers to provide a nice formatted output on such checks.

[bdbaddog]

There's an FAQ about shell environment variables propagation..
https://scons.org/faq.html#Why_doesn.27t_SCons_find_my_compiler.2BAC8-linker.2BAC8-etc..3F_I_can_execute_it_just_fine_from_the_command_line.

[abitrolly]

If not environment variables, what is the idiomatic way to control SCons builds, set paths etc.? From CI/CD, for example.

[mwichmann]

There's an SCons-y way to check other aspects of the build host, which you can read about at https://scons.org/doc/4.7.0/HTML/scons-user.html#chap-sconf

SCons doesn´t believe in controlling the build via environment variables, so has nothing special for them.

There are three main ways to pass information ¨from outside¨: command-line arguments, command-line variables, and targets. Theirs some chatter about that topic at https://scons.org/doc/4.7.0/HTML/scons-user.html#chap-command-line. The variables (FOO=BAR style) can be direct conversions of environment vars, and you can set up some nice tooling to handle them (see https://scons.org/doc/4.7.0/HTML/scons-user.html#sect-command-line-variables)

There's more (but more terse) info in the manpage.

You can set up a site_init.py script to run on SCons startup by putting it in the site_scons directory, that's used by a number of projects as a clean way to import information without littering your SConstruct/SConscript with that stuff.

The scons model in general is that things that control the build are stored in "Construction Variables". Using Variables lets you conveniently transfer from scons inputs to construction variables so your build can use them.

Does that help?

[bdbaddog]

Regardless of checking if the shell which invoked SCons has those environment variables set, you'll have to explicitly propagate them to the execution environment (see FAQ link above).

You could use a configure context with a custom checker to check if they are defined and then propagate them to the execution environment.

[mwichmann]

There's a funky example of pulling in an env var and propagating it here:

https://github.com/SCons/scons/blob/master/packaging/etc/reproducible_site_init.py

not sure if that's best practice, necessarily, but someone contributed that for a specific purpose.