Bug 867105 - python-flask should requires python-jinja2-26
python-flask should requires python-jinja2-26
Status: CLOSED CANTFIX
Product: Fedora EPEL
Classification: Fedora
Component: python-flask (Show other bugs)
el6
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Ricky Elrod
Fedora Extras Quality Assurance
: Reopened
: 1079599 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-10-16 15:07 EDT by Pierre-YvesChibon
Modified: 2014-03-21 21:32 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-06-22 10:50:30 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Reproducing Application (984 bytes, application/octet-stream)
2012-10-17 11:57 EDT, Tim Flink
no flags Details
Simpler reproducer (370 bytes, application/octet-stream)
2013-05-15 11:23 EDT, Jon Fautley
no flags Details

  None (edit)
Description Pierre-YvesChibon 2012-10-16 15:07:55 EDT
Description of problem:
In the current version of python-flask in EPEl6, it only requires python-jinja2 which is at the version 2.2.

Apparently, since flask 0.6 [1], it requires the jinja2 plugin 'autoescape' which has been added in jinja2.4 [2]

[1] http://flask.pocoo.org/mailinglist/archive/2010/7/29/error-after-upgrade/#2f25f80f52e6da50e15ad41e8fdb1b68

[2] http://jinja.pocoo.org/docs/extensions/#autoescape-extension

Version-Release number of selected component (if applicable):
python-flask-0.9-5.el6.noarch

How reproducible:
always (see [1] as well)

Steps to Reproduce:
1. see code in [1]
2.
3.
  
Actual results:
Error as described in [1]

Expected results:
A working flask application

Additional info:
Comment 1 Ricky Elrod 2012-10-17 04:19:50 EDT
Hi - we actually do dep on python-jinja2-26. python-jinja2 gets brought in because we also dep on python-sphinx.

See:
http://pkgs.fedoraproject.org/cgit/python-flask.git/tree/python-flask.spec#n19

I can't reproduce this, given the same code as [1] you linked above.

[root@junk09 ~]# cat /tmp/foo.py
from flask import Flask 
app = Flask(__name__) 

@app.route("/") 
def hello(): 
    return "Hello World!" 

if __name__ == "__main__": 
    app.run() 
[root@junk09 ~]# python /tmp/foo.py &
[1] 24653
* Running on http://127.0.0.1:5000/

[root@junk09 ~]# curl localhost:5000
127.0.0.1 - - [17/Oct/2012 07:59:40] "GET / HTTP/1.1" 200 -
Hello World!
[root@junk09 ~]#
Comment 2 Tim Flink 2012-10-17 11:57:51 EDT
Created attachment 628908 [details]
Reproducing Application

I wrote a quick reproducer that throws errors when '/' is accessed using the devel server on el6
Comment 3 Ricky Elrod 2012-10-17 18:43:58 EDT
Ok, that repro'd.

Looking into this, thanks.
Comment 4 Jon Fautley 2013-05-15 11:23:18 EDT
Created attachment 748371 [details]
Simpler reproducer

This bug is still present and affecting installs of Flask on EL6 systems.

It appears that while the RPM has a dep on python-jinja2-26, nothing is actually telling the Flask module to use that installation over the python-jinja2 package.

A workaround for this is to manually set PYTHONPATH to point to the jinja2-26 installation directory. I've attached a simpler test case to this bug, results below:

[user@host ~]$ ./867105-reproducer.py
'module' object has no attribute 'autoescape'

[user@host ~]$ PYTHONPATH=/usr/lib/python2.6/site-packages/Jinja2-2.6-py2.6.egg ./867105-reproducer.py
Got TemplateNotFound
Comment 5 Pierre-YvesChibon 2013-05-15 11:26:16 EDT
I ran around the problem by adding on my script the following lines:

> # Required to build on EL6
> __requires__ = ['SQLAlchemy >= 0.7', 'jinja2 >= 2.4']
> import pkg_resources
Comment 6 Till Maas 2013-06-17 07:07:02 EDT
When will an update be issued? It looks like Flask is broken in EPEL now for more than half a year.
Comment 7 Ricky Elrod 2013-06-17 14:14:20 EDT
Ok, after looking at this again for a few hours today and talking with a bunch of folks in #fedora-apps, it appears that the way Pierre-YvesChibon handles this in comment 5 is the best way to go about it.

