From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934626AbcJXHwm (ORCPT ); Mon, 24 Oct 2016 03:52:42 -0400 Received: from s3.sipsolutions.net ([5.9.151.49]:49016 "EHLO sipsolutions.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932954AbcJXHwh (ORCPT ); Mon, 24 Oct 2016 03:52:37 -0400 Message-ID: <1477295547.4085.8.camel@sipsolutions.net> Subject: Re: The downside of math:: From: Johannes Berg To: Markus Heiser , Jonathan Corbet , Jani Nikula Cc: Mauro Carvalho Chehab , LKML Mailing List , linux-doc@vger.kernel.org Date: Mon, 24 Oct 2016 09:52:27 +0200 In-Reply-To: <3D1565DE-2513-4326-9FFC-6DF713238B51@darmarit.de> References: <20161019170246.339eff9d@lwn.net> <20161019222618.154434f3@vento.lan> <877f93qdd2.fsf@intel.com> <20161021153806.5c9b5d7b@lwn.net> <3D1565DE-2513-4326-9FFC-6DF713238B51@darmarit.de> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.20.5-1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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@vger.kernel.org/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