I have created a rough specification based on all of this input. It is a bit rough right now, but I will try to clean it up when I get more time. This week is the week of my final exams, therefore I was busy.
Here is the specification(if you are too lazy to read the whole thing, skip to the footnotes for points of conversation). Questions, comments, and more input/feedback are welcome: *Synopsis* Create a web application that provides a cross-platform generic GUI for setting up 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. #What The Developer Does $ catalyst MyApp $ cd MyApp $ catalystx-installer [options] The first command creates the skeleton of the Catalyst application, the second command switch to the root directory of that Catalyst application, and the third command creates script/myapp_setup.pl and handles any special options. Where script/myapp_setup.pl would contain a stand-alone server similar to script/myapp_server.pl. The administrator(person installing the Catalyst application) could then connect to this server and use the GUI to apply the configuration information[1] 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 application developer wanted to allow users to run SQL commands(from a file) on a SQLite database, he or she could do something like this[2]. my $sql_commands=CatalystX::Installer::Controller->new(); $sql_commands->set_type('Entry'); $sql_commands->set_action(sub{ my ($self, $c,$database,$sql_file); system "sqlite3 $database < $sql_file"; }); This would allow the developer to easily customize the installer for his or her applications. A link to "script/myapp_setup.pl" could possibly be placed into the root directory during make dist. The developer could place post-setup in a directory called 'post_t/'.Lastly, the developer could archive the application for distribution. #What The User Does When the user(server administrator) downloads the applications, they first extract it from the archive, switches to directory, and then types the command[3]: $ perl script/myapp_setup.pl First, it scans for dependencies with Module::ScanDeps, and adds any dependencies not already found in Makefile.PL to Makefile.PL. It then runs through the installation scripts while keeping the user informed of its progress: $perl Makefile.PL $make $make test $make install If the tests in 'make test' pass and 'make install' complete successfully, 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. The GUI setup will be (possible) be organized into four sections: Login, Model, Controller, and View. Each of these sections can also have sub-sections. 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 configuration file(s), and create new ones with the new options[4]. 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. #Footnotes [1] Some things that can be configured in the GUI setup include the following: username password plugins to load include file include paths database location(if exists) database schema Configuration for other types of models SQL commands Engine(mod_perl, fastcgi, ect) Extra configuration(any other editing of configuration files) [2] The final code will most likely be much different and much more refined. This example is just to give the reader a basic idea of things. [3] Should script/myapp_setup.pl exist in a PAR archive in order to prevent the problem of the script not running because of missing dependencies? [4] Should script/myapp_setup.pl always run through the installation scripts (Module::ScanDeps, perl Makefile.PL, make, make test, make install) every time the program runs, or should it just do it during its first run and at the user's request? Perhaps the script could be split into two parts: one of which runs through the installation scripts, and the other containing the server with the GUI forms where the user enters the rest of the setup information. On Wed, May 14, 2008 at 4:21 AM, Kieren Diment <[EMAIL PROTECTED]> wrote: > > On 14 May 2008, at 18:43, Andreas Marienborg wrote: >> >> I would say that making sure the deps are correct would not be the job of >> CatalystX::Installer, but the developer of the app. >> > > Yes, but it's useful ^W essential to let the dev team know when they've > stuffed up. > > >> What I hope CatalystX::Installer will be, is something that I can use in >> my apps to make them easier to set up for people installing the app. >> >> This for me includes: >> >> - dependency handling >> any deps the app needs, that isn't available, or the wrong version should >> be installed / helped installed. For instance, a debian user might want >> suggestions for debian packages to install (quite large scope :p) For me it >> should not infer deps automaticly at this time, that the developer should do >> before releasing his app. >> > > yep, local:lib or par i'm not sure which. Someone else can answer this one. > > >> - app configuration >> Databases, paths, etc. This needs to be very customizable/pluggable. For >> instance in easycms2, I have a config setting for what resizes to make of >> pictures. It would be classy if I could easily map this to some webform >> using CatalystX::Installer :p >> > > +1 > >> - schema deployment / upgrades >> Deploy or upgrade the given database-configuration. This sort of infers >> that the CatalystX::Installer also can be used for upgrades :p >> > > > hmm, scope creep > >> - example configurations >> For apache, lighty, nginx, perlbal(?), http-server, fastcgi etc. >> Perhaps it could even go as far as trying to put config under the propper >> /etc/apache/conf-enabled or whatever (this becomes distro-specific, and >> probably needs to be pluggable) >> > > yep, sounds fine for a prototype > >> - Running tests. >> This I think is a cool idea, to optionally run tests against the finished >> setup. The author should perhaps specify which tests to run >> >> > > and the name of the server to run them against. > >> - andreas >> > > Thanks for the input. > > _______________________________________________ > List: Catalyst@lists.scsys.co.uk > Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst > Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ > Dev site: http://dev.catalyst.perl.org/ > _______________________________________________ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/