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.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs