On 10/25/22 14:46, Vít Ondruch wrote:


Dne 25. 10. 22 v 13:12 Jarek Prokop napsal(a):


The other subthread with Jarek reminded me that one of the options could be to extract/fork the whole Darkfish generator instead of monkey patching. But Darkfish is pretty complex. We would probably not avoided any issues.

Maybe it would be possible to just provide the subclass of Darkfish generator as a single file, perhaps monkey patch the JSON index while we're at it.


Sub-clasing is interesting idea. But that would mean we needed to provide our own generator.

We will either monkey patch it, requiring us to come up with an idea of how to bring the monkey patches into the default behavior or provide other generator, this seems main 2 options we are working with.

Our own generator with subclassing seems as a "purer" idea, leaving the behavior of the shipped darkfish generator intact. When executing the %gem_install macro, we might be able to invoke the custom generator outright without worrying if the monkey patches are loaded correctly.


One can provide a different template to a generator and a different generator to a template it seems from messing around with the RDoc CLI and the extracting of the Darkfish template. That leads me to believe that there is a way to do that from code. It would work kind of like this: set the Darkfish template as default, modify the behavior to use symlinks and whatnot. We wouldn't need to keep forked JS/HTML files in a new package.


Please note that my proof of concept provides symlinks.

See other email that used your PoC but combined with my approach of subclassing and completely skipping shipping the darfish template (html, js,...) files, the symlinking functionality is preserved (but requires fine tuning as to what will get symlinked).

Jarek

This would probably minimize required code to get it running.

IOW create a glue between darkfish, json index and RDoc that would make it do what we want to instead of copying it all.

We would then create a tight dependency on those template files, but we can write tests and then check for failures that would crop up via koschei.


Vít


Jarek


Vít



_______________________________________________
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

_______________________________________________
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue