Ok the title is a little bit mouthful and it contains 4 gems so I'll break it down.
I am trying to run unicorn and get GitLab to work. In unicorn's error log I see the following:
/usr/share/gems/gems/backports-3.3.2/lib/backports/tools.rb:328:in `require': cannot load such file -- regin (LoadError)
I checked the aforementioned line [0] and I found no reference to regin.
It appears that regin comes as a bundled gem of rack-mount. I checked the rack-mount.spec [2] and I saw that we ship it without the bundled regin. In an effort to see if this will work, I copied the removed vendor/ in /usr/share/gems/... and it worked.
I guess the reason is because in rack-mount/lib/rack/mount/utils.rb the path to regin is hardcoded to point in vendor/ [3].
I will file a bug report but I wouldn't know how to describe the steps to reproduce it. Any hints?
TL;DR rack-mount raises LoadError without the bundled regin.
[0] https://github.com/marcandre/backports/blob/v3.3.2/lib/backports/tools.rb#L3... [1] https://github.com/josh/rack-mount/blob/master/lib/rack/mount/utils.rb#L3 [2] http://pkgs.fedoraproject.org/cgit/rubygem-rack-mount.git/tree/rubygem-rack-... [3] https://github.com/josh/rack-mount/blob/master/lib/rack/mount/utils.rb#L4
Hi Axilleas,
I believe this is "Bundler" issue. As you can see in [1], rack-mount is trying to require any available regin prior loading the bundled regin. Without Bundler, RubyGems would find the regin gem and load it, but Bundler prohibits it. If you reference regin in your Gemfile, it should work.
There is no cure for this incompatibility. The best would be to convince rack-mount maintainers to remove the bundled regin (not sure if I have tried it or not). That would solve all these incompatibilities, since regin would be proper dependency.
Vít
Dne 8.9.2013 19:30, Axilleas Pipinellis napsal(a):
Ok the title is a little bit mouthful and it contains 4 gems so I'll break it down.
I am trying to run unicorn and get GitLab to work. In unicorn's error log I see the following:
/usr/share/gems/gems/backports-3.3.2/lib/backports/tools.rb:328:in `require': cannot load such file -- regin (LoadError)
I checked the aforementioned line [0] and I found no reference to regin.
It appears that regin comes as a bundled gem of rack-mount. I checked the rack-mount.spec [2] and I saw that we ship it without the bundled regin. In an effort to see if this will work, I copied the removed vendor/ in /usr/share/gems/... and it worked.
I guess the reason is because in rack-mount/lib/rack/mount/utils.rb the path to regin is hardcoded to point in vendor/ [3].
I will file a bug report but I wouldn't know how to describe the steps to reproduce it. Any hints?
TL;DR rack-mount raises LoadError without the bundled regin.
[0] https://github.com/marcandre/backports/blob/v3.3.2/lib/backports/tools.rb#L3... [1] https://github.com/josh/rack-mount/blob/master/lib/rack/mount/utils.rb#L3 [2] http://pkgs.fedoraproject.org/cgit/rubygem-rack-mount.git/tree/rubygem-rack-... [3] https://github.com/josh/rack-mount/blob/master/lib/rack/mount/utils.rb#L4
Hi Vit,
I am not sure that this is related but, the bundler as "built" (packaged) in Fedora has a "bug" in it. "lib/bundler/vendor" should have never been removed [1]. Well, if it was removed, someone should have modified bundler to load the thor/net-http-persistent gem via a require/relative_require. But that's not what happened.
As a matter of fact, bundler tells you NOT to use a "gem" installed version of thor [2], as that "may cause Bundler to malfunction in unexpected ways."
When I looked into this for my needs, I determined that a patch would be required to make bundler happy if the "lib/bundler/vendor" directory was removed. You'd have to modify vendored_thor.rb and vendored_persistent.rb.
Usage of many of the bundler arguments (--with/without, etc) causes errors when "lib/bundler/vendor" has been removed.
/allen
1) http://pkgs.fedoraproject.org/cgit/rubygem-bundler.git/tree/rubygem-bundler.... lines 68-69 2) https://github.com/bundler/bundler/blob/master/lib/bundler/vendored_thor.rb
-----Original Message----- From: ruby-sig-bounces@lists.fedoraproject.org [mailto:ruby-sig- bounces@lists.fedoraproject.org] On Behalf Of Vít Ondruch Sent: Tuesday, September 17, 2013 04:31 To: ruby-sig@lists.fedoraproject.org Subject: Re: regin LoadError with rack-mount and backports when trying to run unicorn
Hi Axilleas,
I believe this is "Bundler" issue. As you can see in [1], rack-mount is trying to require any available regin prior loading the bundled regin. Without Bundler, RubyGems would find the regin gem and load it, but Bundler prohibits it. If you reference regin in your Gemfile, it should work.
There is no cure for this incompatibility. The best would be to convince rack-mount maintainers to remove the bundled regin (not sure if I have tried it or not). That would solve all these incompatibilities, since regin would be proper dependency.
Vít
Dne 8.9.2013 19:30, Axilleas Pipinellis napsal(a):
Ok the title is a little bit mouthful and it contains 4 gems so I'll break it down.
I am trying to run unicorn and get GitLab to work. In unicorn's error log I see the following:
/usr/share/gems/gems/backports-3.3.2/lib/backports/tools.rb:328:in `require': cannot load such file -- regin (LoadError)
I checked the aforementioned line [0] and I found no reference to
regin.
It appears that regin comes as a bundled gem of rack-mount. I checked the rack-mount.spec [2] and I saw that we ship it without the bundled regin. In an effort to see if this will work, I copied the removed vendor/ in /usr/share/gems/... and it worked.
I guess the reason is because in rack-mount/lib/rack/mount/utils.rb the path to regin is hardcoded to point in vendor/ [3].
I will file a bug report but I wouldn't know how to describe the
steps
to reproduce it. Any hints?
TL;DR rack-mount raises LoadError without the bundled regin.
[0]
https://github.com/marcandre/backports/blob/v3.3.2/lib/backports/tools. rb#L328
mount/blob/master/lib/rack/mount/utils.rb#L3
mount.git/tree/rubygem-rack-mount.spec#n14
mount/blob/master/lib/rack/mount/utils.rb#L4
ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
________________________________
Disclaimer Confidentiality Notice: This e-mail, and any attachments and/or documents linked to this email, are intended for the addressee and may contain information that is privileged, confidential, proprietary, or otherwise protected by law. Any dissemination, distribution, or copying is prohibited. This notice serves as a confidentiality marking for the purpose of any confidentiality or nondisclosure agreement. If you have received this communication in error, please contact the original sender.
Dne 18.9.2013 19:26, Allen Hewes napsal(a):
Hi Vit,
I am not sure that this is related but, the bundler as "built" (packaged) in Fedora has a "bug" in it. "lib/bundler/vendor" should have never been removed [1].
It has to be removed due to Fedora policies.
Well, if it was removed, someone should have modified bundler to load the thor/net-http-persistent gem via a require/relative_require. But that's not what happened.
There is no way how to do it, since you don't know where to find thor/net-http-persistent on the system. If Bundler had used original RubyGems require, it would be OK, but they opted to use their custom loader. That is the biggest fail in Bundler design (if we can speak of desing, since Bundler is unfortunately just pile of workarounds).
As a matter of fact, bundler tells you NOT to use a "gem" installed version of thor [2], as that "may cause Bundler to malfunction in unexpected ways."
Yes, they opted for bundling instead of proper design. Unfortunately, Bundler upstream was never open to any of our suggestions towards better packaging and easier collaboration with distributions. They live in Ruby (MacOS X) world and they can't imagine, that somebody might use something else.
When I looked into this for my needs, I determined that a patch would be required to make bundler happy if the "lib/bundler/vendor" directory was removed. You'd have to modify vendored_thor.rb and vendored_persistent.rb.
Could you share your patch with us, please?
Usage of many of the bundler arguments (--with/without, etc) causes errors when "lib/bundler/vendor" has been removed.
Some examples? Bugzillas?
Vít
Hi Vit,
Before I reply to you, I wanted to let you know that I am grateful to you, Bohuslav, Lutterkort, Jeroen, Mamoru and Mo (and others) for all the Fedora/RH Ruby RPM/packaging. I have my own Koji cooker where I am currently building 165 packages for RHEL5 to support a suite of Rails applications and I'd be solving my problem very differently if you guys weren't around.
I only jumped in because the OP is having bundler issues and I know for a fact that bundler is broken as packaged by Fedora.
-----Original Message----- From: ruby-sig-bounces@lists.fedoraproject.org [mailto:ruby-sig- bounces@lists.fedoraproject.org] On Behalf Of Vít Ondruch Sent: Friday, September 20, 2013 7:27 AM To: ruby-sig@lists.fedoraproject.org Subject: Re: regin LoadError with rack-mount and backports when trying to run unicorn
Dne 18.9.2013 19:26, Allen Hewes napsal(a):
Hi Vit,
I am not sure that this is related but, the bundler as "built"
(packaged) in Fedora has a "bug" in it. "lib/bundler/vendor" should have never been removed [1].
It has to be removed due to Fedora policies.
I understand the polices here. I really do. But when policies produce a broken package, wouldn't a better decision be to NOT produce that package? Since it shows up in a yum command, probably everyone thinks that package is sane and works as expected, at least I did. I can't speak for the OP.
Well, if it was removed, someone should have modified bundler to load
the thor/net-http-persistent gem via a require/relative_require. But that's not what happened.
There is no way how to do it, since you don't know where to find thor/net-http-persistent on the system. If Bundler had used original RubyGems require, it would be OK, but they opted to use their custom loader. That is the biggest fail in Bundler design (if we can speak of desing, since Bundler is unfortunately just pile of workarounds).
I toyed with producing RPMs like rubygem-bundler-thor / rubygem-bundler-net-http-persistent and modifying the vendored_persistent.rb/vendored_thor.rb files. I was thinking of satisfying Fedora's policies so that I could give my work to Fedora. I never took this past thinking about it.
I also toyed (made local changes to bundler) with changing bundler to load them ala require/relative_require but arrived at the same place you describe; the bundler guys are doing their level best to make a mess out of $./$LOAD_PATH. That combined with their rubygems "emulation", I gave up and just decided to produce my own version of rubygem-bundler that didn't wipe out "lib/bundler/vendor". After a few days, I gave up on this idea. I MUST have a working bundler.
Also, you won't hear me talking up bundler. I can't stand the darn thing and it's not a very good solution to a hard problem. Plainly, I hate it. The problem bundler solves should be solved in rubygems or a rubygems plugin.
I can't deploy my rails applications WITHOUT bundler.
As a matter of fact, bundler tells you NOT to use a "gem" installed
version of thor [2], as that "may cause Bundler to malfunction in unexpected ways."
Yes, they opted for bundling instead of proper design. Unfortunately, Bundler upstream was never open to any of our suggestions towards better packaging and easier collaboration with distributions. They live in Ruby (MacOS X) world and they can't imagine, that somebody might use something else.
When I looked into this for my needs, I determined that a patch would
be required to make bundler happy if the "lib/bundler/vendor" directory was removed. You'd have to modify vendored_thor.rb and vendored_persistent.rb.
Could you share your patch with us, please?
I solved my issue by importing the rubygem-bundler packaging source and commenting out the removal of "lib/bundler/vendor". Like I mentioned earlier, I have my own Koji setup and I produce a yum repo "overlay" ontop of RHEL5 for my needs. So my version of rubygem-bundler does work for my needs.
Usage of many of the bundler arguments (--with/without, etc) causes
errors when "lib/bundler/vendor" has been removed.
Some examples? Bugzillas?
I created a BZ report https://bugzilla.redhat.com/show_bug.cgi?id=1010406.
Vít _______________________________________________ ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
/allen
________________________________
Disclaimer Confidentiality Notice: This e-mail, and any attachments and/or documents linked to this email, are intended for the addressee and may contain information that is privileged, confidential, proprietary, or otherwise protected by law. Any dissemination, distribution, or copying is prohibited. This notice serves as a confidentiality marking for the purpose of any confidentiality or nondisclosure agreement. If you have received this communication in error, please contact the original sender.
Hi Vit and OP,
OP my issue is, well, created (embarrassingly) by me. So you probably still have some sort of bundler issue. And I'm sorry for thread hijacking.
Vit, thanks for the help. In the BZ, Mamoru gave me some pointers and got me pointed in the right direction.
Again, sorry about the hijack and misinformation...
/allen
-----Original Message----- From: ruby-sig-bounces@lists.fedoraproject.org [mailto:ruby-sig- bounces@lists.fedoraproject.org] On Behalf Of Allen Hewes Sent: Friday, September 20, 2013 14:01 To: 'Ruby SIG mailing list' Subject: RE: regin LoadError with rack-mount and backports when trying to run unicorn
Hi Vit,
Before I reply to you, I wanted to let you know that I am grateful to you, Bohuslav, Lutterkort, Jeroen, Mamoru and Mo (and others) for all the Fedora/RH Ruby RPM/packaging. I have my own Koji cooker where I am currently building 165 packages for RHEL5 to support a suite of Rails applications and I'd be solving my problem very differently if you guys weren't around.
I only jumped in because the OP is having bundler issues and I know for a fact that bundler is broken as packaged by Fedora.
-----Original Message----- From: ruby-sig-bounces@lists.fedoraproject.org [mailto:ruby-sig- bounces@lists.fedoraproject.org] On Behalf Of Vít Ondruch Sent: Friday, September 20, 2013 7:27 AM To: ruby-sig@lists.fedoraproject.org Subject: Re: regin LoadError with rack-mount and backports when
trying
to run unicorn
Dne 18.9.2013 19:26, Allen Hewes napsal(a):
Hi Vit,
I am not sure that this is related but, the bundler as "built"
(packaged) in Fedora has a "bug" in it. "lib/bundler/vendor" should have never been removed [1].
It has to be removed due to Fedora policies.
I understand the polices here. I really do. But when policies produce a broken package, wouldn't a better decision be to NOT produce that package? Since it shows up in a yum command, probably everyone thinks that package is sane and works as expected, at least I did. I can't speak for the OP.
Well, if it was removed, someone should have modified bundler to
load
the thor/net-http-persistent gem via a require/relative_require. But that's not what happened.
There is no way how to do it, since you don't know where to find thor/net-http-persistent on the system. If Bundler had used original RubyGems require, it would be OK, but they opted to use their custom loader. That is the biggest fail in Bundler design (if we can speak
of
desing, since Bundler is unfortunately just pile of workarounds).
I toyed with producing RPMs like rubygem-bundler-thor / rubygem- bundler-net-http-persistent and modifying the vendored_persistent.rb/vendored_thor.rb files. I was thinking of satisfying Fedora's policies so that I could give my work to Fedora. I never took this past thinking about it.
I also toyed (made local changes to bundler) with changing bundler to load them ala require/relative_require but arrived at the same place you describe; the bundler guys are doing their level best to make a mess out of $./$LOAD_PATH. That combined with their rubygems "emulation", I gave up and just decided to produce my own version of rubygem-bundler that didn't wipe out "lib/bundler/vendor". After a few days, I gave up on this idea. I MUST have a working bundler.
Also, you won't hear me talking up bundler. I can't stand the darn thing and it's not a very good solution to a hard problem. Plainly, I hate it. The problem bundler solves should be solved in rubygems or a rubygems plugin.
I can't deploy my rails applications WITHOUT bundler.
As a matter of fact, bundler tells you NOT to use a "gem" installed
version of thor [2], as that "may cause Bundler to malfunction in unexpected ways."
Yes, they opted for bundling instead of proper design. Unfortunately, Bundler upstream was never open to any of our suggestions towards better packaging and easier collaboration with distributions. They live in Ruby (MacOS X) world and they can't imagine, that somebody might use something else.
When I looked into this for my needs, I determined that a patch
would
be required to make bundler happy if the "lib/bundler/vendor"
directory
was removed. You'd have to modify vendored_thor.rb and vendored_persistent.rb.
Could you share your patch with us, please?
I solved my issue by importing the rubygem-bundler packaging source and commenting out the removal of "lib/bundler/vendor". Like I mentioned earlier, I have my own Koji setup and I produce a yum repo "overlay" ontop of RHEL5 for my needs. So my version of rubygem-bundler does work for my needs.
Usage of many of the bundler arguments (--with/without, etc) causes
errors when "lib/bundler/vendor" has been removed.
Some examples? Bugzillas?
I created a BZ report https://bugzilla.redhat.com/show_bug.cgi?id=1010406.
Vít _______________________________________________ ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
/allen
Disclaimer Confidentiality Notice: This e-mail, and any attachments and/or documents linked to this email, are intended for the addressee and may contain information that is privileged, confidential, proprietary, or otherwise protected by law. Any dissemination, distribution, or copying is prohibited. This notice serves as a confidentiality marking for the purpose of any confidentiality or nondisclosure agreement. If you have received this communication in error, please contact the original sender. _______________________________________________ ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
________________________________
Disclaimer Confidentiality Notice: This e-mail, and any attachments and/or documents linked to this email, are intended for the addressee and may contain information that is privileged, confidential, proprietary, or otherwise protected by law. Any dissemination, distribution, or copying is prohibited. This notice serves as a confidentiality marking for the purpose of any confidentiality or nondisclosure agreement. If you have received this communication in error, please contact the original sender.
ruby-sig@lists.fedoraproject.org
-
Achilleas Pipinellis -
Allen Hewes -
Vít Ondruch