Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

7.9.x Update to jinja2 2.11.1 #3502

Merged
merged 3 commits into from
Feb 19, 2020
Merged

Conversation

kinow
Copy link
Member

@kinow kinow commented Feb 16, 2020

These changes close #2572

Sibling PR of #3493

Requirements check-list

  • I have read CONTRIBUTING.md and added my name as a Code Contributor.
  • Contains logically grouped changes (else tidy your branch by rebase).
  • Does not contain off-topic changes (use other PRs for other changes).
  • Already covered by existing tests.
  • Appropriate change log entry included.
  • No documentation update required.

@kinow kinow changed the title Update to jinja2 11 1 [cylc-flow 7.8.x] Update to jinja2 2.11.1 Feb 16, 2020
@@ -33,7 +33,7 @@ __SUITERC__
run_fail "${TEST_NAME_BASE}" cylc validate 'suite.rc'
contains_ok "${TEST_NAME_BASE}.stderr" <<'__ERROR__'
Jinja2Error:
'You can only sort by either "key" or "value"'
raise FilterArgumentError('You can only sort by either "key" or "value"')
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The other changes are the result of copy-and-paste of Jinja2 2.11.1 ZIP contents, minus their asyncio files as that breaks the build due to Py3 code.

After copying the files, this was the only test that failed. Debugging it, it looks like the traceback contents changed in 2.11.1, and instead of having just the text on a new line, it contains the raise FilterArgumentError part too.

