On Jan 29, 2013, at 7:12 PM, James Tucker <jftuc...@gmail.com> wrote: >> As callous as this sounds, this actually doesn't solve anything. The proof >> is in your examples -- they're a part of the standard library for the >> respective platforms. >> >> As soon as you need something like 'libferrous' of a specific version, >> you're boned. Also ldd/otool will never output the results of a gem's native >> dependencies, because ruby is never linked against them until the gem is >> required, and only indirectly. Ruby loads the gem's native object which is >> linked against the library that would be in the gemspec. > > % otool -L nokogiri.bundle > nokogiri.bundle: > /usr/lib/libexslt.0.dylib (compatibility version 9.0.0, current version > 9.15.0) > /usr/lib/libxslt.1.dylib (compatibility version 3.0.0, current version > 3.26.0) > /usr/lib/libxml2.2.dylib (compatibility version 10.0.0, current version > 10.8.0) > /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version > 7.0.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current > version 169.3.0) > /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version > 228.0.0) >
That object wouldn't exist if the dependencies weren't satisfied beforehand, as it wouldn't be able to be compiled. You'll note the original email talks about running against ruby, not a specific shared object. Binary gems could work with this, but with all respect let me know when that's a plausible reality for anyone not on windows. Josiah and I had a system which was a small service and gem plugin that mapped dependency+version (provided via the metadata facility) to a platform-specific set of packages. Then based on the user-selected or detected platform it would install those packages, elevating privileges if necessary. It would then finish the gem installation which at that point should work no differently than it does now. Hooks have been in rubygems that can make this work since 1.6 or so (and I believe this was around the time we came up with this idea). Someone just has to write it. That someone will likely not be Josiah or myself, but I'll be happy to detail this for anyone that's interested in building such a thing. It's not very complicated and there's a little code out there, but not much; I think it was written at the last philly.rb we both attended which was around 2 years ago, but it's a simple enough idea to get your head around regardless. Metadata is arguably the perfect place for this for the reasoning I try to provide above. Third party tools can support it, devs can use those third party tools, and production systems don't have to if they don't want to. If you want a fancy DSL, I don't think anything keeps you from subclassing Gem::Specification. It was geared towards developers. Making rubygems or mkmf satisfy system dependencies as a first class feature would make writing replacements for both a very appealing topic for sysadmins that have to support ruby stacks and don't work around both already. -Erik _______________________________________________ RubyGems-Developers mailing list http://rubyforge.org/projects/rubygems RubyGems-Developers@rubyforge.org http://rubyforge.org/mailman/listinfo/rubygems-developers
