From: Charles Hixson Date: 2001-09-22T00:45:33+09:00 Subject: [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 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/