[Rubygems-developers] Post-install scripts etc

[Chad Fowler]

Eivind,

  I think this is a very interesting/do-able idea, but I'm frankly too
tired to give it enough thought yet.  Hopefully we can spend some time
discussing it here at RubyConf and potentially work up a POC.

Thanks for the input.

Chad

On Fri, 1 Oct 2004, Eivind Eklund wrote:

# Problem:
# 	There are things developers want to do to finish setup that
# 	RubyGems do not support,  A number of these things vary from
# 	system to system, and they can be implemented correctly and
# 	incorrectly on other levels.
#
#
# "Perfect" solution:
# 	Provide all the helpers the developers need to do the tasks,
# 	available as "extra specification" for the package (so any form
# 	of common task is implemented once and done right).  And this
# 	should be trivial to learn for the developer.
#
#
# More details:
# 	We need to somehow provide support for these helpers.  The
# 	problem is there is a bunch of people around the world that will
# 	develop the applications, and that we have too little experience
# 	to really know what helpers they'll need.  And lacking
# 	coordination and tracking of the helpers, we'd get a ton of
# 	broken helpers (not working on various systems etc).
#
# 	I'm already seeing people forcing gems to work as binary
# 	distributions, leading to cross-platform brokenness, and people
# 	doing post-install scripts that are Unix-specific, so the cross
# 	platform issues already rear their head.
#
#
# How to move from here to there:
# 	What we IMO want to do is allow post-install-hooks for a while
# 	(to gather what people need done), but refactor all of them to
# 	use generic helpers.  Then maybe let the post-install-script
# 	functionality "loose" when we've gotten more experience with it
# 	in this context, or maybe decide that the helpers are
# 	sufficient and that we don't need to let the functionality out.
#
# 	"But implementing that is not possible - RubyGems is
# 	distributed", I hear you scream.
#
# 	Here's a design (first the interface, then the implementation):
#
# 	Interface:
#
# 	A packager can add post-install-hooks, but these only work with
# 	versions of RubyGems AT OR BELOW the point in time where the Gem
# 	is released.
#
# 	If the gem is used with a later version of RubyGems, the
# 	post-install-hook is only mentioned as being available (adding a
# 	separate command to run it, and mentioning that it is outdated),
# 	unless it has been registered with RubyGems for changing, in
# 	which case RubyGems run the INTERNAL version of the
# 	post-install-hook (which may be refactored to use the new
# 	helpers) instead of the version in the package.
#
# 	Implementation:
#
# 	Each post-install-hook is labelled with a nonce (number used
# 	only once; basically a large random number) identifying the
# 	hook.  When a hook is submitted to the RubyGems team, this nonce
# 	is entered as an internal identifier for the hook.  Let's call
# 	this the pih-nonce.
#
# 	Each RubyGems release include a nonce.  Call this the rg-nonce.
#
# 	Each post-install-hook list what rg-nonces it work with.  It
# 	cannot list rg-nonces that are not yet published, because the
# 	author does not know about them, so invalidation for future
# 	releases happens automatically.
#
# 	An optimization (that is harder to implement) is to use
# 	public/private keys and publish a version number signed with a
# 	private key for each release of RubyGems, and have RubyGems
# 	include a public key it use to verify this.
#
# 	A possibly slight improvement for the multiple-rg-nonce variant
# 	is to have each nonce be a prime number, and just multiply them
# 	together for the new nonces.  Then each RubyGems variant can
# 	just check if it divides into that number.  (The only real
# 	advantage here is having a single number for the person
# 	releasing a package to include, instead of a list.)
#
# There is a less complicated variant than the above with many of the same
# advantages - force submission of post-install-hooks if they are to run
# automatically, and either sign them or disallow automatic running until
# they're included in the next RubyGems release.  However, if you want
# decentralized construction of packages with post-install-hooks and
# collection + refactoring of said hooks, one of the above schemes are
# necessary.
#
# Or one could make the collection entirely voluntary, but I suspect
# problems with getting that to work in practice - in my experience, it's
# hard to get people to submit stuff unless you're actively talking to
# them at the moment.
#
# Eivind.
# _______________________________________________
# Rubygems-developers mailing list
# Rubygems-developers at rubyforge.org
# http://rubyforge.org/mailman/listinfo/rubygems-developers
#