[Rubygems-developers] 0.4.0 bugfix release

[Mauricio Fernández]

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 [1]
=====================
A depends on B >= 1.2 
we shall see what happens for pessimistic vs.  optimistic

optimistic view
---------------
when B 2.0 is installed, A uses it. Possible break.

pessimistic view
----------------
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.

Conflict [2]
============
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

optimistic view
---------------
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

pessimistic view
----------------
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.

Discussion
==========
I believe that [1] would be far more common than [2]; moreover it can
be assumed that A would be updated eventually to use newer versions of
its dependencies.
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 [1].

For the record, I'd like the Rubygems system to have the following
property:

 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!
A: ...
	-- From the Frequently Unasked Questions