Jinja2 branch is now ready to test and review

62 views
Skip to first unread message

Christian Boos

unread,
Jan 12, 2017, 11:31:44 AM1/12/17
to trac...@googlegroups.com
Hello everybody,

I took some steps to finalize my migration of Trac to the Jinja2
template engine, and the results are now visible in several places.

The latest code is in the jinja2-trunk-r15341 branch:

https://svn.edgewall.org/git/trac/devs/cboos
https://github.com/cboos/trac.git

A demo instance is available:

https://trac.edgewall.org/testing

(this one also contains my wiki-restyling changes, for good measure)

The #12649 ticket can be used to report trivial issues you'd find with
Jinja2 (#12640 for the restyling ones). Don't hesitate to create new
tickets for more serious issues, if any.

It would be nice to get some feedback at this point. You can contribute
by either reviewing the code, or simply by playing around in
t.e.o/testing and report any glitches you'd find there.

If you have any questions, the mailing list would probably be more
appropriate. Be sure to first go through the following wiki pages, as
they may already contain the answer you're looking for:

- https://trac.edgewall.org/wiki/TracDev/Proposals/Jinja
- https://trac.edgewall.org/wiki/TracDev/PortingFromGenshiToJinja


Known "issues" so far:

- the branch keeps Genshi templates and Jinja2 templates side by side
(e.g. search.html and jsearch.html); that was helpful during the
development, and can still be useful while reviewing the branch, but I'm
going to go back to the original names soon (jsearch.html ->
search.html), moving a step closer to the merge.

- I haven't tested the i18n support for Jinja2 templates in plugins
yet; this is what I'm going to work on next


Also, I want to address the concerns raised last year about the backward
compatibility with Genshi. I propose to use the whole 1.4.x series as a
transition period, during which both template engines will be supported.
The plugins making use of Genshi templates won't need to be changed a
bit, while those which want to port to or start using Jinja2 templates
will have to use a new API: `IRequestHandler.process_request` methods
will have to return a `(template, data)` pair instead of the legacy
`(template, data, None)` triple. There's slightly more to it than this,
but you get the idea.

I've also taken into account the plugins which inject content in
generated pages via the ITemplateStreamFilter interface. That way is
deprecated in favor of using JavaScript for that purpose, but the
interface will nevertheless be supported during the transition period as
well.

One problem is that this ITemplateStreamFilter support mostly works, but
is not perfect, and of course kills most of the speed improvement
brought by the switch to Jinja2. Consider this as an incentive to
migrate such plugins! If people are really motivated to fix/enhance this
aspect, feel free to do so, but I feel it's somewhat counter-productive
to invest more energy there.

I hope we can soon finalize the integration of this effort, before we
make more serious moves on the Python3 topic (also, Jinja2 brings in six
as a dependency).

-- Christian

Peter Suter

unread,
Jan 12, 2017, 12:49:05 PM1/12/17
to trac...@googlegroups.com
Hello,

On 12.01.2017 17:31, Christian Boos wrote:
> A demo instance is available:
>
> https://trac.edgewall.org/testing
I stumbled on this:
https://trac.edgewall.org/testing/admin/spamfilter/bayes
Trac detected an internal error: TemplateNotFound: jadmin_bayes.html

I guess all admin panels are assumed to use Jinja templates (but the
plugin ones don't)?
https://trac.edgewall.org/browser/cboos.git/trac/admin/web_ui.py?rev=jinja2-trunk-r15341&marks=96,97,109#L72

Can IAdminPanelProvider.render_admin_panel() get a similar legacy mode
as IRequestHandler.process_request?

> The plugins making use of Genshi templates won't need to be changed a
> bit, while those which want to port to or start using Jinja2 templates
> will have to use a new API: `IRequestHandler.process_request` methods
> will have to return a `(template, data)` pair instead of the legacy
> `(template, data, None)` triple.

The difference seems quite subtle. But I guess it's tricky to be more
explicit without breaking backward compatibility or introducing an ugly
wart for the new way.


One tiny, tiny thing:
https://trac.edgewall.org/browser/cboos.git/trac/util/html.py?rev=jinja2-trunk-r15341&marks=383#L379
"will be in" -> "will be removed in"?


Unfortunately I can't do a more substantial review, sorry, but from what
I read this sounds great.

Peter

RjOllos

unread,
Jan 12, 2017, 6:32:23 PM1/12/17
to Trac Development

Some JavaScript issues noted so far:

* Missing group toggle checkbox on these tables: /admin/ticket/components, /admin/ticket/milestones, /admin/ticket/versions, /admin/versioncontrol/repository
* Missing group toggle feature on permissions table (#11417)
* Divs for plugins are not foldable on /admin/general/plugin

Also:
* On /roadmap, "Hide milestone with no due date" doesn't seem to stick, though the submitted value appears to be effective in filtering the milestones
* Some margin above "Repository Index" h1 on /browser page might be good
* "Visit", "View revisions", "View diff against" options on /browser page might look better with bigger or different font
* Name input on /admin page could be made same width as URL input (General: Basic Settings)
* Very minor preference: I like having just the box-shadow around the label for the folding links (e.g. Attachments on ticket page), rather than a border + box-shadow. Similarly for the folding links on the plugin admin page where the corners of the box at least look too square, might be better with a box-shadow and/or rounded.

Unrelated, it was a long time before I noticed the "View changes..." button on the bottom of the /browser page. I think this has been discussed in a ticket, but maybe that button should be made a link in the context nav?

I'll do more testing later today, or in coming days.

- Ryan

Christian Boos

unread,
Jan 14, 2017, 8:56:17 AM1/14/17
to trac...@googlegroups.com
Hello Peter,

On 1/12/2017 6:49 PM, Peter Suter wrote:
> Hello,
>
> On 12.01.2017 17:31, Christian Boos wrote:
>> A demo instance is available:
>>
>> https://trac.edgewall.org/testing
>
> I stumbled on this:
> https://trac.edgewall.org/testing/admin/spamfilter/bayes
> Trac detected an internal error: TemplateNotFound: jadmin_bayes.html
>
> I guess all admin panels are assumed to use Jinja templates (but the
> plugin ones don't)?
>
https://trac.edgewall.org/browser/cboos.git/trac/admin/web_ui.py?rev=jinja2-trunk-r15341&marks=96,97,109#L72
>

This 'j' prefix was present in various places in the templates and in
the code, which made troubleshooting this annoying. I have now removed
that prefix and all the special cases associated to this temporary hack,
so I could start testing this scenario.


> Can IAdminPanelProvider.render_admin_panel() get a similar legacy mode
> as IRequestHandler.process_request?

In render_admin_panel we already return just a pair (template, data). If
we keep that as the legacy API, we have to come up with something
different for the "new" API. I prefer to pay the cost of a small
backward incompatibility here, and keep (template, data) for the new
API, as it's simpler in the long run and consistent with what we already
do in IRequestHandler.process_request.

Plugins like the SpamFilter will have to be modified to return
(template, data, None) here. No big deal, see:


https://trac.edgewall.org/attachment/ticket/12639/spamfilter-jinja2-compat-r15349.diff

We have the same issue with the preference panel.

I've just pushed the changes that make this happen, see in particular:

https://trac.edgewall.org/changeset/0f3aee46/cboos.git


>> The plugins making use of Genshi templates won't need to be changed a
>> bit, while those which want to port to or start using Jinja2 templates
>> will have to use a new API: `IRequestHandler.process_request` methods
>> will have to return a `(template, data)` pair instead of the legacy
>> `(template, data, None)` triple.
>
> The difference seems quite subtle. But I guess it's tricky to be more
> explicit without breaking backward compatibility or introducing an ugly
> wart for the new way.
>
>
> One tiny, tiny thing:
>
https://trac.edgewall.org/browser/cboos.git/trac/util/html.py?rev=jinja2-trunk-r15341&marks=383#L379
>
> "will be in" -> "will be removed in"?
>

Thanks, fixed!

>
> Unfortunately I can't do a more substantial review, sorry, but from what
> I read this sounds great.
>

Thanks again!

-- Christian

Christian Boos

unread,
Jan 14, 2017, 2:40:07 PM1/14/17
to trac...@googlegroups.com
Hello Ryan,

On 1/13/2017 12:32 AM, RjOllos wrote:
>
> Some JavaScript issues noted so far:
>
> * Missing group toggle checkbox on these tables:
> /admin/ticket/components, /admin/ticket/milestones,
> /admin/ticket/versions, /admin/versioncontrol/repository
> * Missing group toggle feature on permissions table (#11417)
> * Divs for plugins are not foldable on /admin/general/plugin

All due to missing "block head" in these templates, around the <script>
tags.

> Also:
> * On /roadmap, "Hide milestone with no due date" doesn't seem to stick,
> though the submitted value appears to be effective in filtering the
> milestones

One "|htmlattr" filter missing.

> * Some margin above "Repository Index" h1 on /browser page might be good

Right, I removed the <br> but forgot to adjust this.

> * "Visit", "View revisions", "View diff against" options on /browser
> page might look better with bigger or different font

Oops, they still had a "10px", I need to check again for fixed sized
fonts, as obviously I missed some. Actually I missed a lot ;-)

> * Name input on /admin page could be made same width as URL input
> (General: Basic Settings)

OK.

> * Very minor preference: I like having just the box-shadow around the
> label for the folding links (e.g. Attachments on ticket page), rather
> than a border + box-shadow. Similarly for the folding links on the
> plugin admin page where the corners of the box at least look too square,
> might be better with a box-shadow and/or rounded.

I made it a bit lighter, but no border at all counters the more "crisp"
aspect I want to get overall. I obviously like box shadows as I put them
everywhere, but after a while I felt that I've added too much "fuzziness".

> Unrelated, it was a long time before I noticed the "View changes..."
> button on the bottom of the /browser page. I think this has been
> discussed in a ticket, but maybe that button should be made a link in
> the context nav?

I'll first see how well my idea of page "actions" would work. I'm
thinking of a kind of "menu" for links/buttons that apply on the
resource itself. For wiki pages, that would be Edit / Attach / Rename /
History / Delete version / Delete page. For tickets, that would be
Modify / Attach / Comment / Delete.
"Report spam" would also go there rather than into the context
navigation. Context navigation will instead refocus on links to other
resources (the start, parent, and index for the wiki; the query, prev,
and next for tickets).

If that works well for the wiki page, ticket and milestone, I can do
that for the browser page as well, and then the "View changes..." will
be one of the actions.


> I'll do more testing later today, or in coming days.

That would be great!

Thanks for the feedback so far. Here are the corresponding fixes:

(jinja2-trunk-r15341 branch)
- [a47b48a3/cboos.git] (#12639): fixing bugs spotted by Ryan.

(wiki-restyling branch)
- [6ff2ec27/cboos.git] (#633) second round...
- [1fbf96ce/cboos.git] (#12640) minor tweaks of foldable border, ...


Also, what would be great is if you (or anyone else for that matter)
could try to convert some plugins templates to Jinja2. That way, you
could tell me what is not clear in the migration guide, or simply still
missing from it.

-- Christian

Peter Suter

unread,
Jan 14, 2017, 5:22:19 PM1/14/17
to trac...@googlegroups.com
On 14.01.2017 20:40, Christian Boos wrote:
Also, what would be great is if you (or anyone else for that matter)
could try to convert some plugins templates to Jinja2. That way, you
could tell me what is not clear in the migration guide, or simply still
missing from it.

That's something I wanted to try anyway, since I have a few plugins that use (relatively simple) templates.

I semi-randomly picked OnSiteNotificationsPlugin for a first test. It only has two rather trivial templates.
https://trac-hacks.org/wiki/OnSiteNotificationsPlugin
https://trac-hacks.org/browser/onsitenotificationsplugin/trunk/onsitenotifications/templates/onsitenotification.html?rev=16170
https://trac-hacks.org/browser/onsitenotificationsplugin/trunk/onsitenotifications/templates/onsitenotification_list.html?rev=16170

Instead of actually properly reading through your nice, extensive notes I first tried the lazy, impatient trial-by-error approach:
I changed the `return "...", data, None` to `return "...", data` to actually use Jinja.
Then very briefly I looked at the first section of:
https://trac.edgewall.org/wiki/TracDev/PortingFromGenshiToJinja#ChangesintheHTML
I replaced the doctype and <html> as described.
I also searched and found the note about `# extends "layout.html"`,
but didn't immediately see where that should go, so I switched to:
https://trac.edgewall.org/wiki/TracDev/PortingFromGenshiToJinja/Example#Conversionexample
Since the templates looked so simple, I naively assumed that I was more or less done and tried running it.
But nothing showed up; not even an error.
So back to reading a tiny bit more, I found out about `#block title` and `#block content`.
Still nothing, back to reading. I added `${ super() }`.
Finally, I got some errors about `idx`, so I remembered I had to turn `py:for` into `# for`.
Error about `enumerate`. Found: https://trac.edgewall.org/wiki/TracDev/PortingFromGenshiToJinja#Noneedforenumerate
But nothing about "odd / even".
The linked site has an example though: `loop.cycle('odd', 'even')` http://jinja.pocoo.org/docs/dev/templates/#for
Now almost everything seemed to work, except
`$item.resource_href ` showed up on the page uninterpreted.
I remembered that I had to use `${item.resource_href}` instead.

That was all I think. Everything seems to work now. That was not too bad. Maybe I'll try another one later.

Peter


Just in case, the resulting templates:

# extends "layout.html"
<!DOCTYPE html>
<html>
  <head>
    <title>
      # block title
      Notification: ${message['subject']} ${ super() }
      # endblock title
    </title>
  </head>
  <body>
    # block content
    <h2>Notification: ${message['subject']}</h2>
    <pre>${message['body']}</pre>

    ${ super() }

    # endblock content
  </body>
</html>


# extends "layout.html"
<!DOCTYPE html>
<html>
  <head>
    <title>
      # block title
      Notifications ${ super() }
      # endblock title
    </title>
  </head>

  <body>
    # block content
    <div id="content">
      <h2>Notifications</h2>

      <table class="listing">
        <thead>
          <tr class="trac-columns"><th>Resource:</th><th>Details:</th></tr>
        </thead>
        <tbody>
          # for item in items:
          <tr class="${loop.cycle('odd', 'even')}">
            <td><a href="${item.resource_href}">${item['resource']}</a></td>
            <td><a href="${item.details_href}">${item['details']}</a></td>          
          </tr>
          # endfor
        </tbody>
      </table>
    </div>
    <div class="buttons">
      <form id="deletenotifications" action="" method="post">
        <input type="hidden" name="action" value="deletenotifications" />
        <input type="submit" class="trac-disable-on-submit" value="${_('Delete notifications')}" />
      </form>
    </div>

    ${ super() }

    # endblock content
  </body>
</html>

Peter Suter

unread,
Jan 15, 2017, 3:21:35 PM1/15/17
to trac...@googlegroups.com
On 14.01.2017 23:22, Peter Suter wrote:
> On 14.01.2017 20:40, Christian Boos wrote:
>> Also, what would be great is if you (or anyone else for that matter)
>> could try to convert some plugins templates to Jinja2. That way, you
>> could tell me what is not clear in the migration guide, or simply still
>> missing from it.
> Everything seems to work now. Maybe I'll try another one later.
Not quite everything. Apparently I need to add
`${jmacros.form_token_input()}` to every <form method="post">.
This is described here:
https://trac.edgewall.org/wiki/TracDev/PortingFromGenshiToJinja#Producingthecorrectcontentdirectly
Shouldn't this be moved out of the `ITemplateStreamFilter` section?

(Also I forgot to change
`from genshi.builder import tag, Markup`
to
`from trac.util.html import tag, Markup`
since the former still works at the moment.)

Next I converted https://trac-hacks.org/wiki/CardsPlugin
This plugin only has one simple template, but calls `render_template()`.
According to
https://trac.edgewall.org/wiki/TracDev/PortingFromGenshiToJinja#Generatingcontent
> When one wants to directly render a template, the Chrome component
facilities can be used, as before:
> {{{
> return Chrome(self.env).render_template(
> req, 'query_results.html', data, None, fragment=True)
> }}}
But actually it seems for Jinja templates one must now change this to:
{{{
return Chrome(self.env).render_template(
req, 'query_results.html', data, {'fragment': True})
}}}
no?

I also converted these three:
https://trac-hacks.org/wiki/PullRequestsPlugin
https://trac-hacks.org/wiki/MailArchivePlugin
https://trac-hacks.org/wiki/TimeTrackingPlugin
which needed also <xi:include />, # if, # with, # block head which are
all covered nicely in your guide.
I had to look up how admin panels should work (# block adminpanel, etc.)
in another example template, but that seems OK.


A small CSS quirk: When the "wiki expander" is set to "narrow", the
title underline of e.g. `[[TicketQuery?]]` strangely overlaps the content.

(BTW why are all the titles red now? I rather liked that red indicated
"link".)


Peter

Christian Boos

unread,
Jan 15, 2017, 5:44:43 PM1/15/17
to trac...@googlegroups.com
Hello Peter,

Thanks for persisting ;-)

On 1/15/2017 9:21 PM, Peter Suter wrote:
> On 14.01.2017 23:22, Peter Suter wrote:
>> On 14.01.2017 20:40, Christian Boos wrote:
>>> Also, what would be great is if you (or anyone else for that matter)
>>> could try to convert some plugins templates to Jinja2. That way, you
>>> could tell me what is not clear in the migration guide, or simply still
>>> missing from it.
>> Everything seems to work now. Maybe I'll try another one later.
> Not quite everything. Apparently I need to add
> `${jmacros.form_token_input()}` to every <form method="post">.
> This is described here:
> https://trac.edgewall.org/wiki/TracDev/PortingFromGenshiToJinja#Producingthecorrectcontentdirectly
>
> Shouldn't this be moved out of the `ITemplateStreamFilter` section?

Maybe yes, the connection with the `ITemplateStreamFilter` is only
indirect: both were taking benefit of Genshi stream filters.

>
> (Also I forgot to change
> `from genshi.builder import tag, Markup`
> to
> `from trac.util.html import tag, Markup`
> since the former still works at the moment.)

Yes, the nice thing is that `from trac.util.html import tag, Markup`
works with all recent versions of Trac, so we can aggressively promote
this change!

>
> Next I converted https://trac-hacks.org/wiki/CardsPlugin
> This plugin only has one simple template, but calls `render_template()`.
> According to
> https://trac.edgewall.org/wiki/TracDev/PortingFromGenshiToJinja#Generatingcontent
>
>> When one wants to directly render a template, the Chrome component
> facilities can be used, as before:
>> {{{
>> return Chrome(self.env).render_template(
>> req, 'query_results.html', data, None, fragment=True)
>> }}}
> But actually it seems for Jinja templates one must now change this to:
> {{{
> return Chrome(self.env).render_template(
> req, 'query_results.html', data, {'fragment': True})
> }}}
> no?

Right, forgot to update that one. The trac.web.chrome API changed
recently during the preparation for the merge.

> I also converted these three:
> https://trac-hacks.org/wiki/PullRequestsPlugin
> https://trac-hacks.org/wiki/MailArchivePlugin
> https://trac-hacks.org/wiki/TimeTrackingPlugin
> which needed also <xi:include />, # if, # with, # block head which are
> all covered nicely in your guide.
> I had to look up how admin panels should work (# block adminpanel, etc.)
> in another example template, but that seems OK.

I'll have a look and see if I can give some hints for some improvements.
One thing I've seen in the example you posted in your previous mail was
that you wrote plenty of `${x['key']}`. You can use the more compact
`${x.key}`, this will work as well
(http://jinja.pocoo.org/docs/2.9/templates/#variables).

Also, if some of your plugins are localized, you can now also play with
that part, I've finalized the l10n support just now.

See for the jinja2-trunk-r15341 branch:

- [3dd429ae/cboos.git] (#12639): rework the l10n support for Jinja2

(https://trac.edgewall.org/changeset/3dd429ae/cboos.git)


And the proof of concept with a new branch for the SpamFilter:

- [15351] (#12639) Apply basic Jinja2 compatibility patch.
- [15352] SpamFilter (jinja2): add support for l10n with Jinja2
- [15353] SpamFilter (jinja2): convert one template

(https://trac.edgewall.org/log/plugins/trunk/spam-filter-jinja2)


> A small CSS quirk: When the "wiki expander" is set to "narrow", the
> title underline of e.g. `[[TicketQuery?]]` strangely overlaps the content.

I'll check that, but yes, I'm probably not done with tweaking this.

> (BTW why are all the titles red now? I rather liked that red indicated
> "link".)

Well, just because the Trac logo is red, and we have red already for
links, so it mixes well ;-) But I'm open to changing that. I'll
experiment with a darker red.

-- Christian

RjOllos

unread,
Jan 17, 2017, 9:44:59 PM1/17/17
to Trac Development


On Thursday, January 12, 2017 at 8:31:44 AM UTC-8, cboos wrote:
One more possible minor quirk: the level 3 headings from the TracIni macro extend outside the #wikipage div:

- Ryan 

RjOllos

unread,
Jan 20, 2017, 9:42:36 PM1/20/17
to Trac Development
I like the border around the h3 when linking to a comment. I noticed two things:

1. The Reply button overlaps the border of the h3 (1).
2. Some padding between the border and "Description" would look nicer (2).

RjOllos

unread,
Jan 21, 2017, 3:27:19 AM1/21/17
to Trac Development
Through inspecting the errors in the logs, I stumbled across an issue. The log for /trunk/setup_wininst.bmp renders fine in 1.3.1 (1), but raises a ValueError in the testing instance (2).

- Ryan

(1) https://trac.edgewall.org/demo-1.3.1/log/trunk/setup_wininst.bmp?format=changelog&rev=1017&limit=100&mode=stop_on_copy
(2) https://trac.edgewall.org/testing/log/trunk/setup_wininst.bmp?format=changelog&rev=1017&limit=100&mode=stop_on_copy

RjOllos

unread,
Jan 27, 2017, 7:15:03 AM1/27/17
to Trac Development
Another traceback seen in the logs, unsure if it's related to the "ValueError: Can't send unicode content" issue:

2017-01-26 09:57:35,825 Trac[main] ERROR: Internal Server Error: <RequestWithSession "GET '/roadmap?format=ics'">, referrer None
Traceback (most recent call last):
  File "build/bdist.linux-x86_64/egg/trac/web/main.py", line 630, in _dispatch_request
    dispatcher.dispatch(req)
  File "build/bdist.linux-x86_64/egg/trac/web/main.py", line 252, in dispatch
    resp = chosen_handler.process_request(req)
  File "build/bdist.linux-x86_64/egg/trac/ticket/roadmap.py", line 511, in process_request
    self._render_ics(req, milestones)
  File "build/bdist.linux-x86_64/egg/trac/ticket/roadmap.py", line 598, in _render_ics
    self.env.project_name + ' - ' + _("Roadmap"))
  File "build/bdist.linux-x86_64/egg/trac/ticket/roadmap.py", line 578, in write_prop
    buf.write(text[:75] + CRLF)
TypeError: 'unicode' does not have the buffer interface 

- Ryan


Christian Boos

unread,
Jan 27, 2017, 7:39:03 AM1/27/17
to trac...@googlegroups.com
On 1/27/2017 1:15 PM, RjOllos wrote:
>
>
> On Saturday, January 21, 2017 at 12:27:19 AM UTC-8, RjOllos wrote:
>
> Through inspecting the errors in the logs, I stumbled across an
> issue. The log for /trunk/setup_wininst.bmp renders fine in 1.3.1
> (1), but raises a ValueError in the testing instance (2).
>
> - Ryan
>
> (1)
> https://trac.edgewall.org/demo-1.3.1/log/trunk/setup_wininst.bmp?format=changelog&rev=1017&limit=100&mode=stop_on_copy
> <https://trac.edgewall.org/demo-1.3.1/log/trunk/setup_wininst.bmp?format=changelog&rev=1017&limit=100&mode=stop_on_copy>
> (2)
> https://trac.edgewall.org/testing/log/trunk/setup_wininst.bmp?format=changelog&rev=1017&limit=100&mode=stop_on_copy
> <https://www.google.com/url?q=https%3A%2F%2Ftrac.edgewall.org%2Ftesting%2Flog%2Ftrunk%2Fsetup_wininst.bmp%3Fformat%3Dchangelog%26rev%3D1017%26limit%3D100%26mode%3Dstop_on_copy&sa=D&sntz=1&usg=AFQjCNEJE4VgpkfesQbWv3Ojj3oGPf9BTw>
>
>
> Another traceback seen in the logs, unsure if it's related to the
> "ValueError: Can't send unicode content" issue:
>
> 2017-01-26 09:57:35,825 Trac[main] ERROR: Internal Server Error:
> <RequestWithSession "GET '/roadmap?format=ics'">, referrer None
> Traceback (most recent call last):
> File "build/bdist.linux-x86_64/egg/trac/web/main.py", line 630, in
> _dispatch_request
> dispatcher.dispatch(req)
> File "build/bdist.linux-x86_64/egg/trac/web/main.py", line 252, in
> dispatch
> resp = chosen_handler.process_request(req)
> File "build/bdist.linux-x86_64/egg/trac/ticket/roadmap.py", line 511,
> in process_request
> self._render_ics(req, milestones)
> File "build/bdist.linux-x86_64/egg/trac/ticket/roadmap.py", line 598,
> in _render_ics
> self.env.project_name + ' - ' + _("Roadmap"))
> File "build/bdist.linux-x86_64/egg/trac/ticket/roadmap.py", line 578,
> in write_prop
> buf.write(text[:75] + CRLF)
> TypeError: 'unicode' does not have the buffer interface
>

No, it's not, plain trunk has it as well:

https://trac.edgewall.org/demo-1.3/roadmap?format=ics


The issue with /trunk/setup_wininst.bmp should be fixed in latest
rebase of the jinja2 branch (jinja2-trunk-r15379), but I didn't have
time to refresh +testing yet.

-- Christian

RjOllos

unread,
Feb 7, 2017, 10:45:07 AM2/7/17
to Trac Development
Here's a traceback from the demo server logs:

2017-02-06 09:17:24,987 Trac[main] ERROR: [85.115.16.62] Internal Server Error: <RequestWithSession "GET '/changeset/022a729ef43190cdf3ae00663c5e24df41d2b328/cboos.git?annotate=%2Ftrac%2Fhtdocs%2Fcss%2Ftrac.css'">, referrer 'https://trac.edgewall.org/testing/browser/cboos.git/trac/htdocs/css/trac.css?annotate=blame'
Traceback (most recent call last):
  File "build/bdist.linux-x86_64/egg/trac/web/main.py", line 630, in _dispatch_request
    dispatcher.dispatch(req)
  File "build/bdist.linux-x86_64/egg/trac/web/main.py", line 252, in dispatch
    resp = chosen_handler.process_request(req)
  File "build/bdist.linux-x86_64/egg/trac/versioncontrol/web_ui/changeset.py", line 349, in process_request
    self._render_html(req, repos, chgset, restricted, data)
  File "build/bdist.linux-x86_64/egg/trac/versioncontrol/web_ui/changeset.py", line 666, in _render_html
    req, 'changeset_content.html', data)
  File "build/bdist.linux-x86_64/egg/trac/web/chrome.py", line 1485, in generate_fragment
    return self.generate_template_stream(template, data, text)
  File "build/bdist.linux-x86_64/egg/trac/web/chrome.py", line 1571, in generate_template_stream
    bytes = template.render(data).encode('utf-8')
  File "/usr/local/virtualenv/src/trac-testing/.eggs/Jinja2-2.9.4-py2.7.egg/jinja2/environment.py", line 1008, in render
    return self.environment.handle_exception(exc_info, True)
  File "/usr/local/virtualenv/src/trac-testing/.eggs/Jinja2-2.9.4-py2.7.egg/jinja2/environment.py", line 780, in handle_exception
    reraise(exc_type, exc_value, tb)
  File "/tmp/.eggs-testing/Trac-1.3.2.dev0-py2.7.egg-tmp/trac/versioncontrol/templates/changeset_content.html", line 309, in top-level template code
    # call(note, page) jmacros.wikihelp('TracChangeset'):
  File "/usr/local/virtualenv/src/trac-testing/.eggs/Jinja2-2.9.4-py2.7.egg/jinja2/environment.py", line 430, in getattr
    return getattr(obj, attribute)
UndefinedError: 'jmacros' is undefined

- Ryan

Christian Boos

unread,
Feb 7, 2017, 12:33:15 PM2/7/17
to trac...@googlegroups.com
On 2/7/2017 4:45 PM, RjOllos wrote:
> Here's a traceback from the demo server logs:
>
> ...
> "/tmp/.eggs-testing/Trac-1.3.2.dev0-py2.7.egg-tmp/trac/versioncontrol/templates/changeset_content.html",
> line 309, in top-level template code
> # call(note, page) jmacros.wikihelp('TracChangeset'):
> File
> "/usr/local/virtualenv/src/trac-testing/.eggs/Jinja2-2.9.4-py2.7.egg/jinja2/environment.py",
> line 430, in getattr
> return getattr(obj, attribute)
> UndefinedError: 'jmacros' is undefined
>
>

This was already fixed in r15500. I updated /demo-1.3 to latest trunk
(r15506).

-- Christian

Reply all
Reply to author
Forward
0 new messages