Having faced the issue described in #1355, I was reading through the codebase to identify the source of the invalid flag read. While the read causing this specific issue seems to be here, the pattern of flag usage here as well as in the config module confuses me a little.
While every config option has an associated ABSL flag, my understanding is that, as per standard usage, flags need to be parsed in order to be accessed within the application (using absl.flags.FLAGS(argv)). The workaround mentioned in the above issue (using absl.flags.FLAGS.mark_as_parsed()) appears to be a workaround that does not align with standard flag usage.
Further, I noticed two other anomalies -
- I noticed that certain flags are manually "set" as defined during application runtime, which appears as another workaround for similar issues (ex: here)
- None of the config options appear to be set when using
grain.config.update(<option>, <value>), again because the underlying flag is not set unless the flags are parsed
Question: Is there some documentation on how these options are meant to be used with Grain? Are library users expected to parse the flags at the point of usage, and is there a reason for this design? Let me know if I am misunderstanding the control flow here. Thanks!
Having faced the issue described in #1355, I was reading through the codebase to identify the source of the invalid flag read. While the read causing this specific issue seems to be here, the pattern of flag usage here as well as in the config module confuses me a little.
While every config option has an associated ABSL flag, my understanding is that, as per standard usage, flags need to be parsed in order to be accessed within the application (using
absl.flags.FLAGS(argv)). The workaround mentioned in the above issue (usingabsl.flags.FLAGS.mark_as_parsed()) appears to be a workaround that does not align with standard flag usage.Further, I noticed two other anomalies -
grain.config.update(<option>, <value>), again because the underlying flag is not set unless the flags are parsedQuestion: Is there some documentation on how these options are meant to be used with Grain? Are library users expected to parse the flags at the point of usage, and is there a reason for this design? Let me know if I am misunderstanding the control flow here. Thanks!