Yes, pinning Werkzeug was only a temporary fix until all the transitive dependency versions are correctly updates, for instance Flask-AppBuilder has merged the fix https://github.com/dpgaspar/Flask-AppBuilder/commit/7a9c2b822265fc9194ea038798814a06b10ccdb2 but that is not yet included in any release.
On Feb 12 2020, at 11:01 pm, Anton Zayniev <[email protected]> wrote: > I'm not sure this is a correct thread, but IMO pinning werkzeug version is > a little bit too strong. We may have a problem if one dependencies will use > some functionality of werkzeug>1.0. Afaik flask currently allows > werkzeug>1.0 usage, that'll probably introduce some discrepancies soon. > Meanwhile I discovered that the only library that introduces problem for > now is flask-admin. And it is already patched > <https://github.com/flask-admin/flask-admin/releases/tag/v1.5.5> to fix > conflict. I think that just bumping flask-admin to 1.5.5 (currently 1.5.4) > would be more accurate fix. > Anton > > On Fri, 7 Feb 2020 at 16:06, Kaxil Naik <[email protected]> wrote: > > +1 binding > > On Fri, Feb 7, 2020, 20:41 Daniel Imberman <[email protected]> > > wrote: > > > > > +1 binding > > > via Newton Mail > > > [ > > > > > https://cloudmagic.com/k/d/mailapp?ct=dx&cv=10.0.32&pv=10.14.6&source=email_footer_2 > > > ] > > > On Fri, Feb 7, 2020 at 6:22 AM, Bolke de Bruin <[email protected]> > > > > wrote: > > > +1 binding > > > > > > Sent from my iPhone > > > > On 7 Feb 2020, at 14:08, Jarek Potiuk <[email protected]> > > wrote: > > > > > > > > Agree. > > > > > On Fri, Feb 7, 2020 at 2:05 PM Ash Berlin-Taylor <[email protected]> > > > wrote: > > > > > > > > > > Hello all, > > > > > So Werkzeug 1.0 was released this morning, and it finally broke a > > > number > > > > > of direct or indirect dependencies of ours (Werkzeug is a WSGI helper > > > > > library. It mans "tool" in German.) -- meaning 1.10.8 that was just > > > > > released won't funciton > > > > > (The fix for now is to do pip install "werkzeug<1.0.0") > > > > > So I'm going to release 1.10.9 with the fix from Jarek to pin the > > > > > > > > > > version > > > > > (yes, pinning properly is something we still need to tackle.) and I > > > > > > > > > > would > > > > > like to not wait for 72 hours for this release. > > > > > It appears that 72 hours is just a convention, see > > > > > https://apache.org/legal/release-policy.html#release-approval: > > > > > > Release votes SHOULD remain open for at least 72 hours. > > > > > > > > > > In this case since the change > > > > > > > > > > (https://github.com/apache/airflow/pull/7377) > > > > > is one line to restrict the version of Werkzeug to the known working > > > > > version that passed the 1.10.8 vote I am propsing that in case I have > > > > > > > > > > the > > > > > following vote: > > > > > For 72 hours _OR_ until 3 binding votes have been cast > > > > > (Normally the vote is and.) What do people thing? > > > > > -ash > > > > > > > > > > > > > > > > > -- > > > > Jarek Potiuk > > > > Polidea <https://www.polidea.com/> | Principal Software Engineer > > > > > > > > M: +48 660 796 129 <+48660796129> > > > > [image: Polidea] <https://www.polidea.com/> > > > > > > >
