Re: RubyGems in Ruby HEAD

On Thu, 22 Sep 2005, Aredridel wrote:

>> It seems to me that rubygems is going some of the way towards making
>> this easier:- gem help unpack gives
>>
>> Usage: gem unpack GEMNAME [options]
>
> [snip]
>
>> What could be added that would facilitate creating package/rpm/???
>> for those who need to?  Given that we are discussing a TODO list at
>> the moment...
>
> Yes, that is useful -- though thanks to Mauricio Fern叩ndez, the gem
> format is a tarball and not that hard to unpack anyway.
>
> The real trouble comes from gems altering the way ruby works. There's
> code out there that requires gems, there's code out there that assumes
> ruby works the way ruby works without gems, so loading gems /at all/
> will break other things.

I think we need concrete examples of this.  Not because we don't
believe you :-), but because we need test cases

[OT] What is the correct way to markup insertion of a newline when
quoting someone?

> And now with some libraries being distributed
> both only as gems and with hard dependencies on it, that's where life
> gets tough.
>
>>> Indeed.  Note that this is partly due to a different point of view.  For
>>> Debian we package the libs and apps ourselves.  I hate to say it but
>>> there is almost no need for RubyGems in our case, whereas it is very
>>
>> Except that rubyists expect things to work cross platform.  So how
>> can we add things to make it easier?
>
> Make sure that the semantics of require are the same in both cases.
> Don't mess with the load_path silently.

But $: is a VARIABLE, for goodness sake! :-)

Maybe we should reset it when our work is complete.

> Eliminate any need for authors to require 'rubygems'; the RUBYOPT way is
> really good -- if that were the only way to make gems alter the ruby

I keep forgetting about RUBYOPT, and for that reason don't really
like it, but I'll let others speak on that.

> environment, that would be wonderful, so that code doesn't depend on
> rubygems itself, just on the things it actually depends on -- other
> related libraries.
>
         [...]
>>
>> Is there a limited set of things that you need to patch to do this?
>> Presumably it would then be possible to integrate this into the gem
>> command....  Rather like $ patch < boilerplate;
>
> Depends on the code. Some gems are trivial.
>
> Rails is a couple hours of work to patch. Rubygems dependency it pretty
> deep there.

This leaves a broad area to cover.  I don't know how we can meet
that, even half way if we don't know where the end is.
>
>>>> Those solutions may involve changes that can only happen when RubyGems
>>>> is incorporated in Ruby, but let's be realistic here.  If the RubyGems
>>>> developers aren't involved in repackaging efforts, those issues are
>>>> going to end up being low on their priority efforts unless someone
>>>> comes to them with concrete problems *and suggestions for solutions*.
>>>
>>> Ok.  Some concrete stuff then.
>>> * Upstream should only have to create a spec file, not change stuff in
>>>  the code, let 'require "foo"' stay 'require "foo"'.
>>
>> You can get the gemspec out now.  I'm not familiar enough with
>> Debian to know what more info you'd need added to it, but that
>> seems, from my limited understanding, to be a good place to store
>> this info.
>
> The salient point is 'let "require 'foo'" stay "require 'foo'"' -- that
> would help most of my repackaging woes too.

Ruby is open in nature, and redefining methods to do what we want is
particularly rubyesque.   Maybe we need to restore the old usage
after we are done....
>
> The other assumption -- and a tough problem to address in general -- is
> where to locate _non-ruby_ data files. In gems, it's
> File.dirname(__FILE__) or so -- data lives in the ruby datadir.

Can't this go in the gemspec, then?   And if you want it on a
shareable filesystem when it isn't then symlink.  What have I missed
with that though?
>
> The FHS that many linux distributions follows says it should

Which seems to be this:
http://www.pathname.com/fhs/pub/fhs-2.3.html

> be /usr/share/#{packagename}, or something more generic, if it's a

Although many GNU packages still put things in /usr/local/bin rather
than /usr/local/share/bin

> pixmap or font resource particularly.  The reason for it? Keeping things
> that should only be on the system once on the system just once. Imagine
> trying to update a font when every app that uses it has its own copy. To
> move from version 1.0 to version 1.1 of a typeface, you have to locate
> and replace the old copies.  If there's a central location, you update
> just the one.

DRY makes sense.

>>> * Create some generizable installer, maybe assist with Package[2] or
>>>  come up with something better, definitely useful to have a
>>>  distutils[1]-alike system in Ruby Core IMO.
>>
>> I think this is a big project:  I know of ZIP, tar.gz files, Sun
>> package files, RPMs, and it seems no-one has found the be all and
>> end all of installers.  This problem needs to be bounded more, I
>> think.  If we are aiming for 1.8.4 anyway.
>
> What would help more than anything is having an inspectable place to put
> data files, that works akin to rbconfig. At the moment, the only way to

Would an entry in gemspec be sufficient?

> locate data files is by configuration, in every library that uses them.
> Ruby has no central config file like PHP for this, so every library

You could scour rbconfig.rb but then

neelix hgs 36 %> cat CONFIG.rb
#!/usr/local/bin/ruby -w

require 'rbconfig'

puts Config::CONFIG.inspect

neelix hgs 37 %>

> hard-codes paths as robustly as the author thinks neccesary, which is
> never a complete solution.
>
> If ruby had a datadir mechanism, and perhaps even a path-searching
> File.open-alike method that would try each until it found one, the

require or load ...?

> problem could be neatly solved that would make both gems and non-gems
> libraries robust, and provide an elegant mechanism that no other
> language provides natively.
>
> It is undoing the assumptions that one gem = one dir that makes
> repacking them hard. With PLD in particular, we're trying to solve

PLD isn't Programmable Logic Device, or a Polish distro of GNU/Linux, 
so what is it?  (They're the first results from Google.)

> problems with a dual-architecture system like Linux/AMD64 and
> Linux/Sparc64, where the CPU can run two different kinds of code. Having
> things split up in FHS fashion lets one install packages from both
> architectures, allowing both 32-bit and 64-bit versions of things to

Or you could do it by sharing different parts of the hierarchy?

> run. This is entirely out of rubygems scope, so what I'd hope to see is
> simply the tools to let this be possible. A good datadir mechanism, and
> just trying hard not to make assumptions about the relative locations of
> files would help immensely. If this gets added to the ruby stdlib or

That would seem to require us to change require and/or $: to be as
flexible as that?  Does any of the above help, though.

> core, and gem authors were encouraged to use it, then my work would be
> much easier -- debian's too -- and we'd make more progress on making the
> ruby packages truly friendly, easy to use and complete.
>
> Aredridel
>
Much of what you mean is clearer to me now. Thank you.

         Thank you,
         Hugh