[Bf-committers] Proposal for clarified VFX Reference Platform Support

[Ray Molenkamp]

You may feel like you're alone in this, however you may
have an ally in me, and I may even go further than you.

If you read my previous emails in this thread carefully
you'll notice I have personally made no call regarding
the python version, I Don't feel it's my place to make
that call, I'm not on the python team, nor am I a project
admin, and as platform dev, building python 3.9.10 or
3.10.2, I'll be honest it's all the same to me.

I did make the case that if we don't follow python, there's
no point to follow any other recommendations, no-one is going
to care about our TBB or OpenVDB versions if we're out of
line on python, so let’s not make any commitments that benefit
no-one.

However, *IF* we decide to follow it for python, I'd say
we follow the whole thing, actually we ought to go even
further than what we did previously,and ship the python
bindings for components that support it, ship most libraries
shared rather than static (at-least on windows, unsure how
much of a pain-point this is on the *nix based platforms),
and make sure QT/Pyside integrate nicely, perhaps even go
as far as shipping QT. Since once you clear the python
version hurdle, that be the next most common issues that
these sorts of pipeline tools will run into.

You could say I'm an either all in, or all out kind of guy,
picking the bits that we like of the VFX Platform that happen
to align, and have that change between years, isn't a
position I think we should be in, since it's effectively an
"all out" position, with more (Rightfully so) complaining users
due to ambiguity on whether we are in or out for any given
blender release.

--Ray

On 2022-01-17 8:39 a.m., Brecht Van Lommel via Bf-committers wrote:
> For reference there is more discussion about this in the two tasks:
> 2021: https://developer.blender.org/T83246
> 2020: https://developer.blender.org/T68774
>
> My preference is still to track the full VFX platform, including the Python
> version. However I know I'm in the minority on this, and I'm not expecting
> that to change.
>
> I don't think it's practical to support multiple Python versions. For
> add-ons and particularly those with binaries, supporting both Python
> versions would be more work. Likely many of the add-ons would just not be
> tested and not work with the older Python version.
>
> I think other libraries do matter. We still wanted to switch to OpenColorIO
> 2 around the same time as other apps for example, regardless if file
> compatibility is a goal of the VFX platform. It should be a goal for us.
> Further some of these libraries have Python APIs that we'd like to expose,
> like pyopenvdb.
>
> In my opinion we should stick to the VFX platform by default and make
> exceptions as needed. We don't need to retread the Python discussion every
> year, the situation is still the same and it's reasonable to assume we
> continue being incompatible there. For other libraries, if it's not causing
> incompatibility I don't even see that as deviating from the VFX platform.
> If it does lead to incompatibility, I think we should take that into
> consideration.
>
> On Mon, Jan 17, 2022, 15:16 Ray Molenkamp via Bf-committers <
> bf-committers at blender.org> wrote:
>
>>> I don't really feel great about Python
>>> being the only exception allowed to be digressed
>>> from the platform.
>> I think you're misunderstanding the VFX Platform goals,
>> it has nothing to do with asset compatibility throughout
>> the pipeline. Otherwise, it would specify what formats
>> would have to be supported in OIIO, or what version
>> of blosc should be used for OpenVDB since using the
>> "wrong" blosc version will cause files to be unreadable
>> by older versions. It does none of these things.
>>
>> No, what it sets out to do is define a tightly controlled binary
>> runtime environment, if I link my binary addon to the library
>> versions in the platform, I will be able to load it into the host
>> applications that follow the platform without issues.
>>
>> If we break on python, none of the other things in the platform
>> matter, With the only notable exception being the glibc version
>> I suppose.
>>
>> Any commitments we may make to the platform while simultaneously
>> breaking on python are pointless, so no, that case I make is not
>> "Only python is/should be the exception", the case is, "If we
>> break on python there's no need to commit to anything else, so
>> best not to make any commitments."
>>
>> --Ray
>>
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> List details, subscription details or unsubscribe:
>> https://lists.blender.org/mailman/listinfo/bf-committers
>>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> List details, subscription details or unsubscribe:
> https://lists.blender.org/mailman/listinfo/bf-committers