Mailing List Archive: Catalyst: Users

Suggestions for CatalystX::Installer

Index | Next | Previous | View Threaded

fat.perl.hacker at gmail

May 11, 2008, 12:27 AM

Post #1 of 11 (97 views)
Permalink

Suggestions for CatalystX::Installer

Greetings all,

I am developing a program called CatalystX::Installer that will
simplify the installation and setup of Catalyst applications.

I was thinking about what the default options should be for
CatalystX::Installer and am wondering what people want. Basically, I
was thinking that they should be configuration information for the
most common tools used with Catalyst. CatalystX::Installer runs
during or right after the installation of a Catalyst application and
takes care of the initial configuration.Therefore, things that are
commonly done during that time are a good candidate for adding to list
of default options.

Here is what I have so far:

1. Login information

This is where the user logs into the setup application with a username
and password.

2. Required Plugins

Here is where the user enters all of the plugins, such as HTML::Widget
Authorization::ACL, and StackTrance, that need to be loaded.
CatalystX::Installer will then add them to lib/MyApp.pm.

3. Database Locations and Types

This is where the user enters the location of and type of all of the
database that they are going to use. CatalystX::Installer will then
generate all of the necessary config files, possibly by means of
Catalyst::Example::InstantCRUD.

4. Engine

The user can select whether to use mod_perl, fastcgi, or something
else. CatalystX::Installer will then do the necessary configuration.

That is all I have so far. I was also think about having 4 screens, 1
for login, 1 for models, 1 for views, and 1 for controllers; however,
this might be hard to implement due to how blurry the borders between
those last 3 can be.

Anyways, I welcome any suggestions for default(or even non-default)
options for the setup application(which will consist of HTML forms).
I also welcome comments or questions on my current ideas or
CatalystX::Installer in general.

_______________________________________________
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[at]lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

jon at jrock

May 11, 2008, 12:55 AM

Post #2 of 11 (93 views)
Permalink

Re: Suggestions for CatalystX::Installer [In reply to]

Just a meta comment. I think you would get more attention from a
subject like "Looking for suggestions for CatalystX::Installer". The
current subject implies that you are making suggestions instead of
soliciting them. As a result, suggestion-makers may be ignoring your
post.

Regards,
Jonathan Rockway

--
print just => another => perl => hacker => if $,=$"

_______________________________________________
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[at]lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

perimus at gmail

May 11, 2008, 12:52 PM

Post #3 of 11 (83 views)
Permalink

Re: Suggestions for CatalystX::Installer [In reply to]

Paul,

Is CatalystX::Installer going to be used to help initally create a
project, or help deploy a project that is already written to a server
for use? If it is for helping deploy a project to a server, there's a
few things I think would be helpful.

- Generate a cpan preresiquites list from the source
- Generate a file or archive of some sort that can be used to deploy
the application
- Install the preresiquites via CPAN
- Implement setting up the initial database state, perhaps through
$schema->deploy(), or a SQL script, or another method
- create a system user/group to run the application under
- create the location on disk and extract the application to it from a
tar or other sort of archive
- run the app's test suite and report if tests succeed or fail
- generate an include file... perhaps something like myapp.httpd.conf
that can be included into httpd.conf

Hopefully this is helpful!

/Mitchell K. Jackson

On Sun, May 11, 2008 at 2:27 AM, Paul Cain <fat.perl.hacker[at]gmail.com> wrote:
> Greetings all,
>
> I am developing a program called CatalystX::Installer that will
> simplify the installation and setup of Catalyst applications.
>
> I was thinking about what the default options should be for
> CatalystX::Installer and am wondering what people want. Basically, I
> was thinking that they should be configuration information for the
> most common tools used with Catalyst. CatalystX::Installer runs
> during or right after the installation of a Catalyst application and
> takes care of the initial configuration.Therefore, things that are
> commonly done during that time are a good candidate for adding to list
> of default options.
>
> Here is what I have so far:
>
> 1. Login information
>
> This is where the user logs into the setup application with a username
> and password.
>
> 2. Required Plugins
>
> Here is where the user enters all of the plugins, such as HTML::Widget
> Authorization::ACL, and StackTrance, that need to be loaded.
> CatalystX::Installer will then add them to lib/MyApp.pm.
>
> 3. Database Locations and Types
>
> This is where the user enters the location of and type of all of the
> database that they are going to use. CatalystX::Installer will then
> generate all of the necessary config files, possibly by means of
> Catalyst::Example::InstantCRUD.
>
> 4. Engine
>
> The user can select whether to use mod_perl, fastcgi, or something
> else. CatalystX::Installer will then do the necessary configuration.
>
>
> That is all I have so far. I was also think about having 4 screens, 1
> for login, 1 for models, 1 for views, and 1 for controllers; however,
> this might be hard to implement due to how blurry the borders between
> those last 3 can be.
>
> Anyways, I welcome any suggestions for default(or even non-default)
> options for the setup application(which will consist of HTML forms).
> I also welcome comments or questions on my current ideas or
> CatalystX::Installer in general.
>
> _______________________________________________
> 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[at]lists.scsys.co.uk/
> Dev site: http://dev.catalyst.perl.org/
>

