I am just getting comfortable with ruby, having come over from the Java / .NET world and I am a little confused about best practices regarding namespaces and project organization.
I have wrapped all of the classes in my current project in a namespace using modules but am a bit confused about how I should structure the files in the filesystem... I am used to having a project layout that follows the namespace hierarchy. For example:
project
(misc project docs)
src
s0nspark
app
my_app.rb <- main app entry point
my_app/
an_app_lib/
ext
(extensions to ruby classes)
lib
some_lib.rb <- main library stub loader thingie
some_lib/
another_lib.rb
another_lib
util
some_util
Is this feasible with ruby or am I opening up a bag of worms here? To be specific, would it be "right" to define the namespace for "some_lib" above like so:
module s0nspark
module libs
module some_lib
(a class goes here)
end
end
end
... and then require the lib in an app that uses it like so:
require "s0nspark/libs/some_lib.rb"
with all of the necessary lib files loaded in some_lib.rb?
Would it be unwise to use relative paths for files that are loaded/required within some_lib.rb? Is this making sense?
Thanks for any assistance in helping me cut through my fog...
Maybe I'm thinking too much in terms of normal Windows deployment but I my
plan is to take an "unzip anywhere and run" approach rather than using
rubygems or setup.rb... It should just work as long as Ruby is already
installed... Would this mean I *have* to use relative paths in my require
statements from within the libraries to make sure the runtime resolves them
properly?
Also, does my namespace/directory layout make sense within a library? I
definitely see the possibility of like-named classes in different namespaces
within the same lib so I normally depend on filesystem organization to help
me keep these separate...
Am I being too anal about this?
Cheers,
Tim
···
On 8/30/2005 7:31:09 PM, "Trans" wrote:
If I am not mistaken, setup.rb essentially defines the common sructure
for a Ruby project. And is the general layout adopted by Gems.
>If I am not mistaken, setup.rb essentially defines the common sructure
>for a Ruby project. And is the general layout adopted by Gems.
>
Thanks ... I had not seen that.
Maybe I'm thinking too much in terms of normal Windows deployment but I my
plan is to take an "unzip anywhere and run" approach rather than using
rubygems or setup.rb... It should just work as long as Ruby is already
installed... Would this mean I *have* to use relative paths in my require
statements from within the libraries to make sure the runtime resolves them
properly?
Not necessarily, but you would have to add the local directory onto the
lookup path. Something like,
$:.unshift(Dir.pwd)
Also, does my namespace/directory layout make sense within a library? I
definitely see the possibility of like-named classes in different namespaces
within the same lib so I normally depend on filesystem organization to help
me keep these separate...
Am I being too anal about this?
I've thought about this myself --this is very Java-esque, yes? Also
Reminds me of Zope. All in all, if it works for you then go for it. But
since it's purely subjective you may find that your just maintining
alot of uneeded directory stucture -- the module hierarchy in your code
speaks for itself. Personally I tend to take a middle ground approach,
splitting up a files per class or subdir for subclasses only when
things get too copious.
Would this mean I *have* to use relative paths in my require
statements from within the libraries to make sure the runtime resolves them
properly?
Not necessarily, but you would have to add the local directory onto the
lookup path. Something like,
$:.unshift(Dir.pwd)
Aah ... so the local directory is not automatically included? That explains part of my confusion...
I've thought about this myself --this is very Java-esque, yes?
Yes, it is ... probably too much so. Namespaces and the classpath were two things I really latched onto with Java, as most of the other developers I was working with at the time had no concept of organization... I think I might need to relax a bit with it now, though.
