Hugh Sasse wrote:
> On Wed, 5 Oct 2005, nobu.nokada / softhome.net wrote:
>
> > Hi,
> >
> > At Sun, 2 Oct 2005 03:14:02 +0900,
> > Austin Ziegler wrote in [ruby-talk:158553]:
> >> On 10/1/05, Trans <transfire / gmail.com> wrote:
> >>> There has been a lot of talk on core about Gems and how it
> >>> interrelates to various OS (file hierarchy) philosophies. Of
> >>> significant issue is the "DATADIR problem".
> >>
> >> This is a *Ruby* problem that's accentuated by RubyGems, but is not
> >> caused by RubyGems. The integration of RubyGems into the Ruby core is an
> >> opportunity here to solve this for Ruby.
> >
> > What do you consider needed for that purpose?
>
> There is a need for Ruby to ease the separation of portable
> libraries, architecture-dependent libraries, data files, and
> documentation for those platforms which expect this.  In short, we
> need ruby's CONFIG hash to specify more places for things to go,
> (even if for many platforms they end up pointing at the same place).
> This would allow people to specify directories for things which are
> shared between machines, and those that are machine specific, areas
> which are likely to grow (like /var) and those of constant size, and
> those areas which need read/write access and those that only need to
> be read.
>
> Quite which combinations will make the most people happy, I cannot
> say.

If you think about it, we already have a mostly determined project
directory structure dictated by a target distribution, namely FHS
--what setup.rb/install.rb need to work. So FHS is our LCD. In a way
that's too bad. It would be nice if we could be free of such
constraint. In fact I can't even imagine being a Windows user (knowing
next to nothing about Linux) and understanding the arrangement.

So if I put a data or doc file next to the .rb file it goes with in
lib/, obviously that's considered bad by FHS. In fact setup.rb won't
even install it!

And there are other difficulties. I especially find it difficult to
manage a large project in that I can't organize my lib/ structure
independent of how the end-user will access the files inside. I could
have a script rearrange it before distribution, but then I can't easily
test my scripts from their development location because Ruby's require
path is too "frigid".

T.