Created attachment 178376 [details]
Patch to update devel/py-Jinja2
Update to 2.8.1
Superseded by bug #215858
Re-open, because Jinja2 > 2.9 works only with Python >= 3.5 (it uses async keyword in jinja2/asyncfilters.py file).
Created attachment 178672 [details]
Patch to update devel/py-Jinja2
- Limit to Python 2.7
- Remove reference to Python 3
Uh, wait. If Jinja2 >= 2.9 uses async, then 2.8.1 is still py3 compliant. We're using 2.8.1 in production with Python 3.5 (pip installed in virtualenv, tho', it's one of few packages we haven't yet switched to ports) and there's no problem, at least not to our use case (main HTML/XML renderer for a rather large flask web app).
As for update from 2.8 to 2.8.1, I'm adding merge-quarterly request, these are the changes:
(bugfix release, released on December 29th 2016)
- Fixed the `for_qs` flag for `urlencode`.
- Fixed regression when applying `int` to non-string values.
- SECURITY: if the sandbox mode is used format expressions are now sandboxed
with the same rules as in Jinja. This solves various information leakage
problems that can occur with format strings.
Please revise the change and leave Python3 support for 2.8.1.
(In reply to Vladimir Krstulja from comment #4)
No I keep my diff unchanged, it's maintainer's choice, if he wants to keep Python3 support.
(In reply to Olivier Duchateau from comment #5)
Ok. Let me just add this too, it appears that the asyncsupport.py is imported only if there's async support (environment.is_async == True), there's a conditional import for the template in compiler.py. I just ran a quick and dirty test in a py27 virtualenv, and Jinja2 2.9.3 imports fine. I have to test it with actual templates used, but I don't think there's a need to hard-limit Jinja2 to python2.7 only.
Please correct me if I'm wrong.
Also please be aware that there are 29 reverse dependencies of py-Jinja2, some of which, to my knowledge as I haven't tested all of them, build and work fine at the moment with DEFAULT_VERSIONS= python=3.5, most notably Sphinx and Flask. And only a handful of py3-Jinja2, I presume for some cases where those rdeps must be forced to py35-*
So another question is why is py3-Jinja2 an entirely separate port and not a slave? If a sweeping change like this is to be done, perhaps it should be done closer to the next Quarterly cut-off, and we can combine the ports and fully switch to 2.9.x?
the maintainer has timed out. Jinja 2.8 branch is now at 2.8.2. Could you please rework your original patch to update to 2.8.2, which is MFH-able and contains bugfixes over 2.8 currently in port. Then we can push HEAD's jinja to 2.9.5.
No need to limit it for Python2 only, all currently supported Jinja versions work for both Pythons.
I guess you can commit is straight away, since this is in timeout.
Maintainer timeout, back to pool. Sorry, missed to do that earlier.
Submitter is Committer.
A commit references this bug:
Date: Sat Apr 1 10:53:25 UTC 2017
New revision: 437424
Update to 2.9.5
- While I'm here:
- Remove 2to3 stuff
- Simplify PKGNAMESUFFIX check
PR: 215651 (based on)
Submitted by: olivierd
Approved by: maintainer (timeout, 3 months)
Please reopen for two reasons:
1. The merge-quarterly request was ignored. 2017Q2 just got branched off and there will otherwise be three more months of unpatched Jinja.
2. This update broke the port on Python 3, because 2to3 conversion was removed from the post-build step:
2to3 stuff has been restored in r437710.