[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