[ruby-talk:21493] Re: nested require files need path internally

Yukihiro Matsumoto wrote:

> Hi,
> 
> In message "[ruby-talk:21406] Re: nested require files need path internally"
>     on 01/09/20, Paul Brannan <[e-mail]> writes:
> 
> |However, this is a case, I think, where we have a tradeoff between
> |simplicity in the Ruby library and simplicity in the code that Ruby
> |developers write.
> 
> Every developer who works on multi file program has to decide where to
> store files other than main one.  Candidates are:
> 
>   * current directory (this is BAD)
>   * same directory that main file exists (this is bad too)

This seems to me to be the most preferable choice for a user 
application (as opposed to a system application).  We aren't 
talking about compiler libraries here.  These is a collection of 
  script files collected for one purpose.


>   * ruby library directory (e.g. /usr/lib/ruby/1.6)

This is not only very bad for a user application, it's not even 
only bad because it assumes that one is running under a *nix 
system.  When the ruby version changes, all of the user code 
will need to be found and extracted from the old folder and 
placed into a new one.


>   * application specific directory (e.g. /usr/share/lib/app)

If I understand you, this is actually choice 2 above (i.e., 
current application file directory) that I prefer. 
Unfortunately, it assumes that I will know where the user will 
place the folder.  It should be relative to the current location 
of the folder, not to some absolute path.


> 
> I don't recommend the former two at all, so that solutions you've
> listed are not really needed.  They are just answers to the
> (artificial) puzzle.
> 
> So all you need to do to $LOAD_PATH is any of
> 
>   * do nothing, if you put them in the ruby library directory
> 
>   * put '-I dir' in the #! line at the top of the main file, if you
>     put them in the application specific directory.
> 
>   * or if you want, explicitly tweak $LOAD_PATH to include the
>     application specific directory.
> 
> There's no hole to fill, I think.
> 
> 							matz.
> 
> 

If the choices are as stated, I may need to end up combining 
every script into one immense file.  Not a good choice, but the 
best choice that seems to be offered.

What choice is reasonable depends in part on what problem you 
are solving.  For a large subset of problems the absolute best 
choice would be to transparently operate either from the current 
folder or from the current *.tar (*.zip, *.jar) archive.  And it 
should be transparently, so that the program doesn't need to 
change when you archive the folder.  (I suppose that one *could* 
develop inside of an archive, but most editors won't support 
that kind of activity.)
-- 
Charles Hixson

Copy software legally, the GNU way!
Use GNU software, and legally make and share copies of software.
See http://www.gnu.org
     http://www.redhat.com
     http://www.linux-mandrake.com
     http://www.calderasystems.com/
     http://www.linuxapps.com/