Adding the following to the reproducer in attachment 748371 [details] fixes the issue.

__requires__ = ['jinja2 >= 2.4']
import pkg_resources

If your app needs to work on EL6, add those lines and it should work. Sorry there isn't a better fix, but I'm told this is the way to handle it.

I'll make an update that includes a README.el6 explaining the need to do this.
Comment 8 Till Maas 2013-06-17 17:01:22 EDT
(In reply to Ricky Elrod from comment #7)

> Adding the following to the reproducer in attachment 748371 [details] fixes
> the issue.
> 
> __requires__ = ['jinja2 >= 2.4']
> import pkg_resources
> 
> If your app needs to work on EL6, add those lines and it should work. Sorry
> there isn't a better fix, but I'm told this is the way to handle it.

Who says this is the way to handle this? https://fedoraproject.org/wiki/Packaging:Python_Eggs recommends to inserts the full egg path into sys.path.

Also it seems that flask could add the line as well to the location where jinja2 is imported and it will fix the reproduces if the reproducer file does not import jinja2 itself.

> I'll make an update that includes a README.el6 explaining the need to do
> this.

The jinja and sqlalchemy package in EPEL contain README.Fedora files instead.
Comment 9 Toshio Ernie Kuratomi 2013-06-17 19:51:02 EDT
(In reply to Till Maas from comment #8)
> Who says this is the way to handle this?
> https://fedoraproject.org/wiki/Packaging:Python_Eggs recommends to inserts
> the full egg path into sys.path.
> 
There's several reasons that __requires__ is a better recommendation but it partially depends on the audience (also note that I mentioned to relrod in IRC the possibility of updating the guidelines to make __requires__ less deprecated... setuptools upstream has been takne over by new maintainers).


* First reason is that the __requires__ lines are inserted automatically in many upstream scripts by setuptools when those scripts are defined as setuptools entrypoints.  Just as an example, see the python-sphinx package.  In the upstream setup.py there's a:     
    entry_points={
        'console_scripts': [
            'sphinx-build = sphinx:main',
    [...]
This causes setuptools to create a sphinx-build script that is installed into %{_bindir}.  The sphinx-build command has:

    __requires__ = 'Sphinx==1.1.3'
    import sys
    from pkg_resources import load_entry_point
    [...]
This will have the effect of loading the sphinx package at that version and all dependent packages at their proper versions (note: barring setuptools bugs.  Of which there are some which have never been fully diagnosed.)

* Fixing this by inserting into sys.path has a drawback as well.  Whenever the version of the depended upon package is updated, the path to the egg directory changes.  This means that the depending packages would need to be updated any time this occurs.

> Also it seems that flask could add the line as well to the location where
> jinja2 is imported and it will fix the reproduces if the reproducer file
> does not import jinja2 itself.
>
flask already specifies the correct versioned dependencies using egg metadata.  So applications that do __requires__='flask' should pick up the correct jinja2.

It is possible for the flask package to put sys.path.insert() into its own code but this is not a good fix for several reasons:

* flask will have to be updated anytime python-jinja2-26 is updated.
* By the time flask code is invoked, it may be too late to set sys.path because the application may have already imported jinja2.  This is something that needs to be done at application startup which is something that only the application can determine.
Comment 10 Till Maas 2013-06-18 08:20:17 EDT
Just a sidenote: in wsgi files the required workaround differs again:
https://github.com/fedora-infra/fedora-tagger/blob/develop/apache/fedoratagger.wsgi
| import __main__
| __main__.__requires__ = ['SQLAlchemy >= 0.7', 'jinja2 >= 2.4', 'mako >= 0.4']
| import pkg_resources

Instead of setting __requires__ directly __main__ needs to be used.
Comment 11 Ricky Elrod 2014-03-21 21:32:52 EDT
*** Bug 1079599 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.