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

[acarr]

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'

[Emmanuel Blot]

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.

[Christopher Lenz]

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.

[Emmanuel Blot]

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.

[Christian Boos]

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

[moschny]

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.

[Christian Boos]

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.

[Emmanuel Blot]

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

[moschny]

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

[Christian Boos]

Thanks for the reminder! done.