+1
On Wed, Jan 29, 2025 at 12:31 PM Robert Bradshaw via dev <
dev@beam.apache.org> wrote:
> 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 pas
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
Hey everyone, I put together a mini-doc on bundling some more Beam
Python/ML extras so that we have a better strategy for making sure that
users can use ML (or other Python) dependencies which are well tested with
their Beam version. It is mostly in line with how we handle our other
dependencies an
