[ruby-talk:04401] Re: New Require (was: RAA development ideas (was: RE: Looking for inp ut on a 'links' page))

On 10 Aug 2000, Dave Thomas wrote:

> Hugh Sasse Staff Elec Eng <[e-mail]> writes:
> 
> > This seems useful to me.  The only thing I see missing from this is
> > 
> > We want version 1.3.4 or newer, but we know that we don't want
> > 1.3.8, because that only lasted 6 hours until the bug (that slipped
> > throgh the regression tests) breaking earlier working code was
> > found.  But we don't want to force users of 1.3.{4,5,6,7} to
> > upgrade.
> 
> 
> A while back we had a thread where I suggested a kind of super-require 
> that would go and fetch packages automatically on request, but this
> was generally thought to be a bad idea. The stuff I'm suggesting here

	I remember that.
> 
> So, if 1.3.8 has a bug, and you happened to be unlucky enough to
> download it for the 6 hours it was available, I guess you download
> 1.3.9 and the problem goes away. I don't see how else we can do it: we 

That is fine if you were hit by the 1.3.8 bug, and what I had in mind....

> can't assume we're online, so we can't go query the RAA, and previous

...True...

> versions of a package can't predict that 1.3.8 will be a bad-un.

...but if I download the Zoo package, and I do it after 1.3.10 of wombat
is out, but I don't want to upgrade my wombat from version 1.3.4, (for
whatever reason), and the Zoo auther doesn't require me to upgrade 
unless I have ended up with 1.3.8, then this more flexible approach will
allow me to continue to use my old wombat until an upgrade is essential.
It makes the dependency relationships less brittle.  

Maybe a syntax like:

REQUIRE_STATEMENT	: require VERSION_SPEC AVOIDANCE
			;

VERSION_SPEC		: VERSION 
			| VERSION or AGE_MODIFIER
			;

AGE_MODIFIER		: newer
			| older
			:

AVOIDANCE		: avoiding {VERSION_SPEC}
			| /* nothing */
			;

IIRC {...} is a repeatable item in EBNF.  VERSION has the usual meaning.

require "wombat" 1.3.4 or newer avoiding 1.3.8

Here is another example: lots of code was developed for Tcl/Tk 7.x
Now onw might have wanted any versions of Tcl/Tk in version 7 but
not version 8

require "tcl" 7.9 or older	# assuming it worked in earlier versions
				# too
require "tcl" 7.0 or newer avoiding 8.0 or newer

or something of that sort.

> 
> Or am I (yet again) missing the point?
> 

I hope that is clearer.

> 
> Regards
> 
> 
> Dave
> 
> 
	Hugh
	[e-mail]