Change History (12)

Please don't try to 'fix' this. This file is the yapps runtime and is by a third party.

The file xpathparser.g used to have this functionality embedded, but people were subsequently trying to blindly 'fix' the API documentation in the generated xpathparser.py file, making it a nightmare to maintain. So that is why we now include the official yapps runtime.

Could we maybe exclude yappsrt.py from pydoctor API generation and leave the file as-is?

So pydoctor now (in SVN head) avoids that module, but the offending docstring still turns up as the docstring of twisted.words.xish.xpathparser.XPathParser.init, so this alone won't fix the buildbot, so there's still a code change needed for this (adding a docstring to the previously mentioned method). Or I guess pydoctor could not consider docstrings of objects that are excluded but I'm not that keen on that idea.

Seeing that #2502 has been reversed because of this, I'm not sure if packaging the Yapps runtime seperately resolves the issue. The generated twisted.words.xish.xpathparser module would still have an XPathParser.__init__ that inherits from the Yapps runtime and generate non-epydoc docstrings.

Maybe we need a script that calls the yapps compiler and applies the needed local fixes (import and the docstring) for generating xpathparser.py to resolve the issue.

I understand the suggestion of depending on a yapps runtime package, but I notice that there are platforms (e.g. FreeBSD) that don't provide yapps or the yapps runtime as a package (yet).

Distributing it with Twisted but outside twisted should address the issue of platforms which don't package it. If pydoctor still has a problem because the generated subclass inherits the non-parsing docstring, I'm not sure what to do about that (buildbot suggests it doesn't, though)