2008Q2 Grant Proposal - CatalystX::Installer
Thu, 01-May-2008 by
Alberto Simões
edit post
<![CDATA[
* **Name:** Paul Cain
* **Title:** 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.
**Name:**
Paul Cain
**Title:**
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.
**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, 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, 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 'cscript/myapp_setup.pl'.
my $preferred_config_type=CatalystX::Installer::Forms::SelectionList->new();
$preferred_config_type->add({
'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 'cscript/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:
$ 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. 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 \u2013 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
* 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, 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 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.
**Amount Requested:**
$3000
]]>
Comments (6)
I am not properly a Catalyst user. I used it a little to learn a little of the concept, but it seems to me that Catalyst is not stable enough for a GUI installer. IMHO I think this work would be most valuable on the development, testing and documentation (or updating documentation) for Catalyst.
But I would like to hear more about this, from Catalyst users and developers.
Interesting as this is, it seems more useful for the Catalyst-community rather than for the Perl community at large.
To say that it's useful to the Catalyst community only seems shortsighted. Making it easy for people to start using a very useful and easy-to-keep-using tool like Catalyst lowers the barrier of entry to Perl itself.
I'm not sure how compelling I find this project, but I don't think it can be dismissed out of hand.
Don't poo-poo the effects of a strong, easy-to-use framework for the language.
Rails is just a framework, too, but look what it did for Ruby as a language.
Please have a look at the thread here http://lists.scsys.co.uk/pipermail/catalyst/2008-May/018609.html when assessing this grant.
I spent time choosing an MVC. I looked and worked with Rails. I've used all sorts of CMS's.
I like what I've seen with catalyst, and i see as a non-programmer. The installer sounds spot on , would definately promote perl. Also I believe it would promote the improvement of catalyst itself, which is, to my mind, just ripe (mature enough) for an installer.