_______________________________________________
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[at]lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

fat.perl.hacker at gmail

May 11, 2008, 7:52 PM

Post #4 of 11 (79 views)
Permalink

Re: Suggestions for CatalystX::Installer [In reply to]

Hi Mitch,

You have some interesting ideas; thank you for your input.

CatalystX::Installer is mainly designed to help deploy an already
written project to a server for use. Here is a link to the full
description of my current plan:
http://news.perlfoundation.org/2008/05/2008q2_grant_proposal_catalyst.html#more.
Although I'm still planning, so things might change.

On Sun, May 11, 2008 at 2:52 PM, Mitch Jackson <perimus[at]gmail.com> wrote:
> Paul,
>
> Is CatalystX::Installer going to be used to help initally create a
> project, or help deploy a project that is already written to a server
> for use? If it is for helping deploy a project to a server, there's a
> few things I think would be helpful.
>
> - Generate a cpan preresiquites list from the source
> - Generate a file or archive of some sort that can be used to deploy
> the application
> - Install the preresiquites via CPAN
> - Implement setting up the initial database state, perhaps through
> $schema->deploy(), or a SQL script, or another method
> - create a system user/group to run the application under
> - create the location on disk and extract the application to it from a
> tar or other sort of archive
> - run the app's test suite and report if tests succeed or fail
> - generate an include file... perhaps something like myapp.httpd.conf
> that can be included into httpd.conf
>
> Hopefully this is helpful!
>
> /Mitchell K. Jackson
>
> On Sun, May 11, 2008 at 2:27 AM, Paul Cain <fat.perl.hacker[at]gmail.com> wrote:
>> Greetings all,
>>
>> I am developing a program called CatalystX::Installer that will
>> simplify the installation and setup of Catalyst applications.
>>
>> I was thinking about what the default options should be for
>> CatalystX::Installer and am wondering what people want. Basically, I
>> was thinking that they should be configuration information for the
>> most common tools used with Catalyst. CatalystX::Installer runs
>> during or right after the installation of a Catalyst application and
>> takes care of the initial configuration.Therefore, things that are
>> commonly done during that time are a good candidate for adding to list
>> of default options.
>>
>> Here is what I have so far:
>>
>> 1. Login information
>>
>> This is where the user logs into the setup application with a username
>> and password.
>>
>> 2. Required Plugins
>>
>> Here is where the user enters all of the plugins, such as HTML::Widget
>> Authorization::ACL, and StackTrance, that need to be loaded.
>> CatalystX::Installer will then add them to lib/MyApp.pm.
>>
>> 3. Database Locations and Types
>>
>> This is where the user enters the location of and type of all of the
>> database that they are going to use. CatalystX::Installer will then
>> generate all of the necessary config files, possibly by means of
>> Catalyst::Example::InstantCRUD.
>>
>> 4. Engine
>>
>> The user can select whether to use mod_perl, fastcgi, or something
>> else. CatalystX::Installer will then do the necessary configuration.
>>
>>
>> That is all I have so far. I was also think about having 4 screens, 1
>> for login, 1 for models, 1 for views, and 1 for controllers; however,
>> this might be hard to implement due to how blurry the borders between
>> those last 3 can be.
>>
>> Anyways, I welcome any suggestions for default(or even non-default)
>> options for the setup application(which will consist of HTML forms).
>> I also welcome comments or questions on my current ideas or
>> CatalystX::Installer in general.
>>
>> _______________________________________________
>> 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[at]lists.scsys.co.uk/
>> Dev site: http://dev.catalyst.perl.org/
>>
>
> _______________________________________________
> 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[at]lists.scsys.co.uk/
> Dev site: http://dev.catalyst.perl.org/
>

_______________________________________________
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[at]lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

jon at jrock

May 11, 2008, 8:44 PM

Post #5 of 11 (79 views)
Permalink

Re: Suggestions for CatalystX::Installer [In reply to]

* On Mon, May 12 2008, Mitch Jackson wrote:
> Paul,
>
> Is CatalystX::Installer going to be used to help initally create a
> project, or help deploy a project that is already written to a server
> for use? If it is for helping deploy a project to a server, there's a
> few things I think would be helpful.
>
> - Generate a cpan preresiquites list from the source

Module::ScanDeps

> - Generate a file or archive of some sort that can be used to deploy
> the application

"make catalyst_par"

> - Install the preresiquites via CPAN

"make installdeps"

> - Implement setting up the initial database state, perhaps through
> $schema->deploy(), or a SQL script, or another method

DBICx::Deploy

> - run the app's test suite and report if tests succeed or fail

"make test"

Regards,
Jonathan Rockway

--
print just => another => perl => hacker => if $,=$"

_______________________________________________
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[at]lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

diment at gmail

May 11, 2008, 11:59 PM

Post #6 of 11 (78 views)
Permalink

Re: Suggestions for CatalystX::Installer [In reply to]

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[at]lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

fat.perl.hacker at gmail

May 12, 2008, 12:55 AM

Post #7 of 11 (78 views)
Permalink

