[Bf-committers] Blender developer week notes - 2022.01.17
Hi all, Here are the compiled notes for this week's development. For the complete report with modules and projects updates, links and more read it on: https://devtalk.blender.org/t/17-january-2022/22308 Welcomes * Henrik Dick (author of complex solidify modifier), has been granted commit access to continue development in this area. Welcome! Announcements = * Strategic Targets 2022 post on the code blog. [1] Modules & Projects == * In the full report you find a link to the Geometry Nodes Sub-Module Meeting notes. [1] https://code.blender.org/2022/01/strategic-targets-2022/ Have a great week, Thomas -- Thomas Dinges - tho...@blender.org - www.blender.org Developer Community Coordinator at Blender Buikslotermeerplein 161 - 1025 ET Amsterdam - The Netherlands ___ Bf-committers mailing list Bf-committers@blender.org List details, subscription details or unsubscribe: https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Proposal for clarified VFX Reference Platform Support
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@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@blender.org >> List details, subscription details or unsubscribe: >> https://lists.blender.org/mailman/listinfo/bf-committers >> > ___ > Bf-committers mailing list > Bf-committers@blender.org > List details, subscription details or unsubscribe: > https://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@ble
Re: [Bf-committers] Proposal for clarified VFX Reference Platform Support
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@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@blender.org > List details, subscription details or unsubscribe: > https://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org List details, subscription details or unsubscribe: https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Proposal for clarified VFX Reference Platform Support
> 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@blender.org List details, subscription details or unsubscribe: https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Proposal for clarified VFX Reference Platform Support
Hi Bastien, That's a good question you're bringing. For the Python my thoughts are aligned with Campbell. For other libraries I wouldn't make it an official support in the terms that it is us who verifies Blender compiles and works with library versions we don't use ourselves, but we should be open to fixes (assuming they are small, non-intrusive) from people who actually compile Blender with those library versions. Very similar to how we support platforms other than x86_64 and arm64. Bets regards, - Sergey - Sergey Sharybin - ser...@blender.org - www.blender.org Principal Software Engineer, Blender Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands On Mon, Jan 17, 2022 at 1:42 PM Campbell Barton via Bf-committers < bf-committers@blender.org> wrote: > On Mon, Jan 17, 2022 at 11:12 PM Bastien Montagne via Bf-committers > wrote: > > > > Hi Sergey and all, and thanks for this proposition. > > > > This proposal makes complete sense to me. I do not see any benefit for > > Blender to stick to a strict compatibility with VFX platform, but indeed > > ensuring a file-level compatibility seems a good minimum guaranty. > > > > I have one question though, should we still guarantee that we keep > > Blender working with the VFX platform versions of the libraries, or not? > > E.g. do we keep Blender working with python 3.9, even if we switch our > > own builds to 3.11? Think the answer to this question should also be > > clearly stated. > > > > And if we do keep this compatibility level, how do we ensure it? Add new > > buildbot instances with VFX-versioned dependencies? Just 'do our best' > > and fix issues when reported? > > For other libraries, I don't have a strong opinion, for Python though > - keeping *official* support for multiple versions adds too much > overhead. > Even for tracker triage, switching Python versions to match the user > who's reporting takes extra time. > And as you mention - integrating this into the build-bot etc would be > needed too (ideally at least) > > We could consider *unofficial* support by not breaking builds for > older Python versions for a period of time, > meaning that users who have a requirement for an older version can > still build Blender themselves. > Although I'm not sure this is an important use case, just noting that > I wouldn't rule it out entirely. > > > Cheers, > > Bastien > > > > ___ > > Bf-committers mailing list > > Bf-committers@blender.org > > List details, subscription details or unsubscribe: > > https://lists.blender.org/mailman/listinfo/bf-committers > > > > -- > - Campbell > ___ > Bf-committers mailing list > Bf-committers@blender.org > List details, subscription details or unsubscribe: > https://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org List details, subscription details or unsubscribe: https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Proposal for clarified VFX Reference Platform Support
On Mon, Jan 17, 2022 at 11:12 PM Bastien Montagne via Bf-committers wrote: > > Hi Sergey and all, and thanks for this proposition. > > This proposal makes complete sense to me. I do not see any benefit for > Blender to stick to a strict compatibility with VFX platform, but indeed > ensuring a file-level compatibility seems a good minimum guaranty. > > I have one question though, should we still guarantee that we keep > Blender working with the VFX platform versions of the libraries, or not? > E.g. do we keep Blender working with python 3.9, even if we switch our > own builds to 3.11? Think the answer to this question should also be > clearly stated. > > And if we do keep this compatibility level, how do we ensure it? Add new > buildbot instances with VFX-versioned dependencies? Just 'do our best' > and fix issues when reported? For other libraries, I don't have a strong opinion, for Python though - keeping *official* support for multiple versions adds too much overhead. Even for tracker triage, switching Python versions to match the user who's reporting takes extra time. And as you mention - integrating this into the build-bot etc would be needed too (ideally at least) We could consider *unofficial* support by not breaking builds for older Python versions for a period of time, meaning that users who have a requirement for an older version can still build Blender themselves. Although I'm not sure this is an important use case, just noting that I wouldn't rule it out entirely. > Cheers, > Bastien > > ___ > Bf-committers mailing list > Bf-committers@blender.org > List details, subscription details or unsubscribe: > https://lists.blender.org/mailman/listinfo/bf-committers -- - Campbell ___ Bf-committers mailing list Bf-committers@blender.org List details, subscription details or unsubscribe: https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Proposal for clarified VFX Reference Platform Support
Hi Sergey and all, and thanks for this proposition. This proposal makes complete sense to me. I do not see any benefit for Blender to stick to a strict compatibility with VFX platform, but indeed ensuring a file-level compatibility seems a good minimum guaranty. I have one question though, should we still guarantee that we keep Blender working with the VFX platform versions of the libraries, or not? E.g. do we keep Blender working with python 3.9, even if we switch our own builds to 3.11? Think the answer to this question should also be clearly stated. And if we do keep this compatibility level, how do we ensure it? Add new buildbot instances with VFX-versioned dependencies? Just 'do our best' and fix issues when reported? Cheers, Bastien ___ Bf-committers mailing list Bf-committers@blender.org List details, subscription details or unsubscribe: https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Proposal for clarified VFX Reference Platform Support
On Mon, Jan 17, 2022 at 9:24 PM Sergey Sharybin via Bf-committers > I agree that the outcome should be much more prominently communicated. > That's what I think should happen as an outcome of discussion in this > thread: we come up with policy and explicitly communicate it. +1, just noting that this was discussed not all that long ago, without much push to move back to Python supporting the VFX platform. It seems there was an assumption from some developers more recently that the VFX-platform reaching Python 3.9 would mean Blender's Python was following the VFX platform again (instead of this being incidental and a temporary situation). > Ray, Campbell: The Python situation is a subset of the proposal in my > original message. So in this regard we are aligned. But it is not really > clear to me what your position is when it comes to non-Python. Do you > disagree with the proposal, are you fine with it, or suggest something else? In general +1 for your proposal, staying compatible gives an assurance that Blender will run for organizations using Blender with the VFX platform without limiting us too much. It would be good to hear from users who take advantage of the VFX platform though. ___ Bf-committers mailing list Bf-committers@blender.org List details, subscription details or unsubscribe: https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Proposal for clarified VFX Reference Platform Support
Sergey, the correct link to Campbell's reply would be: https://lists.blender.org/pipermail/bf-committers/2021-May/050998.html (it was missing .html in his original email) Op ma 17 jan. 2022 om 11:24 schreef Sergey Sharybin via Bf-committers < bf-committers@blender.org>: > Hi, > > Thanks for the feedback. > > I don't really feel great about Python being the only exception allowed to > be digressed from the platform. It is the most impactful library from the > ones which are directly facing users. If we allow it to be different from > what the Platform is stating, I don't see issues with digression in other > libraries which nobody from users is likely to even notice. > > For the TBB sure there were no big passionate discussions, at least yet. It > doesn't mean staying at an older (officially unsupported, btw) version > doesn't bring, say, maintenance and development and moving forward > complications. > > Campbell, it seems something went wrong with URLs in your message. Not sure > which exact mail/thread the first one is supposed to be pointing, and the > second one is 404. Do you mind sending a followup with updated links? > > I agree that the outcome should be much more prominently communicated. > That's what I think should happen as an outcome of discussion in this > thread: we come up with policy and explicitly communicate it. > > Ray, Campbell: The Python situation is a subset of the proposal in my > original message. So in this regard we are aligned. But it is not really > clear to me what your position is when it comes to non-Python. Do you > disagree with the proposal, are you fine with it, or suggest something > else? > > Best regards, > - Sergey - > > Sergey Sharybin - ser...@blender.org - www.blender.org > Principal Software Engineer, Blender > Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands > > > On Mon, Jan 17, 2022 at 5:58 AM Campbell Barton via Bf-committers < > bf-committers@blender.org> wrote: > > > As far as I'm aware, the decision for Blender *not* to follow the VFX > > platform for Python is still in place (allowing us to follow Python's > > release schedule, unless there are good reasons not to). > > > > Last time the topic came up was May 2021, the discussion petered out > > and there were no conclusions from that thread or meeting minutes at > > the time that any changes were planned. see: [0] "VFX reference > > platform 2022 draft" thread. > > Although it would have been good if the outcome of this discussion was > > noted in meeting minutes (or noted needing further discussion if > > developers involved thought the topic was unresolved). > > > > My opinion on this hasn't changed from the comments made here [1]. > > > > [0]: > > > https://lists.blender.org/pipermail/bf-committers/2021-May/thread.html#50990 > > [1]: https://lists.blender.org/pipermail/bf-committers/2021-May/050998. > > > > > > On Sat, Jan 15, 2022 at 11:57 AM Ray Molenkamp via Bf-committers > > wrote: > > > > > > All right, looks like we're tiptoeing around > > > the elephant in the room, time to rip that > > > Band-Aid off (feels like this metaphor kinda > > > got away from me, but I'm sticking with it!) > > > > > > Let’s not beat around the bush, no-one has > > > ever complained about our OIIO, Boost, VDB or > > > TBB versions. People get ..passionate.. > > > about python, anytime someone brings up the > > > VFX Platform it's python, It's never anything > > > else, it's python, the rest of the VFX platform > > > may as well not exist. The issue is, and will > > > always be python. > > > > > > The real question is, are we going to follow > > > the platform in regards to python or not. > > > > > > The way the python [1] and VFX Platforms [2] > > > are released those most we'll ever have is a > > > 5-month window where the two will overlap and > > > there will actually be active bug fix support > > > on python the python version of the VFX Platform. > > > Are we OK with that? > > > > > > People get upse..uhh passionate when we "suddenly" > > > change our python version. What is needed is a > > > clear and decisive message regarding how we pick > > > our python versions. > > > > > > Are we following: > > > > > > A) The python release schedule > > > B) The VFX platform schedule > > > C) Well, you know maybe, VFX kind of works out > > > this year so why not, next year maybe not so > > > much, we'll see, oh hey this years python has …. > > > [check notes]..better….. error.. messages? we got > > > to upgrade! > > > D) Other > > > > > > We have been doing C, and I don't think anyone > > > is super thrilled about how this is working out. > > > > > > I mostly don’t even care what we pick (not C!!) > > > pick something, write it down somewhere, so people > > > can rely on it. > > > > > > --Ray > > > > > > [1] https://www.python.org/dev/peps/pep-0602/ > > > [2] https://vfxplatform.com/about/ > > > > > > _
Re: [Bf-committers] Proposal for clarified VFX Reference Platform Support
Hi, Thanks for the feedback. I don't really feel great about Python being the only exception allowed to be digressed from the platform. It is the most impactful library from the ones which are directly facing users. If we allow it to be different from what the Platform is stating, I don't see issues with digression in other libraries which nobody from users is likely to even notice. For the TBB sure there were no big passionate discussions, at least yet. It doesn't mean staying at an older (officially unsupported, btw) version doesn't bring, say, maintenance and development and moving forward complications. Campbell, it seems something went wrong with URLs in your message. Not sure which exact mail/thread the first one is supposed to be pointing, and the second one is 404. Do you mind sending a followup with updated links? I agree that the outcome should be much more prominently communicated. That's what I think should happen as an outcome of discussion in this thread: we come up with policy and explicitly communicate it. Ray, Campbell: The Python situation is a subset of the proposal in my original message. So in this regard we are aligned. But it is not really clear to me what your position is when it comes to non-Python. Do you disagree with the proposal, are you fine with it, or suggest something else? Best regards, - Sergey - Sergey Sharybin - ser...@blender.org - www.blender.org Principal Software Engineer, Blender Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands On Mon, Jan 17, 2022 at 5:58 AM Campbell Barton via Bf-committers < bf-committers@blender.org> wrote: > As far as I'm aware, the decision for Blender *not* to follow the VFX > platform for Python is still in place (allowing us to follow Python's > release schedule, unless there are good reasons not to). > > Last time the topic came up was May 2021, the discussion petered out > and there were no conclusions from that thread or meeting minutes at > the time that any changes were planned. see: [0] "VFX reference > platform 2022 draft" thread. > Although it would have been good if the outcome of this discussion was > noted in meeting minutes (or noted needing further discussion if > developers involved thought the topic was unresolved). > > My opinion on this hasn't changed from the comments made here [1]. > > [0]: > https://lists.blender.org/pipermail/bf-committers/2021-May/thread.html#50990 > [1]: https://lists.blender.org/pipermail/bf-committers/2021-May/050998. > > > On Sat, Jan 15, 2022 at 11:57 AM Ray Molenkamp via Bf-committers > wrote: > > > > All right, looks like we're tiptoeing around > > the elephant in the room, time to rip that > > Band-Aid off (feels like this metaphor kinda > > got away from me, but I'm sticking with it!) > > > > Let’s not beat around the bush, no-one has > > ever complained about our OIIO, Boost, VDB or > > TBB versions. People get ..passionate.. > > about python, anytime someone brings up the > > VFX Platform it's python, It's never anything > > else, it's python, the rest of the VFX platform > > may as well not exist. The issue is, and will > > always be python. > > > > The real question is, are we going to follow > > the platform in regards to python or not. > > > > The way the python [1] and VFX Platforms [2] > > are released those most we'll ever have is a > > 5-month window where the two will overlap and > > there will actually be active bug fix support > > on python the python version of the VFX Platform. > > Are we OK with that? > > > > People get upse..uhh passionate when we "suddenly" > > change our python version. What is needed is a > > clear and decisive message regarding how we pick > > our python versions. > > > > Are we following: > > > > A) The python release schedule > > B) The VFX platform schedule > > C) Well, you know maybe, VFX kind of works out > > this year so why not, next year maybe not so > > much, we'll see, oh hey this years python has …. > > [check notes]..better….. error.. messages? we got > > to upgrade! > > D) Other > > > > We have been doing C, and I don't think anyone > > is super thrilled about how this is working out. > > > > I mostly don’t even care what we pick (not C!!) > > pick something, write it down somewhere, so people > > can rely on it. > > > > --Ray > > > > [1] https://www.python.org/dev/peps/pep-0602/ > > [2] https://vfxplatform.com/about/ > > > > ___ > > Bf-committers mailing list > > Bf-committers@blender.org > > List details, subscription details or unsubscribe: > > https://lists.blender.org/mailman/listinfo/bf-committers > > > > -- > - Campbell > ___ > Bf-committers mailing list > Bf-committers@blender.org > List details, subscription details or unsubscribe: > https://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers maili
