[Catalyst-dev] Proposal to the Perl Foundation for
CatalystX::Installer
Sven Dowideit
SvenDowideit at home.org.au
Wed Apr 30 01:46:53 BST 2008
fair enough :)
now that you have the idea in mind, you may make design decisions that
will make it easier - from there refactoring to separate teh Catalyst
specifics and the web generics may well be easier.
Cheers
Sven
On Tue, 2008-04-29 at 16:49 -0500, Paul Cain wrote:
> 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
> >
>
> _______________________________________________
> 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