From: Trans Date: 2006-08-14T02:30:06+09:00 Subject: Toward better project layouts 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.