[Rubygems-developers] Two feature requests

[Mehr, Assaph (Assaph)]

> I disapprove of post-install scripts.  They're convenient but they're
a
> leaky abstraction.  RubyGems is a terrific technology, but it
shouldn't
> take over your computer.  It shouldn't do anything that it doesn't
know
> how to undo -- that's one reason library stubs sucked and why handling
of
> 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
that's
> because they're not actually Ruby packages; they're (ab)using the
RubyGems
> technology to achieve their own end.  That's justifiable and
convenient,
> 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.
But
> you're _asking_ that, so you're responsible for knowing the
consequences. 
> 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).

Cheers,
Assaph