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(a)lists.fedoraproject.org
> To unsubscribe send an email toruby-sig-leave(a)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.fed...
> Do not reply to spam, report it:https://pagure.io/fedora-infrastructure/new_issue
_______________________________________________
ruby-sig mailing list --ruby-sig(a)lists.fedoraproject.org
To unsubscribe send an email toruby-sig-leave(a)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.fed...
Do not reply to spam, report it:https://pagure.io/fedora-infrastructure/new_issue