The variable injection in packaging time

This idea is for the non-package module to get their own packaging variable (e.g. the time in packaging).

For package modules, it is easy: just generating “__variable__.py” in packaging and:

from .__variable__ import PACKAGING_TIME
from .__variable__ import variable # the other variables

For extension modules, it is also easy:

#ifndef PACKAGING_TIME
#define PACKAGING_TIME ""
#endif

// other code
static const char* time = PACKAGING_TIME;
// or use compile time
static const char* compile_time = __DATE__ " " __TIME__;

and then add -DPACKAGING_TIME.

However, these two way cannot be used for non-package modules. If add the variable to environment variable, it may conflict between many modules if the variable name is same. If the variables are just for random and don’t want the project structure be complex, maybe the variable is needed to inject to the code in packaging time.

Here is the imagine: use ? before the variable name to mark that it is needed to be injected, and finally use the packaging tool to inject the string variable in the code:
For example:

?PACKAGING_TIME

will be replaced to:

PACKAGING_TIME = "2026-5-4 18:39:20"

The values can be decided in command or the packaging code.

What’s the use case for this? It seems like a lot of complexity for something that I’ve never seen a request for in all my years working on packaging. And making it a language feature in particular would need a lot more justification if it’s to have any chance of getting accepted

3 Likes

Are you looking for something reproducible build related, like SOURCE_DATE_EPOCH? (SOURCE_DATE_EPOCH — reproducible-builds.org)

Those kinds of values are typically provided as environment variables, or via a use case specific configuration mechanism (such as CLI options)