Dropping python 2.7 support in gtk-doc (requiring python 3.X)

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Dropping python 2.7 support in gtk-doc (requiring python 3.X)

Stefan Sauer-4
Hi,

Having support for both python 2.7 and python 3.X in gtk-doc makes the
code ugly and is beyond what I can test. I am considering to require
python >=3.4 für the next gtk-doc release. Would that be a problem for
anyone?

To also give some extra motivation - Since a few month I am working on
gtkdoc-mkhtml which is a pure python drop-in replacement for
gtkdoc-mkhtml+gtkdoc-fixxref. This is not using docbook xslt anymore and
it won't shell out to tools to do syntax highlighting. This new tool
would need some changes to work with python 2.7 too.

I'll write more about gtkdoc-mkhtml2 soon, especially how you can test
this with your modules, but if you have questions please ask (on
gtk-doc-list@ or in #gtkdoc in irc).

Stefan


_______________________________________________
gtk-doc-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-doc-list
Reply | Threaded
Open this post in threaded view
|

Re: Dropping python 2.7 support in gtk-doc (requiring python 3.X)

Philip Withnall-2
On Fri, 2018-03-30 at 13:24 +0200, Stefan Sauer wrote:

> To also give some extra motivation - Since a few month I am working
> on
> gtkdoc-mkhtml which is a pure python drop-in replacement for
> gtkdoc-mkhtml+gtkdoc-fixxref. This is not using docbook xslt anymore
> and
> it won't shell out to tools to do syntax highlighting. This new tool
> would need some changes to work with python 2.7 too.
>
> I'll write more about gtkdoc-mkhtml2 soon, especially how you can
> test
> this with your modules, but if you have questions please ask (on
> gtk-doc-list@ or in #gtkdoc in irc).
I don’t have any questions; I just want to say that this sounds
fantastic!

Philip
_______________________________________________
gtk-doc-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-doc-list

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Dropping python 2.7 support in gtk-doc (requiring python 3.X)

David Nečas (Yeti)-2
In reply to this post by Stefan Sauer-4
On Fri, Mar 30, 2018 at 01:24:06PM +0200, Stefan Sauer wrote:
> To also give some extra motivation - Since a few month I am working on
> gtkdoc-mkhtml which is a pure python drop-in replacement for
> gtkdoc-mkhtml+gtkdoc-fixxref. This is not using docbook xslt anymore and
> it won't shell out to tools to do syntax highlighting.

Will the possibility to use docbook xslt disappear?  Or will the new
tool somehow emulate it completely?  What will happen to ‘content files’
written in docbook?

I do not understand.

Yeti

_______________________________________________
gtk-doc-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-doc-list
Reply | Threaded
Open this post in threaded view
|

Re: Dropping python 2.7 support in gtk-doc (requiring python 3.X)

Stefan Sauer-4
On 03/30/2018 02:28 PM, David Nečas wrote:
> On Fri, Mar 30, 2018 at 01:24:06PM +0200, Stefan Sauer wrote:
>> To also give some extra motivation - Since a few month I am working on
>> gtkdoc-mkhtml which is a pure python drop-in replacement for
>> gtkdoc-mkhtml+gtkdoc-fixxref. This is not using docbook xslt anymore and
>> it won't shell out to tools to do syntax highlighting.
> Will the possibility to use docbook xslt disappear?  Or will the new
> tool somehow emulate it completely?  What will happen to ‘content files’
> written in docbook?
My plan is to make it a configure option (like we had 'no-tmpl'
previously). This way people can select which toolchain they prefer.
Let me go through why I started to work on this:
* https://bugzilla.gnome.org/show_bug.cgi?id=785139 - I've reported this
upstream (docbook xslt) and there is nothing happening
* the docbook xslt is slow and it is unlikely that either the
stylesheets nor libsxlt will get dramatically faster. For the later it
is unlikely that it will ever using multiple threads.
* the dependencies don't make the tool very portable
(https://bugzilla.gnome.org/show_bug.cgi?id=788911)

The new tool mkhtml2 reads docbook files and converts them to html (this
includes any xml that is part of it, that is also 'content files'). I
also creates the devhelp2 files. There is no more need for fixxref as it
uses the fixxref module to read the dependent devehelp files to resolve
the links. The syntax highlighting is doe though pygments and I am
tempted to also do this in fixxref (so no more shelling out to vim or
source-highlight).

The new tool is not feature complete yet and to be honest it won't to
100% doing the same as the docbook xslt toolchain. E.g. I won't output a
version footer since e.g. distros complained that this makes packages
less deterministic. On the other hand so far the output looks almost
identical and as long as there is a easy rendering, we can add support
for more tags. The tool will log warnings for unsupported tags and I am
still working on adding more coverage. I am close to test this with
various gnome libraries to see what is most often missing.

The good news is that the tool is ~4 times faster and there is potential
to make it even faster.
> I do not understand.

I hope this clarifies. I am grateful for the patches you wrote on the
perl codebase. I am sorry if there where issues with the new releaes for
your project. Please let me know if you have concerns here.

Happy Easter,
Stefan
>
> Yeti
>
> _______________________________________________
> gtk-doc-list mailing list
> [hidden email]
> https://mail.gnome.org/mailman/listinfo/gtk-doc-list



_______________________________________________
gtk-doc-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-doc-list