Wondering if that's safe to update... I don't think users rely on this?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems fine to me.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(What were the asyncio files for though? Is it surprising that deleting those didn't entirely break the new Jinja2?)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Curious, 2.11.1 claims to have 2.7 support. What aspect of the build was breaking? Was is our tests (e.g. pycodestyle) or something functional?

@kinow kinow force-pushed the update-to-jinja2-11-1 branch from d197dc9 to 4bed434 Compare February 16, 2020 23:39
@kinow kinow changed the title [cylc-flow 7.8.x] Update to jinja2 2.11.1 7.8.x Update to jinja2 2.11.1 Feb 16, 2020
@kinow
Copy link
Member Author

kinow commented Feb 16, 2020

Compared the output of the new Jinja2 library side-by-side with 7.8.x and master PR branches, and the traceback changed a bit.

image

For the 7.8.x one test failed as instead of starting a new line with 'You can only...', it starts now with raise FilterArgumentError('You can only...').

image

@kinow kinow self-assigned this Feb 16, 2020
@kinow kinow added this to the cylc-7.8.5 milestone Feb 16, 2020
@hjoliver
Copy link
Member

@kinow - well done getting this to work with 2.7

@oliver-sanders - this fixes a known bug, but are you particularly concerned about Jinja2 back-compat for Met Office Cylc-7 users? (Given that we bundle Jinja2 with Cylc 7, I'm not sure this statement is as true for Cylc 7 as it is for Cylc 8...)

@oliver-sanders
Copy link
Member

oliver-sanders commented Feb 17, 2020

this fixes a known bug, but are you particularly concerned about Jinja2 back-compat for Met Office Cylc-7 users?

Jinja2 bugs in workflows are nasty to debug, worse still as workflows often have highly-branched Jinja2 code bugs go unnoticed until a later date by which time the relation to the change of Cylc version is no longer obvious.

So Jinja2 changes need to be well managed and documented to give users a fighting chance. Sneaking a Jinja2 upgrade into a maintenance release would be unhelpful. It would break the trust of our release schedule if maintenance releases have significant interface changes.

From a change management perspective 8.0.0 is a more natural home for this change. But as 8.0.0 is so far off we could bump 7.8.5 to 7.9 and make a (small) minor release out of this.

@oliver-sanders
Copy link
Member

oliver-sanders commented Feb 17, 2020

Second thoughts, from the MO perspective we might still require Python2.6 compatibility for internal release which this would break. Will check.

If so we would want to push to this to 7.9 and maintain a 7.8.x branch for any future bugfixes.

@hjoliver
Copy link
Member

From a change management perspective 8.0.0 is a more natural home for this change. But as 8.0.0 is so far off we could bump 7.8.5 to 7.9 and make a (small) minor release out of this.

Can do. Is that OK with you @kinow (so your work here won't be wasted 👍 ) (For background, there are many well-known and well-used Cylc-7 suite configs that are essentially massive Jinja2 "programs" 😬 )

@hjoliver
Copy link
Member

(OK awaiting comment from @dpmatthews ... from offline chat with @oliver-sanders we could put this PR to 7.9.0, and maintain 7.8.x as well for the few remaining bug fixes...)

@kinow
Copy link
Member Author

kinow commented Feb 17, 2020

Happy if this is postponed to 7.9 or targeted only for 8.0. Whichever works best.

@dpmatthews
Copy link
Contributor

I don't think we can remove Python 2.6 compatibility in a 7.8.x release so this would need to become 7.9. We still have Cylc in use on RHEL 6 systems so would have to stick to 7.8. Unless there is demand from others, I suggest we make this an 8.0 change.

@TomekTrzeciak
Copy link
Contributor

I don't think we can remove Python 2.6 compatibility in a 7.8.x release so this would need to become 7.9. We still have Cylc in use on RHEL 6 systems so would have to stick to 7.8. Unless there is demand from others, I suggest we make this an 8.0 change.

@dpmatthews, legacy RHEL 6 machines are not the only ones that use python 2.6 for running cylc on our site. Just saying...

@hjoliver
Copy link
Member

Unless there is demand from others, I suggest we make this an 8.0 change.

Then all users for the next year (ish) will have to live with Jinja2 "incorrect context" bug, which is moderately serious (wrong line numbers are often worse than none, when debugging).

So I think putting to 7.9 would be better, for those not stuck on Python 2.6. We don't expect many more changes on 7.x so maintaining two branches for subsequent fixes will be easy enough.

@dpmatthews
Copy link
Contributor

So I think putting to 7.9 would be better, for those not stuck on Python 2.6. We don't expect many more changes on 7.x so maintaining two branches for subsequent fixes will be easy enough.

Fair enough. I assume this pull request will need to be changed to point to a new 7.9.x branch. The installation guide will also need an update to reflect the Python 2.7 requirement.

@oliver-sanders oliver-sanders modified the milestones: cylc-7.8.5, cylc-7.9.0 Feb 17, 2020
@@ -33,7 +33,7 @@ __SUITERC__
run_fail "${TEST_NAME_BASE}" cylc validate 'suite.rc'
contains_ok "${TEST_NAME_BASE}.stderr" <<'__ERROR__'
Jinja2Error:
'You can only sort by either "key" or "value"'
raise FilterArgumentError('You can only sort by either "key" or "value"')
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Curious, 2.11.1 claims to have 2.7 support. What aspect of the build was breaking? Was is our tests (e.g. pycodestyle) or something functional?

@kinow
Copy link
Member Author

kinow commented Feb 17, 2020

@oliver-sanders

Curious, 2.11.1 claims to have 2.7 support. What aspect of the build was breaking? Was is our tests (e.g. pycodestyle) or something functional?

Just this functional test. The output of their traceback changed a bit, so it wasn't matching the output correctly.

@oliver-sanders
Copy link
Member

Just this functional test. The output of their traceback changed a bit, so it wasn't matching the output correctly.

Sorry the context of that comment got skewed. I was referring to the removal of the async files.

@kinow
Copy link
Member Author

kinow commented Feb 17, 2020

Just this functional test. The output of their traceback changed a bit, so it wasn't matching the output correctly.

Sorry the context of that comment got skewed. I was referring to the removal of the async files.

Ah, that one. Travis still has the logs: https://travis-ci.org/kinow/cylc-flow/jobs/645797353

I think it was due to some functional or unit test loading that file?

@hjoliver
Copy link
Member

@kinow I've created the new 7.9.x branch, so you can re-target this PR.

@kinow kinow changed the base branch from 7.8.x to 7.9.x February 18, 2020 23:21
@kinow kinow changed the title 7.8.x Update to jinja2 2.11.1 7.9.x Update to jinja2 2.11.1 Feb 18, 2020
@kinow kinow force-pushed the update-to-jinja2-11-1 branch from 4bed434 to a0b5678 Compare February 18, 2020 23:27
@kinow
Copy link
Member Author

kinow commented Feb 18, 2020

  • Updated PR title
  • Rebased against 7.9.x (thanks @hjoliver !) with GitHub UI
  • Updated changelog (solving a request from @oliver-sanders to update it, thanks!)
  • Push-forced, so now Travis should be busy for a while running functional tests

@hjoliver
Copy link
Member

I'll merge this if it passes the functional tests again (it should) ... we've all agreed in principle, and it doesn't change any files outside of lib/jinja2/ ...

Copy link
Member

@hjoliver hjoliver left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tests pass 👍 ; this changes lib/jinja2/ only.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants