[Rubygems-developers] Two feature requests

Mehr, Assaph (Assaph) assaph at avaya.com
Thu Sep 23 02:00:49 EDT 2004

> I disapprove of post-install scripts.  They're convenient but they're
> leaky abstraction.  RubyGems is a terrific technology, but it
> take over your computer.  It shouldn't do anything that it doesn't
> how to undo -- that's one reason library stubs sucked and why handling
> application stubs needs slight improvement.
> RubyGems is about managing Ruby packages.  Ruby packages shouldn't
need a
> post-install step.  rubygems-update and vim-ruby need these, but
> because they're not actually Ruby packages; they're (ab)using the
> technology to achieve their own end.  That's justifiable and
> but they should still stand out as exceptions.

Aw, but taking over the world is fun...
Seriously, yes I can see your point, but I disagree. We already have two
packages that need this. I am working (intermittently :) on the
app-gem-installer. That could benefit again from a post-install step.

In this case I am concerned about distributing applications, and not
libraries. The target audience is also different: not (paranoid)
developers. If people choose to install my app, they are likely to trust
me and my code. At that point I want to give them a nice integrated
solution, something that will install the app on their system as a
regular application.

The app-gem-installer currently has 2 modes: One which generates an NSIS
script, from which I can generate and .exe installer (and pack the gem
within it); and second which is a ruby script that does all the
shortcuts, file-associations etc.
What I want is simply to allow running this as a post install step.

Never underestimate coveniences and leaky abstractions. They tend to be
powerful with myriad usages. Just look at Ruby ;-)

> Of course, both suggestions can co-exist:
>   Scenario 3)
>     gem install vim-ruby
>        # -> "Please install via: gem run vim-ruby install.rb"
>     gem run vim-ruby install.rb
> Of course, here you're asking RubyGems to do something it can't undo.
> you're _asking_ that, so you're responsible for knowing the
> And it's pretty clear that RubyGems is only facilitating it, it's not
> actually doing it.

You did notice the ask_yes_no before running the script? This is just a
convenience for the user: he can always answer no, inspect the code and
then decide whether to run it or not. Most users will not care and will
be glad for the convenience.

(Actually, now I notice that I don't display the full path name. That,
with perhaps better message wording, is easily corrected).


More information about the Rubygems-developers mailing list