On 11/5/07, Wolfgang Nádasi-Donner <ed.odanow / wonado.de> wrote:
> Gregory Brown schrieb:
> > There is always the option of having a 'core' gem server which hosts
> > the bits that have been marooned from the stdlib, and maybe has a
> > meta-gem that'd install all of them.
>
> Is't something like the following scenario possible (may be even now)?
>
> 1) I have a Ruby application inside a subdirectory "/myappl", which I will
> deliver as a zip file (usually for Windows, but this shouldn't matter).
>

Yeah, you can do that.

> 2) I need some parts of the standard library, which I want to include somewhere
> in a subdirectory of "/myappl", because I cannot load it on the target
> environment, so that a "require" will work.

Take the vendor/ and "gem unpack" approach like Rails, Merb and some others do.

> 3) Afterwards I'm putting everything together, so it can be installed somewhere
> on the target environment and works "stand alone".

With the vendor approach, your application run in a isolated
environment, of couse, try to append your vendor path with before the
standard library of your runtime environment.

> In principle this will work (step 2) for other libraries too, if it works at all.
>
> This scenario, or something alike, will solve all problems.

I currently do something similar for some applications, Rails and
plain Ruby ones, including every gem I use unpacked to run under
environments I don't have control to install gems or specfic versions.

Also, ofr the record, there is a new --vendor switch for extconf (on
trunk), so I guess the "vendor-something" is making its path to the
core ;-)

-- 
Luis Lavena
Multimedia systems
-
Leaders are made, they are not born. They are made by hard effort,
which is the price which all of us must pay to achieve any goal that
is worthwhile.
Vince Lombardi