[Rubygems-developers] 0.4.0 bugfix release
batsman.geo at yahoo.com
Sun Jun 6 09:25:09 EDT 2004
On Mon, May 31, 2004 at 12:26:59PM -0400, Jim Weirich wrote:
> We could support the pessimists view with a new operator that didn't
> bring along semantic overtones (as does ">"). I've played with several,
> but the current option I kinda like is ...
> require_gem package, "*> 1.2"
> This implements the pessimistic "greater than or equal to 1.2 and less
> than 2.0" option and should satisfy those who wish to use it.
> So, I'm proposing two changes ...
> (A) implement multiple requirements, e.g.
> require_gem package, ">= 1.2", "< 2.0"
> All requirements must be true for a package to satisfy the require.
> (B) Implement a pessimistic greater-than version operator. Suggestions
> for the operator include "*>", ">>", "<*>"
In what situation is it a gain not to make the "pessimistic operator"
the default one? I believe that being "optimistic" by default doesn't
buy you much, given Rubygems' ability to have several versions of a
lib. installed simultaneously.
Single dep. scenario 
A depends on B >= 1.2
we shall see what happens for pessimistic vs. optimistic
when B 2.0 is installed, A uses it. Possible break.
B 2.0 can be installed, A will still use B 1.2. Everything guaranteed to work,
as long as the implicit "API declaration" is correct.
A depends on * B 1.0 depends on C 1.2
* C 1.2
B 1.1 is installed; it depends on C 2.0
C >= 1.2 is satisfied by C 2.0. The following will be used:
A B(1.1) C(2.0)
possible silent breakage of A
C 1.2 and 2.0 cannot be required simultaneously.
Rubygems can detect the conflict at install time (hence warning the user before
installing C 2.0) or in the worst case at require time.
A can't be used.
I believe that  would be far more common than ; moreover it can
be assumed that A would be updated eventually to use newer versions of
IMHO it is better to
(1) guarantee correctness in the single dep. case
(2) refuse to install/run in case of conflicts
(pessimistic view) than to let things break silently in both scenarios,
and most importantly in the most common one .
For the record, I'd like the Rubygems system to have the following
Installing a new gem doesn't break the gems installed.
in other words,
New components don't affect deployed, perfectly running pre-existent ones.
Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com
Q: What's the big deal about rm, I have been deleting stuff for years? And
never lost anything.. oops!
-- From the Frequently Unasked Questions
More information about the Rubygems-developers