All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab@s-opensource.com>
To: Markus Heiser <markus.heiser@darmarit.de>
Cc: Daniel Vetter <daniel@ffwll.ch>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Daniel Vetter <daniel.vetter@ffwll.ch>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	Linux Doc Mailing List <linux-doc@vger.kernel.org>,
	Jonathan Corbet <corbet@lwn.net>,
	Daniel Vetter <daniel.vetter@intel.com>
Subject: Re: [PATCH 2/6] docs-rst: automatically convert Graphviz and SVG images
Date: Thu, 2 Mar 2017 16:09:21 -0300	[thread overview]
Message-ID: <20170302160921.3366847d@vento.lan> (raw)
In-Reply-To: <B8CBD363-F0C5-4BE4-84A4-49DB76D4A911@darmarit.de>

Em Thu, 2 Mar 2017 19:16:47 +0100
Markus Heiser <markus.heiser@darmarit.de> escreveu:

> > Am 02.03.2017 um 17:29 schrieb Mauro Carvalho Chehab <mchehab@s-opensource.com>:
> > 
> > Em Thu, 2 Mar 2017 17:13:25 +0100
> > Markus Heiser <markus.heiser@darmarit.de> escreveu:
> >   
> >>> Am 02.03.2017 um 16:49 schrieb Mauro Carvalho Chehab <mchehab@s-opensource.com>:
> >>>   
> >>>>> You can test it with virtualenv  https://virtualenv.pypa.io/en/stable/userguide/
> >>>>> 
> >>>>> In short:
> >>>>> 
> >>>>> $ cd kernel-src
> >>>>> $ virtualenv myenv
> >>>>> $ source myenv/bin/activate
> >>>>> $ pip install 'Sphinx==1.3.1'
> >>>>> $ make ....      
> >>>> 
> >>>> Hmm... at least here, building docs-next with Sphinx 1.3.1 inside a
> >>>> virtualenv is broken:
> >>>> 
> >>>> writing output... [ 16%] media/intro                                            
> >>>> Exception occurred:
> >>>> File "/devel/v4l/patchwork/myenv-1.3/lib/python2.7/site-packages/docutils/writers/_html_base.py", line 671, in depart_document
> >>>>   assert not self.context, 'len(context) = %s' % len(self.context)
> >>>> AssertionError: len(context) = 1
> >>>> The full traceback has been saved in /tmp/sphinx-err-W7CPtT.log, if you want to report the issue to the developers.
> >>>> Please also report this if it was a user error, so that a better error message can be provided next time.
> >>>> A bug report can be filed in the tracker at <https://github.com/sphinx-doc/sphinx/issues>. Thanks!
> >>>> Documentation/Makefile.sphinx:69: recipe for target 'htmldocs' failed
> >>>> make[1]: *** [htmldocs] Error 1
> >>>> Makefile:1450: recipe for target 'htmldocs' failed
> >>>> make: *** [htmldocs] Error 2
> >>>> 
> >>>> Perhaps it is time for us to move minimal requirements to 1.4?    
> >>> 
> >>> Hmm... the same happened with 1.4.9 inside virtualenv. It built fine
> >>> with 1.5.2 (for htmldocs).
> >>> 
> >>> Thanks,
> >>> Mauro
> >>> 
> >>> -
> >>> 
> >>> This is the error log with 1.4:
> >>> 
> >>> # Sphinx version: 1.4.9    
> >> ....  
> >>> File "/devel/v4l/patchwork/myenv-1.4/lib/python2.7/site-packages/docutils/nodes.py", line 187, in walkabout
> >>>   visitor.dispatch_departure(self)
> >>> File "/devel/v4l/patchwork/myenv-1.4/lib/python2.7/site-packages/docutils/nodes.py", line 1895, in dispatch_departure
> >>>   return method(node)
> >>> File "/devel/v4l/patchwork/myenv-1.4/lib/python2.7/site-packages/docutils/writers/_html_base.py", line 671, in depart_document
> >>>   assert not self.context, 'len(context) = %s' % len(self.context)
> >>> AssertionError: len(context) = 1    
> >> 
> >> I guess this is a error from newer docutils, so we have to fix docutils version also.
> >> 
> >> Sphinx itself specifies "docutils>=0.11"
> >> 
> >>  https://github.com/sphinx-doc/sphinx/blob/1.3.1/setup.py#L52
> >> 
> >> So I guess it uses a up to date docutils or the ducutils which are already installed system wide.  
> > 
> > The system-wide docutils is this one:
> > 
> > 	python2-docutils-0.13.1-3.fc25.noarch
> > 	python3-docutils-0.13.1-3.fc25.noarch  
> 
> Sorry my mistake, in the traceback we see
> 
> File "/devel/v4l/patchwork/myenv-1.4/lib/python2.7/site-packages/docutils/writers/_html_base.py", line 671, in depart_document
>   assert not self.context, 'len(context) = %s' % len(self.context)
> 
> ... which means: system wide installation does not matter.
> 
> > Btw, I tested also with virtualenv-3/pip3 and the same issue happens there.
> > 
> > Manually installing version 0.11 makes it to work again.  
> 
> Yes, its only about "docutils>=0.11" in Sphinx 1.3 dependencies. 
> In Sphinx 1.5 the error:
> 
>   https://github.com/sphinx-doc/sphinx/issues/3212
> 
> is fixed:
> 
>   https://github.com/tk0miya/sphinx/commit/73663f63672f22304810ce6bb9787490ad250127
> 
> But this will never be fixed downwards.

