[Bf-committers] Proposal for clarified VFX Reference Platform Support
ideasman42 at gmail.com
Thu Jan 20 04:34:14 CET 2022
This discussion seems to suffer the same fate as other VFX platform
threads... fizzle out with no conclusion.
Could we at least confirm the current status - that is: Python can be
upgraded without being limited by the VFX platform. If someone
proposes to change this - it's fine.
As it happens Sergey's proposal (which I support) doesn't impact
Python either way, so this being undecided shouldn't block upgrading.
If there is a push from other developers to change the policy for
Python, we can always re-evaluate that. If this is the case though -
it should be done now, instead of raising doubts that don't lead to
On Tue, Jan 18, 2022 at 2:40 AM Brecht Van Lommel via Bf-committers
<bf-committers at blender.org> 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
> 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:
More information about the Bf-committers