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 [email protected]
To unsubscribe send an email [email protected]
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/[email protected]
Do not reply to spam, report
it:https://pagure.io/fedora-infrastructure/new_issue
_______________________________________________
ruby-sig mailing list [email protected]
To unsubscribe send an email [email protected]
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/[email protected]
Do not reply to spam, report
it:https://pagure.io/fedora-infrastructure/new_issue
_______________________________________________
ruby-sig mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue