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

Paul Cain fat.perl.hacker at gmail.com
Tue Apr 29 06:56:27 BST 2008


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



More information about the Catalyst-dev mailing list