The real Ruby vs. Python

ruby-talk
61

"Strong dependency management" means that the system ensures no invalid
state (where the dependencies are not fully satisfied) can be reached.
In that sense, RubyGems' dependency management isn't "strong".

The problems are fairly subtle and easy to overlook; I myself didn't
notice them at first when working on rpa-base.

RubyGems' versioning model makes it difficult to track reverse
dependencies: currently user intervention is required to ensure no
dependencies are broken on uninstall, and the installation/removal
of a RubyGems package plus its dependencies isn't performed as a
transaction. There are also some essentially unsolvable issues at runtime
(unsatisfiable dependencies).

···

On Thu, Oct 28, 2004 at 09:08:08PM +0900, David A. Black wrote:

On Thu, 28 Oct 2004, Mauricio Fernández wrote:

> If you really want to use rpa-base (maybe you need atomicity or strong
> dependency management?), take a look at the above link and feel free to
> ask :slight_smile:

Clarification, in case anyone misunderstands: I don't know what your
threshold is for "strong", but Ruby Gems has dependency management,
and I haven't seen anything non-strong about it.

--
Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com

62

when a package is installed - do you store dags of the dependancies somewhere
then? i guess it would need to be a single dag (at least logically) so you
could detect problems on uninstall huh?

-a

···

On Thu, 28 Oct 2004, Mauricio [iso-8859-1] Fernández wrote:

On Thu, Oct 28, 2004 at 09:08:08PM +0900, David A. Black wrote:

On Thu, 28 Oct 2004, Mauricio Fernández wrote:

If you really want to use rpa-base (maybe you need atomicity or strong
dependency management?), take a look at the above link and feel free to
ask :slight_smile:

Clarification, in case anyone misunderstands: I don't know what your
threshold is for "strong", but Ruby Gems has dependency management,
and I haven't seen anything non-strong about it.

"Strong dependency management" means that the system ensures no invalid
state (where the dependencies are not fully satisfied) can be reached.
In that sense, RubyGems' dependency management isn't "strong".

The problems are fairly subtle and easy to overlook; I myself didn't
notice them at first when working on rpa-base.

RubyGems' versioning model makes it difficult to track reverse
dependencies: currently user intervention is required to ensure no
dependencies are broken on uninstall, and the installation/removal
of a RubyGems package plus its dependencies isn't performed as a
transaction. There are also some essentially unsolvable issues at runtime
(unsatisfiable dependencies).

--

EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
PHONE :: 303.497.6469
When you do something, you should burn yourself completely, like a good
bonfire, leaving no trace of yourself. --Shunryu Suzuki

===============================================================================

63

# On Thu, Oct 28, 2004 at 09:08:08PM +0900, David A. Black wrote:
# > On Thu, 28 Oct 2004, Mauricio Fernández wrote:
# >
# > > If you really want to use rpa-base (maybe you need atomicity or strong
# > > dependency management?), take a look at the above link and feel free to
# > > ask :slight_smile:
# >
# > Clarification, in case anyone misunderstands: I don't know what your
# > threshold is for "strong", but Ruby Gems has dependency management,
# > and I haven't seen anything non-strong about it.

···

On Thu, 28 Oct 2004, Mauricio [iso-8859-1] Fernández wrote:

#
# "Strong dependency management" means that the system ensures no invalid
# state (where the dependencies are not fully satisfied) can be reached.
# In that sense, RubyGems' dependency management isn't "strong".
#

"Strong" as in "Strong typing".

# The problems are fairly subtle and easy to overlook; I myself didn't
# notice them at first when working on rpa-base.
#
# RubyGems' versioning model makes it difficult to track reverse
# dependencies: currently user intervention is required to ensure no
# dependencies are broken on uninstall, and the installation/removal
# of a RubyGems package plus its dependencies isn't performed as a
# transaction. There are also some essentially unsolvable issues at runtime
# (unsatisfiable dependencies).
#

Most of this is by design. An example of something that I believe is
broken from an end-user perspective in rpa-base is that when I remove a
package, it removes all of the dependencies. We _don't_ want to do that
with RubyGems. I have Rails installed, and I've written scripts to use
ActiveRecord, which was installed with Rails. If I decide I don't want
Rails anymore, I don't want to have to go manually install ActiveRecord
afterward.

As for tracking reverse dependencies, it doesn't seem difficult to me:

  spec.dependent_gems

The manual user intervention you were talking about is not _necessary_.
We added it because we wanted the user to have the choice to remove a
package even if it might screw something up. I see it as being in the
same vein as allowing a programmer to pass a String into a method that may
usually expect something else. "Here's some rope...you can use it to tie
knots, secure things, etc. or you can hang yourself with it. We trust
that you'll make the right decision, because we don't think you're an
idiot."

Chad

64

... unlike Mauricio (and the rest of the RPA team).

That last part didn't add much to the discussion, but it does add to
the belief that the two teams are antagonistic.

Perhaps I just read it the wrong way.

···

On Thu, 28 Oct 2004 23:31:05 +0900, Chad Fowler <chad@chadfowler.com> wrote:

