Edgewall Software
Modify

Opened 14 years ago

Closed 14 years ago

Last modified 14 years ago

#4568 closed defect (fixed)

Graphviz: AttributeError: 'Formatter' object has no attribute 'base_url'

Reported by: acarr Owned by: Jonas Borgström
Priority: normal Milestone: 0.11
Component: wiki system Version: devel
Severity: normal Keywords: graphviz macros
Cc: Branch:
Release Notes:
API Changes:
Internal Changes:

Description

General Description

I had an existing site, running an early 0.11dev, (October 10th ish, 2006) version of trac on a locally compiled python stack, on Redhat AS3. For other reasons (packages are your friends), we chose to redeploy to an Ubuntu 6.10 setup.

I've got most of the site up and running, getting the various parts to cooperate again, but, graphviz pages now die with the error reported here.

The page in question had 3 graphviz macros on it, and when I remove the graphviz egg, I get the error that it doesn't know how to interpret "{ { {#!graphviz … } } }" stuff, which seems like a reasonable error.

I'm presently running r4608, and I grabbed the current copy of graphviz, too (r1887).

I tried uncommenting the hack in graphviz.py, line 90ish, which has been reported to make it work, but it doesn't.

My present workaround is going to be text file attachments, and include pictures as pictures in the page.

How to Reproduce

While doing a GET operation on /wiki/General System Design, Trac issued an internal error.

The error is reliably caused by having a graphviz element in the page, when the graphviz plugin is installed and enabled.

System Information

Trac 0.11dev
[GCC 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5)]
Python 2.4.4c1 (#1, Oct 11 2006, 21:48:21)
pyPgSQL 2.5.1
Genshi 0.3.6
Subversion 1.3.2

Python Traceback

Traceback (most recent call last):
  File "/usr/lib/python2.4/site-packages/trac/web/main.py", line 395, in dispatch_request
    dispatcher.dispatch(req)
  File "/usr/lib/python2.4/site-packages/trac/web/main.py", line 227, in dispatch
    content_type)
  File "/usr/lib/python2.4/site-packages/trac/web/chrome.py", line 552, in render_template
    return stream.render(method, doctype=doctype)
  File "build/bdist.linux-i686/egg/genshi/core.py", line 141, in render
  File "build/bdist.linux-i686/egg/genshi/output.py", line 203, in __call__
  File "build/bdist.linux-i686/egg/genshi/output.py", line 491, in __call__
  File "build/bdist.linux-i686/egg/genshi/output.py", line 439, in __call__
  File "build/bdist.linux-i686/egg/genshi/core.py", line 202, in _ensure
  File "build/bdist.linux-i686/egg/genshi/core.py", line 202, in _ensure
  File "/usr/lib/python2.4/site-packages/trac/web/chrome.py", line 580, in _strip_accesskeys
    for kind, data, pos in stream:
  File "build/bdist.linux-i686/egg/genshi/core.py", line 202, in _ensure
  File "/usr/lib/python2.4/site-packages/trac/web/chrome.py", line 569, in _generate
    for kind, data, pos in stream:
  File "build/bdist.linux-i686/egg/genshi/filters.py", line 147, in __call__
  File "build/bdist.linux-i686/egg/genshi/template.py", line 1149, in _match
  File "build/bdist.linux-i686/egg/genshi/filters.py", line 147, in __call__
  File "build/bdist.linux-i686/egg/genshi/template.py", line 1123, in _match
  File "build/bdist.linux-i686/egg/genshi/template.py", line 1112, in _strip
  File "build/bdist.linux-i686/egg/genshi/template.py", line 925, in _eval
  File "build/bdist.linux-i686/egg/genshi/eval.py", line 102, in evaluate
  File "/usr/share/trac/templates/wiki_view.html", line 55, in <Expression u"context.wiki_to_html(page.text)">
    ${context.wiki_to_html(page.text)}
  File "/usr/lib/python2.4/site-packages/trac/wiki/api.py", line 286, in wiki_to_html
    Formatter(self).format(wikitext, out, escape_newlines)
  File "/usr/lib/python2.4/site-packages/trac/wiki/formatter.py", line 799, in format
    self.handle_code_block(line)
  File "/usr/lib/python2.4/site-packages/trac/wiki/formatter.py", line 734, in handle_code_block
    processed = self.code_processor.process(self.code_text)
  File "/usr/lib/python2.4/site-packages/trac/wiki/formatter.py", line 118, in process
    text = self.processor(text)
  File "/usr/lib/python2.4/site-packages/trac/wiki/formatter.py", line 105, in _macro_processor
    return self.macro_provider.render_macro(self.formatter, self.name, text)
  File "build/bdist.linux-i686/egg/graphviz/graphviz.py", line 261, in render_macro
AttributeError: 'Formatter' object has no attribute 'base_url'

Attachments (0)

Change History (9)

comment:1 by Emmanuel Blot, 14 years ago

Please report errors about plugins to the plugin author.

For the Graphviz plugin, please use th:wiki:GraphvizPlugin and report this issue against the appropriate component.

Thanks.

comment:2 by Christopher Lenz, 14 years ago

Component: generalwiki
Milestone: 0.11

This is actually due to backwards-compatibility breakage caused by the changes in [4452] (WikiContext), discussed in #4139. Personally, I don't think we should breaking compatibility in that way.

in reply to:  2 comment:3 by Emmanuel Blot, 14 years ago

Replying to cmlenz:

This is actually due to backwards-compatibility breakage caused by the changes in [4452] (WikiContext), discussed in #4139. Personally, I don't think we should breaking compatibility in that way.

Slightly out of topic, but about compatibility break:
I think that when an API is changed in such a way that it could break a plugin, we could/should maintain a wiki page that documents the change, and if possible a code snippet that demonstrates how to implement the same feature with the new API. As an example: time values now need non-naive 'datetime' objects instead of integers, and this caused several plugin failures.

comment:4 by Christian Boos, 14 years ago

About the API break: as it's usually a trivial fix (replace the first req argument by a formatter one, get back req = formatter.req), I don't think it's such a big deal. Furthermore, doing so gives the opportunity to notice the change and to improve the macro itself, whereas adding another method for example (render_macro2?) would be awkward.

Of course, the ideal situation would be to have fine grained versioning for interface in the plugin architecture…

There's already a page for documenting API changes: TracDev/ApiChanges/0.11

comment:5 by moschny, 14 years ago

The fix is indeed trivial, but it has to be done for many plugins.

Even worse, it forces us to maintain two versions of those plugins (for 0.10 and for 0.11dev), as there's no clean way of adapting to the interface change at runtime.

comment:6 by Christian Boos, 14 years ago

Keywords: macros added
Resolution: fixed
Status: newclosed

Ok, by popular demand, the old API has been kept and has been reintroduced by r4621.

… for those having made the effort to adapt their macros, this means that their plugins are broken again, sorry for that. But you're already half-way: keep that formatter argument and simply rename render_macro to expand_macro.

in reply to:  6 comment:7 by Emmanuel Blot, 14 years ago

Replying to cboos:

But you're already half-way: keep that formatter argument and simply rename render_macro to expand_macro.

Maybe it's time to write a TracDev/MacroApi or something similar - if the documentation already exists, I guess links would be welcome from this new page, so that it is easy to locate the information about how to write a macro

comment:8 by moschny, 14 years ago

Also, TracDev/ApiChanges/0.11 should be updated to reflect r4621.

comment:9 by Christian Boos, 14 years ago

Thanks for the reminder! done.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain Jonas Borgström.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from Jonas Borgström to the specified user.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.