Crap. This kind of patch should be backported to Sphinx 1.3/1.4,
or Python's PIP repository should be fixed to require docutils
version to be either 0.11 or 0.12, if one installs version 1.3
or 1.4 of Sphinx.

The way it is, PIP repository is broken!

> All this is about semantic versioning. If you want to promise your
> builds, you have to name which versions of dependencies you support.
> I guess this is nothing new for kernel developers ;)

No. At the Kernel, we do everything possible to not break APIs.

If this were not the case, you wouldn't be able to run Sphinx 1.5 
with legacy Kernel versions ;-)

> The problem is, that PEP440 defines not only ONE version scheme
> 
>  """Some hard to read version identifiers are permitted by
>     this scheme in order to better accommodate the wide range
>     of versioning practices across existing public and private
>     Python projects."""
> 
> In practice, the python projects use slightly different schemes
> which not follow one rule like <main>.<compatible feature>.<patch> 
> From history packaging in Python is the hell, it becomes better, but
> the problem with slightly different version schemes still exist.

IMHO, the way Python and python libraries break compatibility is crazy.

Good packaging sense says that, if APIs can break on every single new
release (with seems to be the case of docutils), then a package
depending on such bad-developed library should require the exact
version(s) it is known to work.

When we're discussing about the docs toolchain, I mentioned that I
was afraid that the Python development model would cause this sort
of issues. Unfortunately, it seems that my concerns were pertinent :-(

> How can this info help us? Now we know, that we have to stick Sphinx
> and docutils by patch-levels we are willing to support. Or with
> your words ....
> 
> > Considering that Sphinx require a specific docutils package for it to
> > work, perhaps it is time for us to consider to use the virtenv
> > enchantments at make docs targets :-p  
> 
> 
> This is very easy, if we use a requiremts.txt file where we 
> stick the versions and run the sphinx in this build in a
> virtualenv which is build up by this requirements.txt.
> 
>   https://pip.pypa.io/en/stable/user_guide/#requirements-files
> 
> To summarize, I recommend a Makefile.sphinx cmd which does
> something like:
> 
>   virtualenv output/myenv
>   source output/myenv/bin/activate
>   pip install -r requirements.txt
>   sphinx-build ...
>   
> I guess this is something we should discuss with Jon, he
> is also familiar with it virtualenv. 

Yeah, making kernel build to depend on network can be a problem.

Maybe one way would be to have a sort of "prepare" script that
would be network-dependent, and will install whatever needed to
build the docs. If called, make *docs will use the virtualenv.
Otherwise, it would print a warning message saying that the doc
build is not reliable, but would try to use whatever installed
on the machine.

Thanks,
Mauro

  parent reply	other threads:[~2017-03-02 19:09 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-28 17:13 [PATCH 0/6] more kernel-doc patches Daniel Vetter
2017-02-28 17:13 ` [PATCH 1/6] doc: Explain light-handed markup preference a bit better Daniel Vetter
2017-02-28 17:13 ` [PATCH 2/6] docs-rst: automatically convert Graphviz and SVG images Daniel Vetter
2017-03-01 15:56   ` Gabriel Krisman Bertazi
2017-03-02  7:12     ` Daniel Vetter
2017-03-02  8:23       ` Markus Heiser
2017-03-02 12:26   ` Laurent Pinchart
2017-03-02 13:54     ` Daniel Vetter
2017-03-02 14:14       ` Laurent Pinchart
2017-03-02 14:58         ` Markus Heiser
2017-03-02 15:11           ` Daniel Vetter
2017-03-02 15:17             ` Laurent Pinchart
2017-03-02 15:21             ` Markus Heiser
2017-03-02 15:45               ` Mauro Carvalho Chehab
2017-03-02 15:49                 ` Mauro Carvalho Chehab
2017-03-02 16:13                   ` Markus Heiser
2017-03-02 16:29                     ` Mauro Carvalho Chehab
2017-03-02 18:16                       ` Markus Heiser
2017-03-02 18:20                         ` Jonathan Corbet
2017-03-02 18:47                           ` Markus Heiser
2017-03-02 19:09                         ` Mauro Carvalho Chehab [this message]
2017-03-02 20:16                           ` Markus Heiser
2017-03-02 20:28                             ` Mauro Carvalho Chehab
2017-03-04 14:56                           ` docutils borkage (was: [PATCH 2/6] docs-rst: automatically convert Graphviz and SVG images) Jonathan Corbet
2017-03-05  2:23                             ` Mauro Carvalho Chehab
2017-03-02 15:22             ` [PATCH 2/6] docs-rst: automatically convert Graphviz and SVG images Jonathan Corbet
2017-03-02 15:53               ` Daniel Vetter
2017-03-02 16:01                 ` Mauro Carvalho Chehab
2017-03-02 19:49                   ` Daniel Vetter
2017-03-06 10:12   ` Daniel Vetter
2017-03-06 13:13     ` Markus Heiser
2017-03-06 15:03       ` Daniel Vetter
2017-02-28 17:13 ` [PATCH 3/6] drm/doc: Add KMS overview graphs Daniel Vetter
2017-03-01 16:33   ` Gabriel Krisman Bertazi
2017-03-02 14:34   ` Laurent Pinchart
2017-03-02 15:06     ` Daniel Vetter
2017-02-28 17:13 ` [PATCH 4/6] drm/doc: Consistent kerneldoc include order Daniel Vetter
2017-02-28 23:39   ` Eric Anholt
2017-02-28 17:13 ` [PATCH 5/6] drm/doc: diagram for mode objects and properties Daniel Vetter
2017-02-28 23:40   ` Eric Anholt
2017-03-01  8:27   ` [PATCH] " Daniel Vetter
2017-03-01 16:45     ` Gabriel Krisman Bertazi
2017-03-02 14:42     ` Laurent Pinchart
2017-02-28 17:13 ` [PATCH 6/6] drm/doc: atomic overview, with graph Daniel Vetter
2017-02-28 23:48   ` Eric Anholt
2017-03-01  9:57     ` Daniel Vetter
2017-03-01 17:42       ` Gabriel Krisman Bertazi
2017-03-02  7:16         ` Daniel Vetter
2017-03-01  8:35   ` [PATCH] " Daniel Vetter
2017-03-01 17:42     ` Eric Anholt
2017-03-02  7:19     ` Daniel Vetter
2017-03-02 14:41       ` Laurent Pinchart
2017-03-02 15:16 [PATCH 1/6] doc: Explain light-handed markup preference a bit better Daniel Vetter
2017-03-02 15:16 ` [PATCH 2/6] docs-rst: automatically convert Graphviz and SVG images Daniel Vetter
2017-03-02 15:20   ` Laurent Pinchart
2017-03-02 22:15   ` Markus Heiser
2017-03-02 23:19     ` Mauro Carvalho Chehab

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170302160921.3366847d@vento.lan \
    --to=mchehab@s-opensource.com \
    --cc=corbet@lwn.net \
    --cc=daniel.vetter@ffwll.ch \
    --cc=daniel.vetter@intel.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=markus.heiser@darmarit.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.