On Sun, 2016-10-23 at 12:58 +0200, Markus Heiser wrote: > If you don't want to see a warning log, we have to consider > a solution like Johannes Berg posted here: > > https://www.mail-archive.com/linux-doc@xxxxxxxxxxxxxxx/msg07071.html > > @johannes: since this thread and our "sequence diagrams" thread > addressing the same questions (how should we handle dependencies from > extensions) I propose to continue the discussion here in this thread > with Jon. Sure. As I said before, regarding the annoying "while (build fails)" loop mentioned above - I think that's actually somewhat *better* than just (silently?) failing the build because some dependency wasn't there. Perhaps, with my code suitably adjusted (should be easy), we could provide some kind of command line option like "DISABLE_PLUGINS=xyz" so you could just build as though you had no plugins installed, to avoid all the follow-up errors. (We'd implement this by changing my dummy code to also pass the import statement, like this: setup = create_setup("sphinxcontrib.plantuml", ["uml"]) and moving the try/except clause into the dummy, and then that can read the environment variable easily and avoid even trying to import when it's set - that way, no dependencies can be needed. > Further I think we should not generate more (and more) external > requirements like e.g. plantuml, Java or reportlab discussed here: I still disagree, I think we should make it easy to "opt out" for the build, but if we're really serious about writing good documentation we shouldn't (artificially) limit the tools available. Sure, we probably shouldn't add seqdiag, plantuml, and others that all the do the same thing - if only for the sake of consistency in the generated output! - but having the ability to have such things is very nice and helpful for documentation. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
