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

[Kieren Diment]

comments inline


On 28 Apr 2008, at 09:56, Paul Cain wrote:
>
> 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.
>
>
> *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);

Better to say that there's no accepted practice of framework for  
providing gui installers for catalyst apps.


> this module intends to help
> standardize setup by providing a generic GUI for all or most of them.

perhaps change this to something like: "by providing 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.
>

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.

perhaps with a nice little thing at the end of the gui installer that  
shows you the command line options you could have used at the end of  
the wizard.

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

Replace with:  "CatalystX::Installer uses the  with the Movable Type  
setup wizard as inspiration for its 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.

replace with : "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 adding the file "script/myapp_setup.pl" to the
> template for Catalyst programs. For example:
>
> $ catalyst MyApp
>

I think what's more likely to be that first you make the skeleton:

catalyst.pl MyApp

then you invoke a script to invoke the installer separately:

catalystx-installer [options]

do this from MyApp's home directory, and you use the Makefile.PL to  
work out that a.  you are actually in a catalyst app's home dir, b.   
what you want in the installer,

> 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".
>
> 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 "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:
>
> $ 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.
>

I'll leave marcus to comment on the technical details above

Your schedule below is out of whack.  if the grant is accepted, it  
will commence on the 1st of June.  You can of course start gathering  
feedback from now though.

> *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 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 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 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
>
> _______________________________________________
> Catalyst-dev mailing list
> Catalyst-dev at lists.scsys.co.uk
> http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev