[Rubygems-developers] Post-install scripts etc

[Eivind Eklund]

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.