[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
> 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
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