Currently, if you want to feature-gate items to add to a submodule, you can't use create_init_submodule. Arguably, it's confusing to have feature-gated items in a Python extension module, but regardless, it's something we see in the wild (e.g., in qcs-sdk-rust, some items are gated behind a libquil feature).
The work-around at the moment is to use multiple create_init_submodule blocks with appropriate cfg(not(feature = "...")) and cfg(feature = "...") attributes, but that's not great, and it's especially problematic if there are multiple features at play, since it requires an exponential number of blocks.
We don't necessarily need to support cfg attributes within the macro, but alternatively, we could have an "extension point" to specify an ordinary function to call during the module initialization process. Within it, we could just write out the gated items "the hard way".
Currently, if you want to feature-gate items to add to a submodule, you can't use
create_init_submodule. Arguably, it's confusing to have feature-gated items in a Python extension module, but regardless, it's something we see in the wild (e.g., inqcs-sdk-rust, some items are gated behind alibquilfeature).The work-around at the moment is to use multiple
create_init_submoduleblocks with appropriatecfg(not(feature = "..."))andcfg(feature = "...")attributes, but that's not great, and it's especially problematic if there are multiple features at play, since it requires an exponential number of blocks.We don't necessarily need to support
cfgattributes within the macro, but alternatively, we could have an "extension point" to specify an ordinary function to call during the module initialization process. Within it, we could just write out the gated items "the hard way".