[Catalyst] Suggestions for CatalystX::Installer

[Paul Cain]

I've been examining everything, and was ponder about a few things:

PAR looks like a great way to archive a Catalyst app, but it doesn't
look like it is possible to un-archive it to where it is back to its
original state in case some changes need to be made. Of course, that
could be accomplished with a tar.gz file(created by make dist). I'm
not sure if that is really a problem or not.

It appears that all that CatalystX::Installer should need to deploy a
database is a valid schema.

After getting a list of required modules(using Module::ScanDeps), do I
just add them to makefile.PL?

On Mon, May 12, 2008 at 2:55 AM, Paul Cain <fat.perl.hacker at gmail.com> wrote:
> All of those modules and the suggestions look like they will be really
>  helpful, thanks for the input Jonathan and Kieren.
>
>
>  >I still want support for GetOpt:: modules as well so that we can do all this from the comand line.
>
>  Sounds good, the GetOpt:: modules should make command line arguments
>  rather trivial.
>
>
>  >The opportunity here is for the whole thing to be done wrong first time round so we know what to do for the >subsequent iteration.  This is a technique that is proven to work in technology development many times over [2].
>
>  I guess I will be back here next year to fix my mistakes then.
>
>
>
>  On Mon, May 12, 2008 at 1:59 AM, Kieren Diment <diment at gmail.com> wrote:
>  >
>  > On 12 May 2008, at 13:44, Jonathan Rockway wrote:
>  >
>  >>
>  >> Module::ScanDeps
>  >>
>  >
>  > needs some configuration || filtering to make sense of it, and warn if
>  > Makefile.PL looks wrong
>  >
>  >> "make catalyst_par"
>  >
>  > and improve the documentation here
>  >
>  >>
>  >> "make installdeps"
>  >>
>  >> DBICx::Deploy
>  >>
>  >> "make test"
>  >>
>  >
>  > Provide some standard configuration for DBIx::Class models, and
>  > Catalyst::Model::File models so we get a sense of what's required for
>  > Catalyst::Model::Whatever to support catalystx::installer.  I think that
>  > View:: logic is probably ususally hard coded into the app, but i could be
>  > wrong.
>  >
>  > Catalyst::Controller::REST for the CRUD stuff required (maybe) - remember
>  > this originates in a (rejected[1]) google summer of code application, so we
>  > need to provide learning opportunities as well as a final result.
>  >
>  > i still want support for GetOpt:: modules as well so that we can do all this
>  > from the comand line.
>  >
>  > The opportunity here is for the whole thing to be done wrong first time
>  > round so we know what to do for the subsequent iteration.  This is a
>  > technique that is proven to work in technology development many times over
>  > [2].
>  >
>  > [1] Rejected because google is a python shop and so the perl foundation
>  > didn't get enough slots, and the enlightened perl organisation application
>  > was rejected this time round
>  >
>  > [2] Although unix looks like it doesn't conform to this, it was the
>  > licencing that unix got wrong mostly.
>  >
>  > _______________________________________________
>  > List: Catalyst at 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/
>  >
>