[Rubygems-developers] How to deal with binary dependencies?
luislavena at gmail.com
Mon Jul 21 15:56:30 EDT 2008
On Mon, Jul 21, 2008 at 9:23 PM, Charlie Savage <cfis at savagexi.com> wrote:
> Luis Lavena wrote:
>> Hmn, I was talking that One-Click Installer did that in the past since
>> it bundled a lot of extensions and gems, but we are shifting to a
>> gem-based design where RubyGems plan a important role.
>> Manipulating the path? that means change code in RubyGems to take care
>> of each gem that expose a "binary library"... I don't like the idea.
> It has two big advantages. First, you don't have to copy all libraries to
> one directory. Second it solves the issue if 2 gems use different versions
> of the same dll (in the copying solution one gem will lose since its dll
> will be overwritten).
Yes, but also exposes issues and clashes if some gem bundles a dll
like OpenSSL which proven to clash with the openssl bindings. There is
a example of that scenario when running postgresql adapters, the
bundled openssl dll and trying to require 'openssl' library.
I saw that Ruby C openssl built/linked to a older version of openssl
(the one in ruby/bin) produce some errors when postgresql bundled dlls
precede in the PATH.
> Remember, this path manipulation is only for the currently running process
> (not system wide) and is fully supported by the Windows api. Don't know
> about other OSes though, haven't looked.
That means make RubyGems Ruby/DL dependant and include the
SetDllDirectory API. I'm not against that, but we need to know how
deep those modifications go.
>>>> What about #binaries? and we thread them different that executables
>>>> (verbatim copy them instead of adding shebangs).
>>> I'd probably be more specific and define a new spec setting called
>>> "libraries" that means RubyGems will:
>> But a library is also a ruby library, which doesn't apply. Is it a
>> binary dependency of the extension bundled in the gem.
> Yes. But there is a difference between a binary executable and a binary
> library. I think we would regret calling them the same thing, because they
> are not.
Is better we find sooner a name to make them fit properly sooner than later :-)
>>> a) On installation copy the files marked "libraries" to ruby/bin
>>> b) On loading a gem, update the path to include the location of the
>>> files (if any are set).
>>> spec.libraries << "lib/libxml2-2.dll"
>>> How does that sound?
>> Hmn, that definetely add some platform specific code beyond what
>> RubyGems should be doing... and from POV I don't like it so much.
> Why is that platform specific code? Any file listed in libraries gets
> copied to ruby/bin.
SetDllDirectory ? or you're talking about ENV['PATH'] alteration in this case?
> Of course, you might not want that to happen on all platforms, but to solve
> that you just provide platform specific gems (which obviously you have to
> anyway if the GEM include binary files). For a Windows GEM you'd include
> the spec.libraries line, for other platform GEMS you would not.
I'll love to heard back from Eric and other RubyGems developers about this.
>>> And what should I do in the short term?
>> Indicate your users to copy the dll or provide a RubyGems binary
>> (minimal script) that performs the dll copy form that particular
>> folder into ruby/bin (Gem.bindir)
> Right - which is what we do now in the documentation. I think that's a bad
> solution and want to avoid it.
We agree :-P
>> Something similar is what I do for mongrel_service.
> Services are a bit different, in that you need admin rights to install.
Oh, I was not talking about installing services, I was talking about
mongrel_service use a small script to copy mongrel_service executable
into ruby/bin directory.
(I need to improve my english)
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
More information about the Rubygems-developers