How about a command-line switches with intelligent defaults? E.g.
--with-bluecloth=system
That's beginning to sound like work for all involved.
In principal, having multiple copies of a lib laying around
shouldn't have to be a problem. Disk space is now cheap.
Having a copy of something in local relative directory shouldn't
be an issue if the code that wants to use it is the only code
that knows about it. Many libraries take less space than the
accompanying change log files that list every minor alteration
since day zero.
True. My only concern is what happened to Java apps a couple of years
back: you saw everyone shipping their own internal jre and refusing to
work with the system. Very annoying. As a community, I think we should
try to make ruby-gems more pervasive. Hopefully it will get into the
std-lib soon.
Packaging trivia: The tar.gz file for BlueCloth 0.0.4b is 38kb.
The bluecloth.rb file, the one that actually does the work, is
31kb uncompressed.
The wonders of modern technology 
* Mehr, Assaph (Assaph) <assaph@avaya.com> [0722 06:22]:
>> How about a command-line switches with intelligent defaults? E.g.
>> --with-bluecloth=system
> That's beginning to sound like work for all involved.
> In principal, having multiple copies of a lib laying around
> shouldn't have to be a problem. Disk space is now cheap.
> Having a copy of something in local relative directory shouldn't
> be an issue if the code that wants to use it is the only code
> that knows about it. Many libraries take less space than the
> accompanying change log files that list every minor alteration
> since day zero.
For me it's not so much a space thing as a library path thing - if the app
is overriding $: and you are trying to reproduce a problem it can be confusing
if you are loading a later library from the system paths than the app is from its
lib directory. I had a lot of trouble with a recent Instiki which I suspect was due
to a later RedCloth gem I'd installed (though I didn't have time to trace it fully,
the problem went away on a gemless server).
True. My only concern is what happened to Java apps a couple of years
back: you saw everyone shipping their own internal jre and refusing to
work with the system. Very annoying. As a community, I think we should
try to make ruby-gems more pervasive. Hopefully it will get into the
std-lib soon.
And as a sysadmin, you either find developers sending you WARfiles with
the entire Struts API in them, or you have no odd-third-party-lib.jar because
developer #2 stuck them in Tomcats CLASSPATH. Later servlet APIs have kludges
to try to solve this but they seem to muddy the waters further.
I've seen more and more ruby apps that dynamically look for optional libraries,
and workaround their absence - raggle and instiki spring to mind - I think that's
a sensible solution.
Is there any functionality in the Gem APIs to simplify this kind of check? Last time
I was looking around it I know there was talk of extending the version checking code
down to the method semantics level.
···
--
I've seen better heads on half a pint of beer.
Rasputin :: Jack of All Trades - Master of Nuns
* Mehr, Assaph (Assaph) <assaph@avaya.com> [0722 06:22]:
>
> >> How about a command-line switches with intelligent defaults? E.g.
> >> --with-bluecloth=system
>
> > That's beginning to sound like work for all involved.
>
> > In principal, having multiple copies of a lib laying around
> > shouldn't have to be a problem. Disk space is now cheap.
> > Having a copy of something in local relative directory shouldn't
> > be an issue if the code that wants to use it is the only code
> > that knows about it. Many libraries take less space than the
> > accompanying change log files that list every minor alteration
> > since day zero.
For me it's not so much a space thing as a library path thing - if the app
is overriding $: and you are trying to reproduce a problem it can be confusing
if you are loading a later library from the system paths than the app is from its
lib directory. I had a lot of trouble with a recent Instiki which I suspect was due
to a later RedCloth gem I'd installed (though I didn't have time to trace it fully,
the problem went away on a gemless server).
I'd love to hear more details offlist if you can provide them. Do you
think you had a problem with RubyGems or a problem with compatability
of the RedCloth you had installed?
I've seen more and more ruby apps that dynamically look for optional libraries,
and workaround their absence - raggle and instiki spring to mind - I think that's
a sensible solution.
Is there any functionality in the Gem APIs to simplify this kind of check? Last time
I was looking around it I know there was talk of extending the version checking code
down to the method semantics level.
We don't yet have support for optional libraries. We've talked about
a couple of approaches that seem reasonable but demand wasn't high at
the time. I've recently seen several situations that would benefit
from the ability to define "nice to have" dependencies, so I think it
will bubble to the top of the list before 1.0.
Chad
···
On Mon, 2 Aug 2004 19:31:45 +0900, Dick Davies <rasputnik@hellooperator.net> wrote: