> -----Original Message----- > From: Tomas Doran [mailto:bobtf...@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 _______________________________________________ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/