The warning only appears if you run `python setup.py test` (or equivalent), but the breakage occurs regardless of whether you were actually running this; if you depend on a package that doesn’t have a pre-built wheel, and the package attempts to import the removed module in its `setup.py`, then your build will break.
code as config is amazing. well can be, easily, it needs to be descriptive and composable. meaning it needs to be able to return data according to some schema.
the point is, that the problem again is the lack of a clear boundary between the gathering, assembling, ordering, calculating and validating the steps required to prepare/build/install/load/use/and-so-on and the actual execution of those steps.
Terraform, for example, has a plan and run phase.
And in general the fear of too many layers (and in-situ DSLs) leads to very brittle and extremely inconvenient "interfaces" (ie. GitHub and Ansible programming in YAML comes to mind)
...
Ideally build/packaging/setup steps themselves were written in a way that their reinterpretation[0] is easily possible. (So we don't need to litter the implementation with explicit hook points, etc.)
from time to time config is just not willing to sit there in a list. it needs to be computed.
just an example from a few days ago. someone needs to pull data from some remote service (maybe Vault), or generation of keys/entropy/etc. [0][1]
of course this just means folks should wrap the whole thing in a program. but that's getting inefficient fast if every layer only accepts "env vars" or a plain JSON file.