We trust that you'll make the right decision,
because we don't think you're an idiot."

--
Bill Guindon (aka aGorilla)

65

First of all, this email is written by me, Horacio López and doesn't
necessarily reflect the opinions of the RPA team.

We added it because we wanted the user to have the choice to remove a
package even if it might screw something up. I see it as being in the
same vein as allowing a programmer to pass a String into a method that may
usually expect something else.

I see these comments in the same vein as comparing oranges to apples.

"Here's some rope...you can use it to tie
knots, secure things, etc. or you can hang yourself with it.

it could read more like:
"here's a nice tool, you can use it to run production installations
without breaking stuff, streamlining the process and behaving in a
predictable manner... or you can use your former package management
system of choice"

We trust that you'll make the right decision, because we don't think you're an
idiot."

it could read more like:
"we ease the job because our focus is quality, and not everyone is
willing or have time to spend building decent packages that work
together well"

We don't call people "idiots".

Some people believe just a little policy is good for production
environments, nobody is going to die because of it, and you can
happily continue to design another system that has another policy (if
any) that suits your needs better.

I would still like to know what's the Rubygems manifesto, set of
guidelines, what's the purpose, big idea, right now, based on your
comments and diverging opinions from other Rubygems developers,
features that appear and disappear in the next release, it's hard to
tell and it feels like a bit of a moving target.

It's way much more difficult to start a decent analysis of a system if
you don't know what it will be like in 10 seconds from now, perhaps
it's not even worth the hassle.

On the other hand, it's very easy to drop FUD about a clearly defined
roadmap, for bad or good.

best,
                              vruz

66

An example of something that I believe is
broken from an end-user perspective in rpa-base is that when I remove a
package, it removes all of the dependencies. We _don't_ want to do that
with RubyGems. I have Rails installed, and I've written scripts to use
ActiveRecord, which was installed with Rails. If I decide I don't want
Rails anymore, I don't want to have to go manually install ActiveRecord
afterward.

Heh. This seems to be a preference issue: I strongly prefer that
dependencies are removed. This is especially important when libraries
are used for application support. I see extra dependencies being left
around as a significant problem when my use is scaled a little bit.

As an example, on one of my FreeBSD systems where I've experiemented
with different software packages and dependencies are not
automatically removed, I presently have 399 software packages
installed. I guess over 100 of these are presently unused
dependencies. These complicate my enviornment, but removing them is
work, and risk breaking things that have added implict dependencies on
them.

In my ideal world (and the design I originally described for RPA), the
dependencies are *hidden* from the user until they are explictly
requested. Thus, your case above cannot happen.

As for tracking reverse dependencies, it doesn't seem difficult to me:

  spec.dependent_gems

The manual user intervention you were talking about is not _necessary_.

I don't get this. Do you mean there is a way to deinstall the
dependencies that the install of a gem auto-installed without manual
intervention? If so, how? I couldn't find it in the documentation -
I'll add it in the places I looked if there is a way.

We added it because we wanted the user to have the choice to remove a
package even if it might screw something up.

I don't see how this relate to the above - may we be talking past each other?

I see it as being in the
same vein as allowing a programmer to pass a String into a method that may
usually expect something else. "Here's some rope...you can use it to tie
knots, secure things, etc. or you can hang yourself with it. We trust
that you'll make the right decision, because we don't think you're an
idiot."

I'm an idiot, so I tend to presume that there are others out there, too :slight_smile:

