Bug 867105

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 ~]#

Created attachment 628908 [details]
Reproducing Application

I wrote a quick reproducer that throws errors when '/' is accessed using the devel server on el6

Ok, that repro'd.

Looking into this, thanks.

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

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

When will an update be issued? It looks like Flask is broken in EPEL now for more than half a year.

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.

(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.

(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.

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.

*** Bug 1079599 has been marked as a duplicate of this bug. ***