I’m trying to build a Python package that will unconditionally build a “core” set of CFFI libraries, but then have some other libraries that will not be built in unless the user opts in with an “extras” flag.
I do not need to pull in any other Pip dependencies or external tarballs based on that flag; I only need to select at build-time / bdist-time whether or not to pass some clib specifications to setuptools.
Some of the algorithms that suite includes (McEliece, Dilithium, and SPHINCS+) are simply libre and should be included stock with every installation.
One of the algorithms — the only NIST-standardized KEM, Kyber, which is currently being rolled out in every major web browser — is released under a rather awkward and constraining set of licenses that the public technically hasn’t been allowed to see in full yet.
And some of the algorithms (Falcon, HQC) are only yet allowed for use in security and fitness evaluation research.
All of them have some audience, if only researchers, and it’s likely that they will all get “rolled up into” the libre baseline eventually.
…but I cannot figure out how the “extras” flag is exposed programmatically.
Is it even possible to tell the difference at build-time between
pip install pypqc-cffi-bindings
and
pip install "pypqc-cffi-bindings[kyber,falcon]"
or will I have to give up on that?
If so, is splitting the bindings library up into separate distribution packages (e.g. pypqc-cffi-bindings-librepypqc-cffi-bindings-kyberpypqc-cffi-bindings-falconpypqc-cffi-bindings-hqc) the only option, or are there other ways to tackle this I haven’t considered?
when we wanted to run a different PID loop in an embedded application or select between different sets of configuration settings for testing purposes, we would use C preprocessor conditionals that we could either set or clear just prior to programming to select between the different options. For example, if the flag was set in a conditional, option A would be enabled, else, option B would, etc. Can you implement / mix C preprocessor directives here? Here is a potential link. I haven’t done this myself with Python but wondering if this is something that would be of interest to you for this particular application.
Here is a potential link that may be of use:
C preprocessor conditionals are ideal in C … maybe for Python as well.
It doesn’t matter much to me whether it’s implemented with an if clause in setup.py, or with a preprocessor macro; what I’m wondering is how I can determine what “extras” have been set in the first place, so that I could start effecting changes to the build based on that.
I am not sure it is possible. Well, everything is possible if you try hard enough, I guess. But I do not think there are any primitives available to do this easily. Anyway… I am quite sure that which extras are selected should have strictly no influence on the builds. Extras are only meant for the installer (or more precisely the dependency resolver). Basically when we consider extras we can completely ignore builds (source distributions, source trees, etc.) and reason only with already built artifacts, i.e. the wheels.
