> I would like to urge everybody to avoid such strict version requirements, especially without any justification, as in this Prawn case.
I agree. I'm currently looking into how to run the Asciidoctor PDF test suite against a prerelease of Prawn that doesn't have this restriction. Unfortunately, because of how RubyGems works, I cannot simply declare a dependency that forces pdf-core to be upgraded to 0.8.1 because RubyGems forbids it (due to Prawn's tight restriction). But I can run the tests against a prerelease branch (master or a modified version of 2.2.2). Best Regards, -Dan On Wed, May 6, 2020 at 1:53 AM Vít Ondruch <vondr...@redhat.com> wrote: > Hi Chris, > > I think that part of the issues is that upstream is very likely using > Bundler whereas you are running the test suite without it. This has its own > set of pros and cons. > > For Fedora, the main benefit of running test suite without using Bundler > is reduced amount of dependencies. For example, to be able to use Bundler > for asciidoctor-pdf and run the test suite as upstream does, you would > probably need to package rubocop, rubocop-rspec, deep-cover-core and their > dependencies. Or you have to diverge somewhere, e.g. by tweaking Gemfile. > But this yet again means you are diverging from upstream. > > When you reach this point, I think it is the best to avoid Bundler > altogether and fix the issue with dependencies which are not according to > the upstream wishes. > > In this case, it should be ensured that Prawn works correctly with > pdf-core 0.8.1 and of course fix all stuff which depends on Prawn. Actually > it seems that Prawn is going to bump the requirement [1], but when it is > going to be released is hard to know. And it is good to learn that while > this kind of strict dependencies reduces the test matrix, they fail > somebody sooner or later. They prevent the innovation, because they are > just (temporary) hiding issues. So on this place, I would like to urge > everybody to avoid such strict version requirements, especially without any > justification, as in this Prawn case. > > </End of rant here> > > So are there other specific test cases you need help with? :) Because for > example all failures with this message: > > ~~~ > > Gem::GemNotFoundException: > can't find gem asciidoctor-pdf (>= 0) with executable asciidoctor-pdf > > ~~~ > > > Are very likely due to not using Bundler. > > > Vít > > > > [1] > https://github.com/prawnpdf/prawn/commit/c504ae4e683017d7afadece084734a9190230cd8 > > Dne 05. 05. 20 v 21:30 Dan Allen napsal(a): > > Christopher, > > I discovered the issue. Fedora uses a new version of the pdf-core gem > (0.8.1) than what prawn requests (0.7.0). There was a change introduced in > that version to truncate any float value in the PDF to an integer if the > decimal is zero. See > https://github.com/prawnpdf/pdf-core/commit/3bea761521b3483e1e81968c600b6fddf6a87863. > That's why we're seeing differences in the test results when comparing the > page dimensions. > > I'll make the change to the test suite with a note that the comparison > must not assume the numeric type. > > -Dan > > On Tue, May 5, 2020 at 9:11 AM Christopher Brown <chris.br...@redhat.com> > wrote: > >> Hi there, >> >> I have bumped the version of a package I maintain in Fedora and am seeing >> an increase in errors from the test suite run. >> >> https://kojipkgs.fedoraproject.org//work/tasks/6453/44116453/build.log >> >> I'm specifically trying to understand the errors regarding being unable >> to locate the binary and the eql errors as these form the majority. >> >> I have asked about the latter upstream a while back: >> >> https://github.com/asciidoctor/asciidoctor-pdf/issues/1542 >> >> and received comment about there possibly being a problem with rspec >> itself? >> >> Any advice appreciated. >> >> -- >> Christopher Brown >> _______________________________________________ >> ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org >> To unsubscribe send an email to ruby-sig-le...@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 >> > > > -- > Dan Allen | @mojavelinux | https://twitter.com/mojavelinux > > _______________________________________________ > ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org > To unsubscribe send an email to ruby-sig-le...@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 > > _______________________________________________ > ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org > To unsubscribe send an email to ruby-sig-le...@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 > -- Dan Allen | @mojavelinux | https://twitter.com/mojavelinux
_______________________________________________ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@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
