[Catalyst-dev] Proposal to the Perl Foundation for CatalystX::Installer

Paul Cain fat.perl.hacker at gmail.com
Tue Apr 29 22:49:04 BST 2008


Sven,

Your idea is certainly intriguing; it would be nice to create a
generic web deployment module, perhaps as a sister module to
CatalystX::Installer that uses a lot of the same code base.

Unfortunately, I'm a full time student right now, and I will only have
time to do this during the summer(although hopefully I will still be
able to maintain it afterwards). Mainly I want to keep the scope of
this program fairly narrow to assure that I can get it done on time.
However, things get ahead of schedule, I may consider adding more
functionality either to CatalystX::Installer or branching it off into
new module.

Paul Cain

On Tue, Apr 29, 2008 at 2:55 AM, Sven Dowideit <SvenDowideit at home.org.au> wrote:
> Paul,
>
>  Is there a good reason why you're making a Catalyst specific 'generic
>  GUI web deployment module'?
>
>  Would it not be more useful to make a generic Web deployment and
>  configuration module that has a Catalyst personality (and thus allows
>  for others)?
>
>  Of course, I'm somewhat biased, as I don't 'just' use Catalyst. but it
>  does feel to me like you're missing out on a bigger opportunity that may
>  be not much more work - as I would expect you need to have a web UI that
>  works before Catalyst is up & running, that then can bootstrap and
>  configure the needed pre-requisites.
>
>  and then I can leverage your work for TWiki too :}
>
>  Sven
>
>
>
>
>  On Tue, 2008-04-29 at 00:56 -0500, Paul Cain wrote:
>  > I made the suggested changes to this proposal; below is the diff of
>  > the new versions and the old. I plan on submitting this in about 19
>  > hours.
>  >
>  > Any questions/comments are welcome.
>  >
>  >
>  > --- old_proposal.txt  2008-04-29 00:47:31.000000000 -0500
>  > +++ Perl_Foundation_Proposal.txt      2008-04-29 00:48:06.000000000 -0500
>  > @@ -1,187 +1,83 @@
>  >  Paul Cain
>  > -
>  >  fat.perl.hacker at gmail.com
>  > -
>  >  CatalystX::Installer – A generic GUI deployment for catalyst applications
>  >
>  >
>  > -
>  >  *Synopsis*
>  > -Create a web application that provides a cross-platform generic GUI
>  > -for setting up Catalyst applications. There is no command line version
>  > -of this program since anyone who wants to use the command line can
>  > -just edit the configuration files directly.
>  > -
>  > +Create a web application that provides a cross-platform generic GUI
>  > for setting up Catalyst applications. There is no command line version
>  > of this program since anyone who wants to use the command line can
>  > just edit the configuration files directly.
>  >
>  >
>  >  *Benefits to the Perl Community*
>  > -Anyone who wants a friendly GUI with which they can easily setup,
>  > -test, and automatically configure their catalyst applications will
>  > -benefit from this project.
>  > -The target user base for this application is people who would like to
>  > -simplify and automate the installation of Catalyst applications onto
>  > -their web servers. Currently, each Catalyst application uses its own
>  > -setup wizard(if it even has one); this module intends to help
>  > -standardize setup by providing a generic GUI for all or most of them.
>  > -There is no command line version of this program since anyone who
>  > -wants to use the command line can just edit the configuration files
>  > -directly. I think this program could be classified as a new approach
>  > -that is also an aggregation of existing tools and ideas.
>  > -
>  > -
>  > -
>  > - *Deliverables *
>  > -I plan to deliver a completed Perl module, called
>  > -CatalystX::Installer, that provides a generic GUI for the deployment
>  > -of Catalyst applications.
>  > +Anyone who wants a friendly GUI with which they can easily setup,
>  > test, and automatically configure their catalyst applications will
>  > benefit from this project.
>  > +The target user base for this application is people who would like to
>  > simplify and automate the installation of Catalyst applications onto
>  > their web servers. Currently, there is no accepted  framework for
>  > providing GUI installers for catalyst applications; this module
>  > intends to provide a generic GUI for common web application use-cases,
>  > and a basis for extension where required. There is no command line
>  > version of this program since anyone who wants to use the command line
>  > can just edit the configuration files directly. I think this program
>  > could be classified as a new approach that is also an aggregation of
>  > existing tools and ideas.
>  >
>  >
>  > +*Deliverables*
>  > +I plan to deliver a completed Perl module, called
>  > CatalystX::Installer,  that provides a generic GUI for the deployment
>  > of Catalyst applications.
>  >
>  > -*Project Details *
>  > -For CatalystX::Installer, Marcus suggested that something like the
>  > -setup wizard for Movable Type would be a place to start for a design.
>  > -The main new idea of this approach is that the program will provide a
>  > -generic GUI that works with most if not all Catalyst application
>  > -installed on a system.
>  > -This approach frees the Catalyst developers from having to design a
>  > -setup wizard for their application(with the possible exception of some
>  > -special cases) while also freeing the user from the hassle of having
>  > -to use a different(or no) install wizard for each Catalyst application
>  > -that he or she installs.
>  > -
>  > -The solution involves adding the file "script/myapp_setup.pl" to the
>  > -template for Catalyst programs. For example:
>  > -
>  > -$ catalyst MyApp
>  > -
>  > -would create all of the files that it currently creates, plus
>  > -"script/myapp_setup.pl". The file would contain a stand-alone server
>  > -similar to script/myapp_server.pl. The administrator could then
>  > -connect to this server and use the GUI to apply the configuration
>  > -information(such as database info, fastcgi information, mod_perl,
>  > -server address, login information, language, etc) when the application
>  > -is installed on a sever. The application developer could also
>  > -customize this based on the requirements of his or her application. I
>  > -would create a set of APIs that wrap around HTML::FormFu to make this
>  > -process as simple as possible. For example, if the developer wanted to
>  > -add an entry to get the preferred type of configuration file(YAML,
>  > -INI, XML, etc), he or she could add some code similar to this to
>  > -"script/myapp_setup.pl".
>  >
>  > +*Project Details*
>  > +For CatalystX::Installer, the Movable Type setup wizard is used as an
>  > inspiration for its design. The main new idea of this approach is that
>  > the program will provide a generic GUI that works with most common
>  > use-cases for Catalyst applications, and provides a framework for
>  > extension for specialist use-cases.
>  > +This approach frees the Catalyst developers from having to design a
>  > setup wizard for their application(with the possible exception of some
>  > special cases) while also freeing the user from the hassle of having
>  > to use a different(or no) install wizard for each Catalyst application
>  > that he or she installs.
>  > +The solution involves either:
>  > +1. adding the file script/myapp_setup.pl to the template for Catalyst
>  > programs. For example:
>  > +     $ catalyst MyApp
>  > +
>  > +     That command would create all of the files that it currently
>  > creates, plus         "script/myapp_setup.pl".
>  > +2.  Having the installer script running seperately such as:
>  > +     $ catalyst MyApp
>  > +     $ cd MyApp
>  > +     $ catalystx-installer [options]
>  > +
>  > +     Where "$ catalystx-installer [options] " creates
>  > script/myapp_setup.pl and handles         any special options.
>  > +The file would contain a stand-alone server similar to
>  > script/myapp_server.pl. The administrator could then connect to this
>  > server and use the GUI to apply the configuration information(such as
>  > database info, fastcgi information, mod_perl, server address, login
>  > information, language,  etc)  when the application is installed on a
>  > server. The application developer could also customize this based on
>  > the requirements of his or her application. I would create a set of
>  > APIs that wrap around HTML::FormFu to make this process as simple as
>  > possible. For example, if the developer wanted to add an entry to get
>  > the preferred type of configuration file(YAML, INI, XML, etc), he or
>  > she could add some code similar to this to "script/myapp_setup.pl".
>  >  my $preferred_config_type=CatalystX::Installer::Forms::SelectionList->new();
>  >  $preferred_config_type->add({
>  > -    'YAML' => "YAML",
>  > -    'INI' => 'Windows INI File',
>  > -    'XML' => 'XML',
>  > +     'YAML' => "YAML",
>  > +     'INI'       => 'Windows INI File',
>  > +     'XML'    => 'XML',
>  >  });
>  >
>  > -This would allow the developer to easily customize the installer for
>  > -his or her applications. A link to "script/myapp_setup.pl" can be
>  > -placed into the root directory during make dist.
>  > +This would allow the developer to easily customize the installer for
>  > his or her applications. A link to "script/myapp_setup.pl" can be
>  > placed into the root directory during make dist.
>  >
>  > -When the user(server administrator) downloads the applications, she
>  > -first extracts it, switches to directory, and then types the command:
>  > +When the user(server administrator) downloads the applications, she
>  > first extracts it, switches to directory, and then types the command:
>  >
>  >  $ perl myapp_setup.pl
>  >
>  > -It then starts by checking Makefile.PL to verify that all of the
>  > -dependencies are installed. If all dependencies are not met, it asks
>  > -the user if he or she wants to automatically install the CPAN
>  > -dependencies, and also warns about any missing non-CPAN dependencies
>  > -that cannot be installed. Next, it verifies that the program runs
>  > -correctly by doing the tests. After that, it runs make install. When
>  > -make install completes, it will prompt the user to either enter a
>  > -password or use a randomly generated password with which the GUI setup
>  > -can be accessed(the user can change the password in the GUI setup).
>  > -The user can then access this server either from the local machine or
>  > -a remote one, as long as they are using web browser capable of
>  > -entering information into web forms. The password exists to prevent
>  > -unauthorized access to myapp_setup.pl, it is stored in an encrypted
>  > -location, and it is required for all subsequent runnings of
>  > -myapp_setup.pl. The connection will also be encrypted with SSL/TLS in
>  > -order to assure the safety of all data sent.
>  > -
>  > -CatalystX::Installer can be used for more than just installation; it
>  > -can also be used to reconfigure an application that has already been
>  > -installed. For example, if the user were to run myapp_setup.pl again,
>  > -they could change the options they set up the first time.
>  > -myapp_setup.pl would then save a backup copy of the original config
>  > -file(s), and create new ones with the new options.
>  > -
>  > -There are of course some uncertainties for this application. One of
>  > -the main foreseeable problems for this application will be making the
>  > -GUI generic enough where works for all programs, but not so generic
>  > -that user or developer(s) needs to do a lot of customizations in order
>  > -to satisfactorily setup the program.
>  > -I plan on doing some surveys on the Catalyst mailing list to see
>  > -exactly what options people want myapp_setup.pl to have by default.
>  > +It then starts by checking Makefile.PL to verify that all of the
>  > dependencies are installed. If all dependencies are not met, it asks
>  > the user if he or she wants to automatically install the CPAN
>  > dependencies, and also warns about any missing non-CPAN dependencies
>  > that cannot be installed. Next, it verifies that the program runs
>  > correctly by doing the tests.  After that, it runs make install. When
>  > make install completes, it will prompt the user to either enter a
>  > password or use a randomly generated password with which the GUI setup
>  > can be accessed(the user can change the password in the GUI setup).
>  > The user can then access this server either from the local machine or
>  > a remote one, as long as they are using web browser capable of
>  > entering information into web forms. The password exists to prevent
>  > unauthorized access to myapp_setup.pl, it is stored in an encrypted
>  > location, and it is required for all subsequent runnings of
>  > myapp_setup.pl. The connection will also be encrypted with SSL/TLS in
>  > order to assure the safety of all data sent. When the GUI setup is
>  > complete, it will ask the user if they want the setup program to
>  > create a script that can be used to automatically enter the data that
>  > they just entered into the GUI setup program. This allows a user to
>  > clone a setup for multiple systems and of course a password is still
>  > required. Also, the script, if created, will only be readable by the
>  > user who created it.
>  >
>  > +CatalystX::Installer can be used for more than just installation; it
>  > can also be used to reconfigure an application that has already been
>  > installed. For example, if the user were to run myapp_setup.pl again,
>  > they could change the options they set up the first time.
>  > myapp_setup.pl would then save a backup copy of the original config
>  > file(s), and create new ones with the new options.
>  > +
>  > +There are of course some uncertainties for this application. One of
>  > the main foreseeable problems for this application will be making the
>  > GUI generic enough where works for all programs, but not so generic
>  > that user or developer(s) needs to do a lot of customizations  in
>  > order to satisfactorily setup the program.
>  > +I plan on doing some surveys on the Catalyst mailing list to see
>  > exactly what options people want myapp_setup.pl to have by default.
>  > +
>  > +
>  >  *Project Schedule*
>  >  May 10 – Gather community feedback about what they want in the the module
>  >
>  > -May 17 – Feedback gathered – Begin designing class heirarchy charts,
>  > -flowcharts,  all necessary modules, and other planning materials
>  > +May 17 – Feedback gathered – Begin designing class heirarchy charts,
>  > flowcharts, and other planning materials
>  > +
>  > +June 1 – Project Begins by starting coding on all necessary APIs for
>  > both the base program and user extensions
>  >
>  > -May 26 – Project Begins by starting coding on all necessary APIs for
>  > -both the base program and user extensions
>  > +Monday, June 18 – APIs are functional – Begin programming
>  > myapp_setup.pl to perform its necessary functions and fixing any
>  > unforeseen problems in the APIs
>  >
>  > -Monday, June 18 – APIs are functional – Begin programming
>  > -myapp_setup.pl to perform its necessary functions and fixing any
>  > -unforeseen problems with the APIs
>  > -
>  > -Monday, July 7 – Beta 1 released – All features exist now in the
>  > -program; program will be distributed to any willing victims for
>  > -testing
>  > +Monday, July 7 – Beta 1 released – All features exist now in the
>  > program; program will be distributed to any   willing victims for
>  > testing
>  >
>  >  Monday, July 21 – Beta 2 released – mainly just bug fixes
>  >
>  >  Monday, August 4th – Release Candidate 1 released
>  >
>  > -August 11 – Release Candidate 2 released – This release may be skipped
>  > -if no show-stopping bugs are found in RC1
>  > +August 11 – Release Candidate 2 released – This release may be
>  > skipped if no show-stopping bugs are found in RC1
>  >
>  >  August 18 – Project goes gold
>  >
>  >
>  > -
>  > -
>  >  *Bio*
>  > -My name is Paul Cain. I am 18 years old and I am a Freshman(sophomore
>  > -by the time summer starts) and I go to Kansas State University at
>  > -Salina, where I have a 4.0 GPA.
>  > -I have been programming in Perl for about 2.5 years and I have read
>  > -several books on programming in Perl. Of those books, Perl Best
>  > -Practices was my favorite. I've been using Linux since 2004, although
>  > -right now I do most of my work on Windows Vista with ActivePerl and
>  > -Strawberry Perl.
>  > -For development tools, I started out using Activestate's ActivePerl as
>  > -my Perl interpreter, but more recently I have been using Strawberry
>  > -Perl due to its superior CPAN compatibility. I've also used standard
>  > -Perl installation on various Linux distributions over the years. When
>  > -coding Perl, I usually use a text editor with syntax highlighting such
>  > -as Notepad++, Kate, or Gedit. However, the larger my code gets, the
>  > -harder it is to manage with a simple text editor, especially when to
>  > -code reaches 1000+ lines. I plan to switch to an IDE with a class
>  > -browser, automated debugger, and other tools that will make the code
>  > -easier to manage. Finally, I use dual-17 inch monitors in order to
>  > -increase my productivity.
>  > -
>  > -Generally I try to stay close to the coding standards set forth in
>  > -Perl Best Practices because they provide a logical way to code that
>  > -can be easily duplicated among multiple developers. For this
>  > -particular project, I think that an Object-Oriented method of program
>  > -design would probably be the best design method due to the size,
>  > -complexity, and type of the program.
>  > -
>  > -Most of the Perl programs I write are pretty short, but the largest
>  > -program I've written was a personal project that ended up being about
>  > -1800 lines of code, much of which was for the GUI behavior. This
>  > -particular program particular will most likely be larger than that,
>  > -but I plan to use well-designed classes and strict adherence to Perl
>  > -Best Practice's coding standards in order to keep my code cleaning,
>  > -readable and easy to manage.
>  > -
>  > -
>  > +My name is Paul Cain. I am 18 years old and I am a Freshman(sophomore
>  > by the time summer starts) and I go to Kansas State University at
>  > Salina, where I have a 4.0 GPA.
>  > +I have been programming in Perl for about 2.5 years and I have read
>  > several books on programming in Perl. Of those books, Perl Best
>  > Practices was my favorite. I've been using Linux since 2004, although
>  > right now I do most of my work on Windows Vista with ActivePerl and
>  > Strawberry Perl.
>  > +For development tools, I started out using Activestate's ActivePerl
>  > as my Perl interpreter, but more recently I have been using Strawberry
>  > Perl due to its superior CPAN compatibility. I've also used standard
>  > Perl installation on various Linux distributions over the years. When
>  > coding Perl, I usually use a text editor with syntax highlighting such
>  > as Notepad++, Kate, or Gedit. However, the larger my code gets, the
>  > harder it is to manage with a simple text editor, especially when to
>  > code reaches 1000+ lines. I plan to switch to an IDE with a class
>  > browser, automated debugger, and other tools that will make the code
>  > easier to manage. Finally, I use dual-17 inch monitors in order to
>  > increase my  productivity.
>  > +Generally I try to stay close to the coding standards set forth in
>  > Perl Best Practices because they provide a logical way to code that
>  > can be easily duplicated among multiple developers. For this
>  > particular project, I think that an Object-Oriented method of program
>  > design would probably be the best design method due to the size,
>  > complexity, and type of the program.
>  > +Most of the Perl programs I write are pretty short, but the largest
>  > program I've written was a personal project that ended up being about
>  > 1800 lines of code, much of which was for the GUI behavior. This
>  > particular program  particular will most likely be larger than that,
>  > but I plan to use well-designed classes and strict adherence to Perl
>  > Best Practice's coding standards in order to keep my code cleaning,
>  > readable and easy to manage.
>  >
>  >  *Amount Requested*
>  >  $3000
>  >
>  > On Mon, Apr 28, 2008 at 11:57 AM, Paul Cain <fat.perl.hacker at gmail.com> wrote:
>  > > What if rather than having command line options, you could just use
>  > >  WWW::Mechanize to automatically fill out the forms with a script.
>  > >
>  > >  Something like:
>  > >
>  > >  use WWW::Mechanize;
>  > >  my $mech = WWW::Mechanize->new();
>  > >
>  > >  #Your password shouldn't be hardcoded into a script this way in practice
>  > >  $mech->submit_form(
>  > >         fields      => {
>  > >             username    => 'admin',
>  > >             password    => 'mypass',
>  > >         }
>  > >  );
>  > >
>  > >  $mech->submit_form(
>  > >         fields    => {
>  > >                   dbd       => 'sqlite',
>  > >                   dbname => 'foo.db',
>  > >                   #ect
>  > >         },
>  > >  );
>  > >
>  > >  This would be easier than implementing two seperate interfaces for the
>  > >  command line and GUI, and with a little golf it could probably be done
>  > >  in a few perl -e commands.
>  > >
>  > >
>  > >
>  > >  On Mon, Apr 28, 2008 at 2:14 AM, Kieren Diment <diment at gmail.com> wrote:
>  > >  >
>  > >  >  On 28 Apr 2008, at 16:57, Andreas Marienborg wrote:
>  > >  >
>  > >  >
>  > >  > >
>  > >  > > On Apr 28, 2008, at 7:26 AM, Zbigniew Lukasiak wrote:
>  > >  > >
>  > >  > >
>  > >  > > > On Mon, Apr 28, 2008 at 3:13 AM, Kieren Diment <diment at gmail.com> wrote:
>  > >  > > >
>  > >  > > > >
>  > >  > > > >
>  > >  > > > > > There is no command line version of this program since anyone who
>  > >  > > > > > wants to use the command line can just edit the configuration files
>  > >  > > > > > directly. I think this program could be classified as a new approach
>  > >  > > > > > that is also an aggregation of existing tools and ideas.
>  > >  > > > > >
>  > >  > > > > >
>  > >  > > > > >
>  > >  > > > >
>  > >  > > > > dunno about that.  You could override the myapp_install.pl script so
>  > >  > that
>  > >  > > > > if @ARGV is not empty it runs it from the command line:
>  > >  > > > >
>  > >  > > > > script/myapp_install.pl --dsn dbd:sqlite:dbname=foo.db
>  > >  > --admin-user=fred
>  > >  > > > > --admin-passwd=wilma --deployment-path=/ and so on.
>  > >  > > > >
>  > >  > > >
>  > >  > > > Hmm.  My understanding was that all of the options above could be
>  > >  > > > entered in the GUI.
>  > >  > > >
>  > >  > >
>  > >  > > I think Kieren wants to be able to do BOTH, and that the
>  > >  > CatalystX::Installer, in the end of the process, gives you a command line
>  > >  > equivalent of the setup you already did, if, for instance, you want to redo
>  > >  > the installation later or something like that
>  > >  > >
>  > >  >
>  > >  >  Yes, exactly, thanks :-)
>  > >  >
>  > >  >
>  > >  >
>  > >  >  _______________________________________________
>  > >  >  Catalyst-dev mailing list
>  > >  >  Catalyst-dev at lists.scsys.co.uk
>  > >  >  http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev
>  > >  >
>  > >
>  >
>  > _______________________________________________
>  > Catalyst-dev mailing list
>  > Catalyst-dev at lists.scsys.co.uk
>  > http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev
>
>  _______________________________________________
>  Catalyst-dev mailing list
>  Catalyst-dev at lists.scsys.co.uk
>  http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev
>



More information about the Catalyst-dev mailing list