[ruby-talk:12809] Re: Library packaging

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On Behalf Of Dave
> "Colin Sampaleanu" <[e-mail]> writes:
> > > The implementation of JAR files is one of the many evils of
> > > Java. Every time I get a new Java application, I have to add its JAR
> > > file to my classpath. THis rapidly becomes unmanageable.
> >
> > ... what you are typically supposed to do is start java (the vm)
> > and specify a classpath specific to that application. This can
> be done in a
> > relative fashion. So if I have an app with JARed libs in /lib,
> and some raw
> > .class files starting in /classes, I can have a batch file
> (supplied with
> > the app) in the root of the app structure which can start the
> app, with the
> > following contents:
> > ----
> > java -cp lib/whatever.jar;somethingelse.jar;etc.jar;classes
> > com.whatever.package.structure.StartClass
> > ----
>
> All true, but... with a typical application, I'm bringing in classes
> from all over the place. In the Java world, for example, I may need to
> bring in six Visibroker JAR files, a couple of Oracle JDBC ones, and a
> few of my own. And this is for _every_ application. And because these
> various vendors don't know about each other, it's up to _me_ to link
> these things together.
>
> Contrast that to the current Ruby way (which isn't perfect, but)...
>
> - I install the packages I need.>
> - I run the application.
>
> No messing with wrappers, no going through a bunch of files
> changing paths.
>
> The problem with JAR files is you can't just slap them in a directory
> and have Java find them: you have to nominate each one.
>
> Now, there's an intermediate step I _could_ support. It there was a
> library called (say) 'rdparse', and this library had a library
> structure something like:
>
>    rdparse/parser.rb
>    rdparse/token.rb
>    rdparse/token/unicode.rb
>    rdparse/lex.rb
>
> then I would be convenient to be able to package all these together in
> a single archive, say 'rdparse.rlb'. When Ruby searches for libraries,
> it could assume that within a file called 'xxx.rlb' it could resolve
> requests to load xxx/..., and therefore open it automatically. This
> would cut down on the number of files installed by an application, but
> at the same time would avoid having to list each archive file
> explicitly whenever you run an application.

So this is more about how classes are found and loaded, than about packaging
as individual files or archives. Having auto discovery/standard locations
can help somewhat, and some sort of package management tool can make things
even easier, but the tough question to me is how do you manage visibility
and versioning. If everything is visible to everything else, how do you
manage two version of a library when one piece of code somewhere needs a
version, and another needs a different one? How do you stop one app from
seeing what it shouldn't? Even in java, you can actually dump jars in
$JAVA_HOME/jre/lib/ext and they will be automatically found by the VM and
used by anyone. However a mechanism that simple can't handle managing
different versions, and in practice ends up only being used for standard
system extension. In the end you wind up with each app duplicating code. On
my system, I probably easily a dozen copies of the Xercese parser jar in a
dozen different apps. It's not great in terms of space efficiency, but at
least they don't interfere with each other, and each app is easy to
uninstall without affecting others. I'm sure there has to be a cleaner
solution, but it is not obvious to me.
One possible relatively complicated solution might be to have a centra
package manager, packages registered with the system have versions, and
there is management based on that, e.g. users of packages can specify what
version they need, and new package versions can specify how far backwards
they are compatible. I believe there is stuff somewhat along these lines
being worked on in Debian Linux to handle shared libraries...