RFC local::lib + CPAN shell support in CatalystX::Starter (was:Re: [Catalyst] RFC: The paradox of choice in web development)

[Matt Pitts]

> -----Original Message-----
> From: Tomas Doran [mailto:bobtfish at bobtfish.net]
> Sent: Friday, February 20, 2009 3:16 AM
> To: The elegant MVC web framework
> Subject: Re: RFC local::lib + CPAN shell support in CatalystX::Starter
> (was:Re: [Catalyst] RFC: The paradox of choice in web development)
> 
> 
> On 19 Feb 2009, at 18:27, Matt Pitts wrote:
> 
> > All this talk about Perl/Catalyst/CPAN pains, has got me thinking...
> >
> > Anybody like the idea of having a local::lib "bootstrap" option to
> > CatalystX::Starter and possible integration of a script that would
> > launch a CPAN shell for installing into the local::lib folder?
> 
> CatalystX::Starter is for boot strapping a Catalyst component, not an
> application. You'd be looking to add to Catalyst::Devel

Ok, I see why it shouldn't be in CX::Starter, but if it's in C::Devel it
defeats the purpose of it being a bootstrapper because C::Devel requires
Catalyst.

My thinking was to have a system with an absolute minimum Perl/CPAN
install. My current baseline is an up-to-date CPAN (1.92+) via
Bundle::CPAN and Path::Class, but after that no other dists installed
system-wide. For this reason, I was imagining a stand-a-lone dist
(CatalystX::Bootstrapper?) that itself only requires Path::Class,
local::lib and maybe a couple of other "basic" modules.

The usage would then look something like:

$ perl -MCPAN -e 'install CatalystX::Bootstrapper'
...
$ catalystx_bootstrapper.pl MyApp
$ cd MyApp
$ script/myapp_server.pl

The only trick to this is that the bootstrapper command would have to do
all of the following:

 - setup initial directories (MyApp, MyApp/locallib, MyAPP/script)

 - write its files (script/AppBootstrap.pm, script/myapp_cpan_shell.pl)

 - invoke the CPAN shell for the 1st time to install 
     (Catalyst, Catalyst::Devel, others) this is the tricky part

 - invoke catalyst.pl MyApp (the one now installed under locallib) to
actually generate the app

 - patch the newly created script files to use AppBootstrap.pm
    (maybe there's a way to "hook" catalyst.pl instead of doing this?)

This all might be a bit rough, maybe folks out there have some better
ideas.

> > Or, maybe a separate module Catalyst::Starter::LocalLib?
> >
> > The idea would be to help folks bootstrap Cat apps and get all the
> > deps
> > inside the app folder right from the start for easier deployment. Of
> > course it won't eliminate the need for a shell, but it's still an
> > improvement.
> 
> You'd be looking to have local::lib support built into the scripts &
> etc which Catalyst generates, and an additional shell script in your
> scripts directory to start a CPAN shell pointing at your
> application's local::lib and tricks to install all the non perl core
> dependencies into that directory?

Actually, the bootstrapper CPAN shell script would install everything
into locallib. If the user wants something installed system-wide, they
can just use a normal cpan shell. Ideally, the bootstrapper wouldn't
make any assumptions about what should go where.

> That sounds like a good idea, and I've considered hacking on it
> myself, but never found the tuits.

I currently have this working well for me across a couple of apps. Using
local::lib it didn't turn out to be as tricky as I thought it might, but
I still have trouble with Module::Build based modules because sometimes
it doesn't honor --install_base -or- wants to use an existing one even
though o conf mbuildpl_arg was set.

The other part of this worth mentioning is that all the bootstrap code
is in a separate file (script/AppBootstrap.pm), which makes it easy for
additional scripts to bootstrap the local libs like so:

use FindBin;
use lib("$FindBin::Bin");
use AppBootstrap;

I'm doing this for multiple scripts that need MyApp->... for various
"jobs" as well as _server.pl, etc.

> > I could probably put together a patch if I can get some "best
> > practice"
> > ideas.
> 
> I'm thinking of rails' ability to 'freeze' rails into your
> application here. In actual fact, I've never found this feature very
> useful as I want to freeze all the dependencies too (this is
> possible, but involves hacking environment.rb and etc in the same way
> as manually attaching a local::lib to your Cat app).

I haven't played with Rails enough to get this far. Sounds similar,
though.

> I guess the biggest argument is likely to be what the correct name
> for the directory containing your local::lib is. I also expect there
> would be a fair amount of toolchain related yak-shaving to get it
> right, but its certainly a feature I'd like to see happen.

Currently, I'm just calling the directory 'locallib', but since the idea
of the module would be a bootstrapper, the name could be a command-line
option that then becomes hard-coded into the bootstrap code. Also, no
yak-shaving as of yet, but there might be some things I'm missing.

Thanks for your input t0m.

v/r
-matt pitts