On 01/23/2012 04:23 AM, Vít Ondruch wrote:
Dne 20.1.2012 18:38, Mo Morsi napsal(a):
On 01/20/2012 03:58 AM, Vít Ondruch wrote:
Dne 19.1.2012 21:52, Mo Morsi napsal(a):
On 01/19/2012 03:16 AM, Vít Ondruch wrote:
So, obviously the bundle can't find the C extension. According to
some research, I see this on rubygems.org
"This works because rubygems copies the shared object from ext to
lib
when the gem is installed."
I'm not sure that's happening.
Actually that's happening, just a bit differently. You see that
you have the
'/usr/local/lib/gems/exts/sqlite3-1.3.5/lib/sqlite3/sqlite3_native.so'
so it is in libs and if you run "$ ruby -r sqlite3 -e "puts 'it
works'"", RubyGems should prepare the load paths and everything
should work.
Unfortunately Bundler does not use RubyGems to prepare the load
paths and it is doing everything by itself. Therefore Bundler
doesn't know about this modifications we made to RubyGems and
cannot load the library properly. Moreover, Bundler replace the
RubyGems modified 'require' by the Ruby's original version, so
RubyGems cannot help here.
We are looking into Bundler now to find a cure. Unfortunately,
that means you will not be able to use stock Bundler in Fedora
anymore. The only option is to push the RubyGems modifications
upstream [1], and later push the changes into Bundler's upstream.
However, RubyGems upstream is not very responsive in this matter.
May be you can try to support us a bit.
Yes, seems to be a pretty big blocker. The new paths should allow
us to use both the version of bundler shipped via rpm and bundler
if installed via gem.
We can push for different practices upstream but that is quite an
effort w/ no guarantees, and most likely won't be implemented by
F17. If we can't figure out a solution to get bundler working at a
technical level, this will have to push the 1.9.3 release back.
To clarify things a bit, RubyGems as they are prepared for F17, will
install your custom gems into your home directory. If you are doing
so, Bundler should have no issues. If you want to deploy your
application, it is best if you are going with RPM packaged gems,
including RPM Bundler. If you are going to install gems system-wide,
using gem install as a root, you are "asking for troubles" (yes, it
is a bit exaggerated :)) and you should know what are you doing.
Vit
The problem is, installing gems system-wide as root is a valid use
case, which is often practised in the upstream ruby community.
Putting comments aside on the wisdom of such practices, I've seen
many ruby applications instruct the user to install dependencies via
'sudo gem install'.
If this use case is broken under Fedora 17, this will be a regression
as far as our community's support. This is a big enough blocker that
we can't accept it, so we'll need to figure out a solution or hold
off the release until one is engineered. I don't forsee this taking
too long, even if it involves some guidelines or upstream bundler
work, though may cause us to miss the F17 target.
-Mo
_______________________________________________
ruby-sig mailing list
ruby-sig@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
Hi Mo,
There are 3 solutions:
1) Always use Bundler provided by Fedora which will works as it should.
2) Force Ruby and RubyGems upstream to properly support FHS. I already
provided patches [1] but I need your support.
3) Revert the customized behavior of RubyGems for /usr/local
I strongly disagree with point 3. You have choice, either you broke
some Ruby users expectations or you broke the rules given by FHS. You
can't have both ATM. It would be nice if you could help to stir Ruby
and its community in correct directions instead of promoting bad
practices in the name of "often practised in the upstream ruby
community". I would really appreciate if you could weight in and send
your comments upstream [1]. Bundler upstream may follow, the patch is
ready ....
I understand your sentiment about helping the ruby community move away
from bad practices, including not conforming to the FHS, but it's just
not going to work by breaking support for a widespread upstream practice.
In these situations, the path of least resistance is always most often
employed, and this will just result in fewer upstream ruby developers
using Fedora as a platform, and/or more using rvm and alternative
tools/platforms to install ruby, rubygems, etc.
I whole heartedly agree that when the gem / bundler communities adopt
the FHS standards, it'd make sense to make the changes in our packages.
But until then we need to still be able to allow for upstream practices
(even if we don't officially support them) while working with the
upstream communities to better those practices and migrate to our platform.
-Mo
_______________________________________________
ruby-sig mailing list
ruby-sig@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
