On 07/15/2016 09:32 PM, Thomas De Schampheleire wrote:
On Tue, Jul 12, 2016 at 12:55 PM, Mads Kiilerich <[email protected]> wrote:
On 06/30/2016 08:11 PM, Thomas De Schampheleire wrote:
I'm now looking at the other tests. One specific failure is easy to
reproduce, either:
$ py.test kallithea/tests/functional/test_changelog.py
or interactively by launching kallithea with the test.ini:
$ paster serve kallithea/tests/test.ini
then browsing to one of either repos vce_test_hg/git and then to
'Changelog'.
This renders a 500 Server Error without traceback or further information.
I was able to zoom in on the problem with manual traces, and found it
is related to pagination. If I remove the pagination block from the
template (see patch below) then the Changelog page works fine (except
for pagination, of course).
diff --git a/kallithea/templates/changelog/changelog.html
b/kallithea/templates/changelog/changelog.html
--- a/kallithea/templates/changelog/changelog.html
+++ b/kallithea/templates/changelog/changelog.html
@@ -160,7 +160,6 @@
</div>
<div class="pagination-wh pagination-left">
- ${c.pagination.pager('$link_previous ~2~ $link_next')}
</div>
</div>
</div>
However, it is unclear to me how to proceed. What is the problem with
this pagination, why is it a problem under Turbogears2 and not under
Pylons? How to see more details about the failures?
I think that I am missing some debugging skills in python - Kallithea
- mako - Turbogears2. I would be grateful if others with more
experience could help me on that. In this problem, it looks like there
is some kind of template rendering problem, but without any hint in
the logs.
Thanks,
Thomas
I tried to test it but encountered some problems trying to follow
https://bitbucket.org/conservancy/kallithea/wiki/Turbogears2Migration.md .
It seems like it really wants "setup.py develop"? "pip install -e ."
doesn't work? Do you know ... what is the story around that?
Also, it took me a while to figure out that even though the config file
and database must be created with another installation, the ini file
must be changed to use sqlalchemy.url without db1 . Any other changes to
watch out for?
Please consider clarifying the wiki page.
Anyway, I do get a nice traceback on stdout when encountering the 500
from the pager:
File "/home/mk/kallithea-tg/kallithea/controllers/changelog.py", line
176, in index
return render('changelog/changelog.html')
File "/home/mk/kallithea-tg/kallithea/lib/base.py", line 65, in render
return render_template({'url': url}, 'mako', template_path)
File
"/home/mk/kallithea-venv/lib/python2.7/site-packages/tg/render.py", line
212, in render
kwargs['result'] = render_function(template_name, tg_vars, **kwargs)
File
"/home/mk/kallithea-venv/lib/python2.7/site-packages/tg/renderers/mako.py",
line 126, in __call__
cache_type=cache_type, cache_expire=cache_expire)
File
"/home/mk/kallithea-venv/lib/python2.7/site-packages/tg/render.py", line
278, in cached_template
return render_func()
File
"/home/mk/kallithea-venv/lib/python2.7/site-packages/tg/renderers/mako.py",
line 123, in render_template
return Markup(template.render_unicode(**template_vars))
File
"/home/mk/kallithea-venv/lib/python2.7/site-packages/Mako-1.0.0-py2.7.egg/mako/template.py",
line 452, in render_unicode
as_unicode=True)
File
"/home/mk/kallithea-venv/lib/python2.7/site-packages/Mako-1.0.0-py2.7.egg/mako/runtime.py",
line 803, in _render
**_kwargs_for_callable(callable_, data))
File
"/home/mk/kallithea-venv/lib/python2.7/site-packages/Mako-1.0.0-py2.7.egg/mako/runtime.py",
line 835, in _render_context
_exec_template(inherit, lclcontext, args=args, kwargs=kwargs)
File
"/home/mk/kallithea-venv/lib/python2.7/site-packages/Mako-1.0.0-py2.7.egg/mako/runtime.py",
line 860, in _exec_template
callable_(context, *args, **kwargs)
File "_base_root_html", line 203, in render_body
File "_base_base_html", line 41, in render_body
File "changelog_changelog_html", line 218, in render_main
File "/home/mk/kallithea-tg/kallithea/lib/helpers.py", line 1020, in
pager
result = re.sub(r'~(\d+)~', self._range, format)
File "/usr/lib64/python2.7/re.py", line 155, in sub
return _compile(pattern, flags).sub(repl, string, count)
File "/home/mk/kallithea-tg/kallithea/lib/helpers.py", line 977, in
_range
nav_items.append(self._pagerlink(thispage, text_))
File
"/home/mk/kallithea-venv/lib/python2.7/site-packages/WebHelpers-1.3-py2.7.egg/webhelpers/paginate.py",
line 841, in _pagerlink
link_url = url_generator(**link_params)
File
"/home/mk/kallithea-venv/lib/python2.7/site-packages/Routes-1.13-py2.7.egg/routes/util.py",
line 269, in url_for
(args, kargs))
GenerationException: url_for could not generate URL. Called with args:
() {'page': 2}
One reason I get a nice traceback might be that I use pip for installing
as much as possible and thus don't get the annoying eggs but readable
python.
It seems like the problem is that this helpers.py pager function ends up
in webhelpers/paginate.py which has some pylons specific code and uses
url_generator = pylons.url.current when using Pylons.
It can apparently be worked around with
--- a/kallithea/lib/helpers.py
+++ b/kallithea/lib/helpers.py
@@ -911,6 +911,10 @@ class Page(_Page):
Custom pager to match rendering style with YUI paginator
"""
+ def __init__(self, *args, **kwargs):
+ kwargs.setdefault('url', url.current)
+ _Page.__init__(self, *args, **kwargs)
+
def _get_pos(self, cur_page, max_page, items):
edge = (items / 2) + 1
if (cur_page <= edge):
@@ -1050,11 +1054,12 @@ class Page(_Page):
class RepoPage(Page):
def __init__(self, collection, page=1, items_per_page=20,
- item_count=None, url=None, **kwargs):
+ item_count=None, url=url.current, **kwargs):
"""Create a "RepoPage" instance. special pager for paging
repository
"""
+ # FIXME: Why not calling baseclass __init__?
self._url_generator = url
# Safe the kwargs class-wide so they can be used in the
pager() method
This could probably just be upstreamed now, already while still using
Pylons.
Closing comment: This made me look at the Page code. Now I feel sad. But
the TG stuff generally seems to work. That makes me happy.
/Mads
_______________________________________________
kallithea-general mailing list
[email protected]
http://lists.sfconservancy.org/mailman/listinfo/kallithea-general
