[Catalyst] Suggestions for CatalystX::Installer
Paul Cain
fat.perl.hacker at gmail.com
Sat May 17 11:24:31 BST 2008
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 <diment at gmail.com> 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 at 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/
>
More information about the Catalyst
mailing list