Hi everybody,
Looking at omniauth PR [1], I just realized that on a lot of places, we remove references to SimpleCov, Coveralls, Bundler and probably others to cut down the dependencies. What if we shipped in rubygems-devel some fake libraries, which would try to load the original library, but silently provided the miminum mock to make the test suite pass without the library?
E.g. for rubygem-omniauth and Coveralls, we would have:
~~~ $ cat /usr/share/ruby/vendor_ruby/coveralls.rb begin gem 'coveralls' require 'coveralls' rescue LoadError puts '!!! Mocking Coveralls !!!' class Coveralls end end ~~~
This is just an idea. I have not tested it. WDYT?
Vít
[1] https://src.fedoraproject.org/rpms/rubygem-omniauth/pull-request/1
[2] https://src.fedoraproject.org/rpms/rubygem-omniauth/blob/master/f/rubygem-om...
I agree the intent to create fake libraries for SimpleCov, Coveralls and Bundler. It makes each rubygem package easy and clean. That's good.
But ruby-devel is used for the use case to build the rubygem that has a C extension, with ruby.h I think that ruby-devel's "devel" means user's development, not packager's development If we add the fake libraries, users are confused to refer the fake libraries.
I assume that the fake libraries are used for the use case of our rpm packaging development only.
I would prefer to create new ruby's sub RPM package or separated RPM package such as * "ruby-packagers-utils": inspired from scl-utils or * "ruby-packagers-devel" or * "ruby-packagers-fake-libs" or etc
Then each rubygem-foo.spec use like this if it is necessary.
rubygem-foo.spec
``` BuildRequires: ruby-packagers-utils ```
+1 for not confusing users with libraries that do not work as expected.
Jun Aruga wrote on 5/9/19 1:17 PM:
I agree the intent to create fake libraries for SimpleCov, Coveralls and Bundler. It makes each rubygem package easy and clean. That's good.
But ruby-devel is used for the use case to build the rubygem that has a C extension, with ruby.h I think that ruby-devel's "devel" means user's development, not packager's development If we add the fake libraries, users are confused to refer the fake libraries.
I assume that the fake libraries are used for the use case of our rpm packaging development only.
I would prefer to create new ruby's sub RPM package or separated RPM package such as
- "ruby-packagers-utils": inspired from scl-utils
or
- "ruby-packagers-devel"
or
- "ruby-packagers-fake-libs"
or etc
Then each rubygem-foo.spec use like this if it is necessary.
rubygem-foo.spec
BuildRequires: ruby-packagers-utils
What if we shipped in rubygems-devel some
fake libraries, which would try to load the original library, but silently provided the miminum mock to make the test suite pass without the library?
You mentioned about including the logic in "rubygems-devel" RPM. I misunderstood you mentioned about "ruby-devel".
rubygems-devel package includes below files, that have macros for rubygems RPM packaging.
When a user install current rubygems-devel, that is not still harmful, that's not confusing a user. But after including the fake libraries in it, if user install the rubygems-devel by mistake, it is harmful.
ruby.spec
``` %files -n rubygems-devel %{_rpmconfigdir}/macros.d/macros.rubygems %{_rpmconfigdir}/fileattrs/rubygems.attr %{_rpmconfigdir}/rubygems.req %{_rpmconfigdir}/rubygems.prov %{_rpmconfigdir}/rubygems.con ```
----- Original Message -----
From: "Jun Aruga" jaruga@redhat.com To: "Ruby SIG mailing list" ruby-sig@lists.fedoraproject.org Sent: Thursday, May 9, 2019 3:23:33 PM Subject: Re: Fake libraries for gem builds?
What if we shipped in rubygems-devel some
fake libraries, which would try to load the original library, but silently provided the miminum mock to make the test suite pass without the library?
You mentioned about including the logic in "rubygems-devel" RPM. I misunderstood you mentioned about "ruby-devel".
rubygems-devel package includes below files, that have macros for rubygems RPM packaging.
When a user install current rubygems-devel, that is not still harmful, that's not confusing a user. But after including the fake libraries in it, if user install the rubygems-devel by mistake, it is harmful.
I do not see any harm done by skipping code coverage(with rubygems-devel package installed and the code coverage gem not). IMHO in most cases, bundler(or other dependency solution) will install the dependencies for you, when you work on that project and it will load fine. rubygems-devel is a platform-dependent package after all and users should not have it installed by mistake.
Additionally I'd include a message like "Code coverage skipped, please install #{coverage_library} to enable it.".
Overall it's a good solution for me.
ruby.spec
%files -n rubygems-devel %{_rpmconfigdir}/macros.d/macros.rubygems %{_rpmconfigdir}/fileattrs/rubygems.attr %{_rpmconfigdir}/rubygems.req %{_rpmconfigdir}/rubygems.prov %{_rpmconfigdir}/rubygems.con
-- Jun Aruga / He - His - Him
----- Original Message -----
From: "Pavel Valena" pvalena@redhat.com To: "Ruby SIG mailing list" ruby-sig@lists.fedoraproject.org Sent: Thursday, May 9, 2019 4:33:19 PM Subject: Re: Fake libraries for gem builds?
----- Original Message -----
From: "Jun Aruga" jaruga@redhat.com To: "Ruby SIG mailing list" ruby-sig@lists.fedoraproject.org Sent: Thursday, May 9, 2019 3:23:33 PM Subject: Re: Fake libraries for gem builds?
What if we shipped in rubygems-devel some
fake libraries, which would try to load the original library, but silently provided the miminum mock to make the test suite pass without the library?
You mentioned about including the logic in "rubygems-devel" RPM. I misunderstood you mentioned about "ruby-devel".
rubygems-devel package includes below files, that have macros for rubygems RPM packaging.
When a user install current rubygems-devel, that is not still harmful, that's not confusing a user. But after including the fake libraries in it, if user install the rubygems-devel by mistake, it is harmful.
I do not see any harm done by skipping code coverage(with rubygems-devel package installed and the code coverage gem not). IMHO in most cases, bundler(or other dependency solution) will install the dependencies for you, when you work on that project and it will load fine. rubygems-devel is a platform-dependent package after all and users should not have it installed by mistake.
Additionally I'd include a message like "Code coverage skipped, please install #{coverage_library} to enable it.".
Overall it's a good solution for me.
I'd add also Pry gem to this list. Pavel
ruby.spec
%files -n rubygems-devel %{_rpmconfigdir}/macros.d/macros.rubygems %{_rpmconfigdir}/fileattrs/rubygems.attr %{_rpmconfigdir}/rubygems.req %{_rpmconfigdir}/rubygems.prov %{_rpmconfigdir}/rubygems.con
-- Jun Aruga / He - His - Him
-- Pavel Valena Software Engineer, Red Hat Brno, Czech Republic
+1 to do this with something like "ruby-packagers-utils"
Providing simple mocks would make packaging easier but could very easily mess up the environment at times especially if I install ruby-devel to build native gems that I download with the gem tool even though we only need (and probably even want it) only in the packaging (mock) environment.
On 09/05/2019 12:17, Jun Aruga wrote:
I agree the intent to create fake libraries for SimpleCov, Coveralls and Bundler. It makes each rubygem package easy and clean. That's good.
But ruby-devel is used for the use case to build the rubygem that has a C extension, with ruby.h I think that ruby-devel's "devel" means user's development, not packager's development If we add the fake libraries, users are confused to refer the fake libraries.
I assume that the fake libraries are used for the use case of our rpm packaging development only.
I would prefer to create new ruby's sub RPM package or separated RPM package such as
- "ruby-packagers-utils": inspired from scl-utils
or
- "ruby-packagers-devel"
or
- "ruby-packagers-fake-libs"
or etc
Then each rubygem-foo.spec use like this if it is necessary.
rubygem-foo.spec
BuildRequires: ruby-packagers-utils
ruby-sig@lists.fedoraproject.org