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(a)lists.fedoraproject.org [mailto:ruby-sig-
bounces(a)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(a)lists.fedoraproject.org [mailto:ruby-sig-
> bounces(a)lists.fedoraproject.org] On Behalf Of Vít Ondruch
> Sent: Friday, September 20, 2013 7:27 AM
> To: ruby-sig(a)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(a)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(a)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.