-
Notifications
You must be signed in to change notification settings - Fork 220
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: feature gates #5287
feat: feature gates #5287
Conversation
564914a
to
0b843e7
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good. Some minor readability and maintenance suggestions
|
||
pub use feature::Feature; | ||
pub use status::Status; | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some docs here on when / how / why to maintain this list would be highly useful.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good
The only thing I would add is a default network, so if the user does not select a network, it will default to mainnet, or perhaps development as building from dev that's the most likely? But this is open to discussion
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need to update the readme with all this as well.
Description --- This PR is for reflective purposes regarding feature gating at compile time. See tari-project#5135 for more info. This PR as it stands is to be used as an example of a network _type_ based feature gate at compile time. It allows setting an ENVVAR for the network with conditional compilation for features. The feature sets can be imported across any crate in the project easily and then used with the `#[cfg(tari_feature_...)]` attribute macro. I played with a few styles of gating code. In the case of burning, and validator registration what I found was it became easier to focus on the entry and exit points of the code. These functions don't have much outside effect other than their distinct purpose so preventing someone from calling them is good enough conditional compilation. It's easier than trying to remove every aspect of their existence throughout. This wouldn't always be the case though- with a feature that changes an existing feature the style of code writing has the potential to change heavily with possible duplication of entire enums or structs. It could be useful to have more examples to help guide people with, but also is something we'll probably see patterns for emerge naturally. The nice part is we have the flexibility to support different needs. There was a desire to use the network based feature gating to prevent a "mainnet" compiled bin from compiling with testnet configuration at all. To remove conensus constants, or even the knowledge of the testnets. This proved more difficult with the current code base and would require a lot of refactoring. I've made another PR with a branch I consider broken demonstrating the minimal amount of changes needed to perform this kind of task and it doesn't seem to bring us a major benefit for the time being. --------- Co-authored-by: Cayle Sharrock <[email protected]>
Co-authored-by: Cayle Sharrock <[email protected]>
a3a238f
to
926706c
Compare
Ack |
## [0.50.0-pre.0](v0.49.0-pre.6...v0.50.0-pre.0) (2023-04-12) ### ⚠ BREAKING CHANGES * add paging to utxo stream request (5302) ### Features * add extended mask recovery ([5301](#5301)) ([23d882e](23d882e)) * add network name to data path and --network flag to the miners ([5291](#5291)) ([1f04beb](1f04beb)) * add other code template types ([5242](#5242)) ([93e5e85](93e5e85)) * add paging to utxo stream request ([5302](#5302)) ([3540309](3540309)) * add wallet daemon config ([5311](#5311)) ([30419cf](30419cf)) * define different network defaults for bins ([5307](#5307)) ([2f5d498](2f5d498)) * feature gates ([5287](#5287)) ([72c19dc](72c19dc)) * fix rpc transaction conversion ([5304](#5304)) ([344040a](344040a))
Description
This PR is for reflective purposes regarding feature gating at compile time. See #5135 for more info. This PR as it stands is to be used as an example of a network type based feature gate at compile time.
It allows setting an ENVVAR for the network with conditional compilation for features. The feature sets can be imported across any crate in the project easily and then used with the
#[cfg(tari_feature_...)]
attribute macro.I've also introduced a secondary commit for binaries to perform a quick network check against itself to ensure the intended network is supported by the binary. This check is made non-invasive (not conditionally compiling possible network) as that method of check ends up being much more tedious.
Motivation and Context
We want some features on some networks, but maybe not all.
How Has This Been Tested?
Manually
What process can a PR reviewer use to test or verify this change?
Compile a binary with a set network
TARI_NETWORK=nextnet cargo build --release --bin tari_base_node
then run the binary with a test network as a parameter:
./tari_base_node --network esme
and receive an error:
Please note
That running the binary will cause the build to default to the test network always. Meaning this will not work:
The second command
cargo run
will re-build the binary, and without theTARI_NETWORK
env set the binary will default to a test binary.In development if you want to call run and connect to a non test network you need to also pass the TARI_NETWORK envvar instead of the
--network
flag.TARI_NETWORK=nextnet cargo run --bin tari_base_node --release -- --network nextnet
Breaking Changes