# Toward better project layouts

**URL:** <https://www.ruby-forum.com/t/toward-better-project-layouts/64799>\
**Category:** Ruby\
**Created:** [August 15, 2006, 2:19pm UTC](https://www.ruby-forum.com/t/toward-better-project-layouts/64799 "2006-08-15T14:19:08Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![Trans](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/dfb087/32.png) [@Trans](https://www.ruby-forum.com/u/Trans)\
**Post date:** [August 15, 2006, 2:19pm UTC](https://www.ruby-forum.com/t/toward-better-project-layouts/64799/1 "2006-08-15T14:19:08Z")

</div>

Hi–

As some of you may know I’ve been working on and off on a lib versioing  
system for Ruby that would allow versioned libs to be required  
independent of the pacakge system used to distribute them (as opposed  
to Gems). The system I’ve developed works well, and at this point I’m  
just finalizing library metadata access and integrating secure remote  
requiring. But all that aside, I want to talk about how the project  
folders are currently layed out and how what I’m doing evolves them,  
and most importantly, how might we “rethink” the whole of it for a  
better future.

Consider the typcial layout of a project has paths something like this:

myapp/branches/1.0.0/lib/myapp/foo.rb

Yours may very a bit depending on what SCM you use and how you use it,  
but it’s basicaly the same general pattern. Now, the  
distribution-independent versioning project I have requires another  
version tier:

myapp/branches/1.0.0/lib/myapp/1.0.0/myapp/foo.rb

This extra bit of layout is what allows the versioing system to remain  
independent of the packaging system. So whether the lib is installed  
via apt-get or rpm or setup.rb, it doesn’t matter, you can still  
control versioning.

Additionally, I recently asked in another thread for opinions on  
creating directory unions to be used with require. Nabu suggested  
subdirectories and appending them to the load path. While not a common  
need, when desired the paths grwo further and look like this:

myapp/branches/1.0.0/lib/myapp/1.0.0/myapp/core/myapp/foo.rb  
myapp/branches/1.0.0/lib/myapp/1.0.0/myapp/more/myapp/bar.rb

Whew! Those are some long pathnames! Clearly there is a serious lack of  
DRY going on here. “myapp” is repeated 4 times and the version 2 times.  
So I’m wondering where the root of this DRYless evil lies? Is it that  
the FHS standard forces us into this? Is the limited LCD capabilities  
of our filesystems? Is Ruby’s require system just too simplistic? Or is  
it some combination there-of? And then, what can be done to achieve a  
better way in the future?

T.

P.S. One last thing. Please, no heated debate on why all this is just a  
waste of time becuase I should just use Gems. If you think about it,  
Gems is doing a essentially the same thing, it’s just hiding the  
version tier via a specialized packaging system. My project also  
includes a tool that can create a staging of a project and  
automatically add in the the extra version tier for you. Thus achieving  
the same effect.