[Rubygems-developers] __FILE__ hacks -was: Re: [...] Adoption

Jim Weirich jim at weirichhouse.org
Fri Oct 22 06:45:55 EDT 2004

On Friday 22 October 2004 05:23 am, Hugh Sasse Staff Elec Eng wrote:
> On Thu, 21 Oct 2004 chad at chadfowler.com wrote:
> >> That said, if RubyGems normalized the directory structures, numbering
> >> schemes, etc of the upstream sources, it *could* become the input format
> >> of choice for repackagers...
> >
> > This is actually what I had in mind.  Especially finding places where
> > people rely on, for example, __FILE__ hacks that make it hard for
> > everyone.  I'm optimistic that a focused effort with enough feedback to
> My brain produced a pop-up when I read this :-). In the new PickAxe
> you talk about testing on page 225, which refers people to the
> techniques of Chapter 12 (pp 151ff) [though you didn't write Ch 12,
> of course].  On page 160 is just such a
> __FILE__ hack to get around paths being odd after installation.  Is
> there a way to avoid this?  Can I put a method of Gem in place of
> this, or something?  For those without the book to hand, the code I
> mean is
>     $:.unshift File.join(File.dirname(__FILE__), ",,", "lib")
> I noticed that the directory structures in both chapters agreed
> (p159, 232).
> > the original developers could result in a behavioral shift in at least a
> > decent number of them.  My guess is that in most cases, developers that
> > release packages with this kind of problem do so because they didn't
> > really consider them to be a problem (as opposed to having done these
> > things intentionally).
> I've used the 'if __FILE__ == $0' hack lots of times to ensure that
> "libraries" (rather grand term for some of them!) have the test code
> with them where it won't get lost, and if you invoke it as a command
> by mistake it will do something sensible (test itself).  Maybe
> there's an elegant way to do the same thing with test code in
> another directory....
> While musing about this: Should rubygems have the capability to
> generate "boilerplate" for a new project: create the directories
> project, project/lib, project/doc, project/tests, and maybe write
> stubby versions of project/lib/project.rb,
> project/tests/ts_project.rb, etc?  For all the "Ubiquitous
> Automation" reasons.  It could then encourage people to do this sort
> of thing correctly.

In David HH's RubyConf talk, he mentioned that Rails promotes conformity by 
making the conforming "golden" path easy and the non-conforming paths 
difficult.  I see this suggestion, along with careful selection of defaults 
in the gem spec as being part of the "golden path" strategy.  If you use "gem 
initialize-directory" and a very minimal gemspec, you could have a working 
gem project.

I think providing documentation about this "golden path" is good too.  Make 
using a properly designed directory structure easy and a improper one 
inconvenient and most people will automatically follow your lead (for those 
at RubyConf: think "Man Dancing, Man playing flute").

-- Jim Weirich

More information about the Rubygems-developers mailing list