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

Brecht Van Lommel brechtvanlommel at gmail.com
Mon Jan 17 16:39:33 CET 2022


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
>


More information about the Bf-committers mailing list