From: David Masover <ninja@...>
Date: 2009-08-25T09:44:16+09:00
Subject: Re: Packaging - distribution

On Monday 24 August 2009 05:08:58 pm Pito Salas wrote:
> 1) make system/ into a gem. I don't love this because it implies to me
> that it's a general purpose service, and maybe it is, but off the cuff
> it feels like overkill.

If you've never built a gem before, now is a good time to start. The hardest 
part is picking a name. After that, it's really not as scary as people make it 
out to be.

> 2) combine system/ and newapplication/ into one application. I don't
> like this because they are separate and while one depends on the other,
> the first is useful on its own.

If this is for public consumption, the question to ask is whether anyone would 
want system who didn't also want newapplication. If not, you could simply move 
system into a subdirectory of newapplication, and let people use it as needed.

> 3) copy the files from system/ into a subdirectory under newapplication.
> And keep the files in sync. I don't like this because of many reasons.

Git submodules could make this work very well. As a bonus, newapplication 
would always depend on a specific version of system, just like it could with a 
gem.

> 4) Somehow be clever with the search paths when invoking system/ from
> newapplicaiton/ I don't like this because I am not sure how to do it and
> I fear it will not be robust

"Not robust", maybe. But if newapplication always knows where system is, it's 
easy:

$: << '/path/to/system/lib'
require 'sub_alpha'

In my opinion, that's much better than trying to do something like:

require '/path/to/system/lib/sub_alpha.rb'