This approach looks good to me, and tames the somewhat ad-hoc approach
we've had so far.
On Wed, Jan 29, 2025 at 9:14 AM Kenneth Knowles wrote:
> Looks good to me.
>
> I've been told in the past that it is more "pythonic" to have one large
> module with codepaths that are always there but don't
Looks good to me.
I've been told in the past that it is more "pythonic" to have one large
module with codepaths that are always there but don't work unless you
installed with extras, versus having multiple modules that are fully
functional without extras. Is that still the prevailing view for Beam
This is your daily summary of Beam's current high priority issues that may need
attention.
See https://beam.apache.org/contribute/issue-priorities for the meaning and
expectations around issue priorities.
Unassigned P1 Issues:
https://github.com/apache/beam/issues/33793 The PreCommit Java