Re: Suggestions for CatalystX::Installer [In reply to]

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[at]lists.scsys.co.uk/
> Dev site: http://dev.catalyst.perl.org/
>

_______________________________________________
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[at]lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

fat.perl.hacker at gmail

May 13, 2008, 10:16 PM

Post #8 of 11 (47 views)
Permalink

Re: Suggestions for CatalystX::Installer [In reply to]

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[at]lists.scsys.co.uk/
> > Dev site: http://dev.catalyst.perl.org/
> >
>

_______________________________________________
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[at]lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

fat.perl.hacker at gmail

May 14, 2008, 1:17 AM

Post #9 of 11 (47 views)
Permalink

Re: Suggestions for CatalystX::Installer [In reply to]

Here is output from Module::ScanDeps

#.pl file
'AutoLoader' => '5.64',
'File::Spec' => '3.2701',
'File::Spec::Unix' => '3.2701',
'Scalar::Util' => '1.19',
'inc::Module::Install' => '0.72',
'Cwd' => '3.2701',
'List::Util' => '1.19',
'Module::Install' => '0.72',

#.pm file
'AutoLoader' => '5.64',
'Catalyst::Runtime' => '5.7012',
'parent' => '0.221',
'List::Util' => '1.19',
'Scalar::Util' => '1.19',

On Wed, May 14, 2008 at 12:16 AM, Paul Cain <fat.perl.hacker[at]gmail.com> wrote:
> 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[at]lists.scsys.co.uk/
> > > Dev site: http://dev.catalyst.perl.org/
> > >
> >
>

_______________________________________________
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[at]lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

omega at palle

May 14, 2008, 1:43 AM

Post #10 of 11 (47 views)
Permalink

Re: Suggestions for CatalystX::Installer [In reply to]

On May 14, 2008, at 7:16 AM, Paul Cain wrote:

> 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?
>

I would say that making sure the deps are correct would not be the job
of CatalystX::Installer, but the developer of the app.

What I hope CatalystX::Installer will be, is something that I can use
in my apps to make them easier to set up for people installing the app.

This for me includes:

- dependency handling
any deps the app needs, that isn't available, or the wrong version
should be installed / helped installed. For instance, a debian user
might want suggestions for debian packages to install (quite large
scope :p) For me it should not infer deps automaticly at this time,
that the developer should do before releasing his app.

- app configuration
Databases, paths, etc. This needs to be very customizable/pluggable.
For instance in easycms2, I have a config setting for what resizes to
make of pictures. It would be classy if I could easily map this to
some webform using CatalystX::Installer :p

- schema deployment / upgrades
Deploy or upgrade the given database-configuration. This sort of
infers that the CatalystX::Installer also can be used for upgrades :p

- example configurations
For apache, lighty, nginx, perlbal(?), http-server, fastcgi etc.
Perhaps it could even go as far as trying to put config under the
propper /etc/apache/conf-enabled or whatever (this becomes distro-
specific, and probably needs to be pluggable)

- Running tests.
This I think is a cool idea, to optionally run tests against the
finished setup. The author should perhaps specify which tests to run

- andreas

_______________________________________________
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[at]lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

diment at gmail

May 14, 2008, 2:21 AM

Post #11 of 11 (46 views)
Permalink

Re: Suggestions for CatalystX::Installer [In reply to]

On 14 May 2008, at 18:43, Andreas Marienborg wrote:
>
> I would say that making sure the deps are correct would not be the
> job of CatalystX::Installer, but the developer of the app.
>

Yes, but it's useful ^W essential to let the dev team know when
they've stuffed up.

> What I hope CatalystX::Installer will be, is something that I can
> use in my apps to make them easier to set up for people installing
> the app.
>
> This for me includes:
>
> - dependency handling
> any deps the app needs, that isn't available, or the wrong version
> should be installed / helped installed. For instance, a debian user
> might want suggestions for debian packages to install (quite large
> scope :p) For me it should not infer deps automaticly at this time,
> that the developer should do before releasing his app.
>

yep, local:lib or par i'm not sure which. Someone else can answer
this one.

> - app configuration
> Databases, paths, etc. This needs to be very customizable/
> pluggable. For instance in easycms2, I have a config setting for
> what resizes to make of pictures. It would be classy if I could
> easily map this to some webform using CatalystX::Installer :p
>

+1

> - schema deployment / upgrades
> Deploy or upgrade the given database-configuration. This sort of
> infers that the CatalystX::Installer also can be used for upgrades :p
>

hmm, scope creep

> - example configurations
> For apache, lighty, nginx, perlbal(?), http-server, fastcgi etc.
> Perhaps it could even go as far as trying to put config under the
> propper /etc/apache/conf-enabled or whatever (this becomes distro-
> specific, and probably needs to be pluggable)
>

yep, sounds fine for a prototype

> - Running tests.
> This I think is a cool idea, to optionally run tests against the
> finished setup. The author should perhaps specify which tests to run
>
>

and the name of the server to run them against.

> - andreas
>

Thanks for the input.

_______________________________________________
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[at]lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact lists@gossamer-threads.com