I work day-to-day with a package system (FreeBSD's) that do track
reverse dependencies and prevent dropping packages that has a
dependency, but do allow a force switch to override it.

I regularly try to de-install libraries that are in use. Roughly 70%
of those attempted de-installs are by accident, while 30% are ones
that I want to go through with anyway. So I definately appreciate
being caught by the safety-net.

Eivind.

···

On Thu, 28 Oct 2004 23:31:05 +0900, Chad Fowler <chad@chadfowler.com> wrote:
--
Hazzle free packages for Ruby?
RPA is available from http://www.rubyarchive.org/

67

It is easy to rebuild the graph on uninstall, based on the stored
dependency information. rpa-base also has a mark and sweep garbage
collector (like Ruby :slight_smile: to reclaim unneeded packages. It is very useful
for "build dependencies", but that concept doesn't exist in RubyGems so
they're not in dire need of that.

···

On Thu, Oct 28, 2004 at 11:04:01PM +0900, Ara.T.Howard@noaa.gov wrote:

>RubyGems' versioning model makes it difficult to track reverse
>dependencies: currently user intervention is required to ensure no
>dependencies are broken on uninstall, and the installation/removal
>of a RubyGems package plus its dependencies isn't performed as a
>transaction. There are also some essentially unsolvable issues at runtime
>(unsatisfiable dependencies).

when a package is installed - do you store dags of the dependancies
somewhere
then? i guess it would need to be a single dag (at least logically) so you
could detect problems on uninstall huh?

--
Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com

68

# "Strong dependency management" means that the system ensures no invalid
# state (where the dependencies are not fully satisfied) can be reached.
# In that sense, RubyGems' dependency management isn't "strong".
#

"Strong" as in "Strong typing".

Exactly... with the exception that it's got nothing to do at all :wink:
with what we're talking about :))) So it's more like apples and oranges.

# The problems are fairly subtle and easy to overlook; I myself didn't
# notice them at first when working on rpa-base.
#
# RubyGems' versioning model makes it difficult to track reverse
# dependencies: currently user intervention is required to ensure no
# dependencies are broken on uninstall, and the installation/removal
# of a RubyGems package plus its dependencies isn't performed as a
# transaction. There are also some essentially unsolvable issues at runtime
# (unsatisfiable dependencies).
#

Most of this is by design.

And it's good so. I was trying to explain the differences between
RubyGems and rpa-base, you shouldn't interpret it as an attack. The
fact is that RubyGems supports several versions of a lib at a time,
and rpa-base works differently and features what I've called "strong
dependency management".

These differences illustrate that RubyGems and rpa-base have different
goals, and that it is indeed a good idea for RPA not to throw rpa-base
away to embrace RubyGems: after all, rpa-base was designed for RPA.

Both codebases are useful for their respective niches and we're looking
forward to increased cooperation especially given your recent commitment
to making RubyGems repackager-friendly. I can tell you that many ppl are
looking forward to that and we (I can't really speak for the whole RPA
team because we're quite busy in general, but at least I) will try to
help you make that happen.

An example of something that I believe is
broken from an end-user perspective in rpa-base is that when I remove a
package, it removes all of the dependencies.

We've explained in the past that this is a known UI issue that will be
solved when we get our new UI framework in place. There's a reason for
rpa-base being 0.2 :wink:

Anyway, I wonder what that well known UI issue in rpa-base has got
to do with RubyGems' lack of "strong dependency management" given the
above definition.

We _don't_ want to do that
with RubyGems. I have Rails installed, and I've written scripts to use
ActiveRecord, which was installed with Rails. If I decide I don't want
Rails anymore, I don't want to have to go manually install ActiveRecord
afterward.

It is possible to indicate which dependencies shouldn't be uninstalled
when their rev-depends. are removed. IMHO this should be a configuration
option and it will be handled that way in the new UI. I believe
rpa-base's new configuration system and UI framework could benefit
RubyGems so we'd be happy to contribute it when it's finished.

If you want to let the user choose (to match the "we don't think you
are an idiot" philosophy you profess) what to do, you will need a
garbage collector for the packages. I might try to adapt rpa-base's for
RubyGems but I'm not sure it's practical because its versioning model
makes it harder to track (reverse) dependencies.

As for tracking reverse dependencies, it doesn't seem difficult to me:

  spec.dependent_gems

Well you're obviating the code behind *g* But there are still some problems
you'd run into if RubyGems tried to do everything rpa-base does
regarding reverse deps, etc... This is probably better discussed on IRC
or on your ML though.

The manual user intervention you were talking about is not
_necessary_.
We added it because we wanted the user to have the choice to remove a
package even if it might screw something up.

Choice is good. Having a system provide guarantees so that the user
doesn't have to bother about things that can be handled automatically is too.

I see it as being in the
same vein as allowing a programmer to pass a String into a method that may
usually expect something else. "Here's some rope...you can use it to tie
knots, secure things, etc. or you can hang yourself with it. We trust
that you'll make the right decision, because we don't think you're an
idiot."

I am sure we all love dynamic typing but it doesn't really have anything
to do with this :slight_smile:

I use rpa-base myself and I surely don't call myself an idiot *for that*
(there are many other better reasons :wink:

···

On Thu, Oct 28, 2004 at 11:31:05PM +0900, Chad Fowler wrote:

--
Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com

69

We trust that you'll make the right decision,
because we don't think you're an idiot."

... unlike Mauricio (and the rest of the RPA team).

That last part didn't add much to the discussion, but it does add to
the belief that the two teams are antagonistic.

Not every sentence by a discussion participant needs to add something
to the discussion, surely.

Perhaps I just read it the wrong way.

Perhaps, perhaps not. The above sentence is not good evidence,
though: claiming to not treat users like idiots is the preserve of
many technology enthusiasts. That doesn't make them antagonistic.

Gavin

···

On Friday, October 29, 2004, 2:16:56 AM, Bill wrote:

On Thu, 28 Oct 2004 23:31:05 +0900, Chad Fowler <chad@chadfowler.com> wrote:

71

vruz wrote:

"Here's some rope...you can use it to tie
knots, secure things, etc. or you can hang yourself with it.

it could read more like:
"here's a nice tool, you can use it to run production installations
without breaking stuff, streamlining the process and behaving in a
predictable manner... or you can use your former package management
system of choice"

We trust that you'll make the right decision, because we don't think you're an
idiot."

it could read more like:
"we ease the job because our focus is quality, and not everyone is
willing or have time to spend building decent packages that work
together well"

We don't call people "idiots".

I don't believe Chad's remarks were in the context of comparing gems
and rpa at all, but rather the context of explaining design decisions
in gems.

Therefore your translation may result in true statements, but I don't
think it has any relation to what Chad was saying.

Hal