[openstack-dev] Following the new PTI for document build, broken local builds
Monty Taylor
mordred at inaugust.com
Fri Mar 23 13:03:22 UTC 2018
On 03/22/2018 05:43 AM, Stephen Finucane wrote:
> On Wed, 2018-03-21 at 09:57 -0500, Sean McGinnis wrote:
>> On Wed, Mar 21, 2018 at 10:49:02AM +0000, Stephen Finucane wrote:
>>> tl;dr: Make sure you stop using pbr's autodoc feature before converting
>>> them to the new PTI for docs.
>>>
>>> [snip]
>>>
>>> I've gone through and proposed a couple of reverts to fix projects
>>> we've already broken. However, going forward, there are two things
>>> people should do to prevent issues like this popping up.
>>
>> Unfortunately this will not work to just revert the changes. That may fix
>> things locally, but they will not pass in gate by going back to the old way.
>>
>> Any cases of this will have to actually be updated to not use the unsupported
>> pieces you point out. But the doc builds will still need to be done the way
>> they are now, as that is what the PTI requires at this point.
>
> That's unfortunate. What we really need is a migration path from the
> 'pbr' way of doing things to something else. I see three possible
> avenues at this point in time:
>
> 1. Start using 'sphinx.ext.autosummary'. Apparently this can do similar
> things to 'sphinx-apidoc' but it takes the form of an extension.
> From my brief experiments, the output generated from this is
> radically different and far less comprehensive than what 'sphinx-
> apidoc' generates. However, it supports templating so we could
> probably configure this somehow and add our own special directive
> somewhere like 'openstackdocstheme'
> 2. Push for the 'sphinx.ext.apidoc' extension I proposed some time back
> against upstream Sphinx [1]. This essentially does what the PBR
> extension does but moves configuration into 'conf.py'. However, this
> is currently held up as I can't adequately explain the differences
> between this and 'sphinx.ext.autosummary' (there's definite overlap
> but I don't understand 'autosummary' well enough to compare them).
> 3. Modify the upstream jobs that detect the pbr integration and have
> them run 'sphinx-apidoc' before 'sphinx-build'. This is the least
> technically appealing approach as it still leaves us unable to build
> stuff locally and adds yet more "magic" to the gate, but it does let
> us progress.
I'd suggest a #4:
Take the sphinx.ext.apidoc extension and make it a standalone extension
people can add to doc/requirements.txt and conf.py. That way we don't
have to convince the sphinx folks to land it.
I'd been thinking for a while "we should just write a sphinx extension
with the pbr logic in it" - but hadn't gotten around to doing anything
about it. If you've already written that extension - I think we're in
potentially great shape!
> Try as I may, I don't really have the bandwidth to work on this for
> another few weeks so I'd appreciate help from anyone with sufficient
> Sphinx-fu to come up with a long-term solution to this issue.
> Cheers,
> Stephen
>
> [1] https://github.com/sphinx-doc/sphinx/pull/4101/files
>
>>> * Firstly, you should remove the '[build_sphinx]' and '[pbr]' sections
>>> from 'setup.cfg' in any patches that aim to convert a project to use
>>> the new PTI. This will ensure the gate catches any potential
>>> issues.
>>> * In addition, if your project uses the pbr autodoc feature, you
>>> should either (a) remove these docs from your documentation tree or
>>> (b) migrate to something else like the 'sphinx.ext.autosummary'
>>> extension [5]. I aim to post instructions on the latter shortly.
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
More information about the OpenStack-dev
mailing list