[Catalyst-dev] 2nd Draft Proposal for the Generic GUI for installing Catalyst Apps(CatalystX::Installer)

[Marcus Ramberg]

On 7. april. 2008, at 09.46, Paul Cain wrote:
> Here is the second draft of my proposal for the Generic GUI for  
> installing
> Catalyst Apps, which I have decided to call CatalystX::Installer.
>
> Thanks to everyone who provided feedback on my first draft.
>
> Again, questions/comments/etc are welcome.
>

Hi Paul.

Your proposal looks quite good. A few comments below

>
> my $preferred_config_type=CatalystX::Installer::Forms::SelectionList- 
> >new();
> $preferred_config_type->add({
>    'YAML' => "YAML",
>    'INI' => 'Windows INI File',
>    'XML' => 'XML',
> });
>

It might make sense to build the Forms stuff on top of HTML::FormFu.

>
> 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 make sure all of the  
> dependencies
> are installed(and prompts the user if not). Next, it verifies that the
> program runs correctly by doing the tests. After that, it can  
> display the
> GUI setup, get the information, create a configuration file in a  
> chosen
> format, and install.
>
>
> The second solution involves having a dist-file from  
> CatalystX::Installer
> in the server's root directory and myapp_setup.pl in the cgi-bin. The
> advantage here is that existing Catalyst applications do not need to  
> be
> modified in order to use CatalystX::Installer. The server  
> administrator can
> install the module on his server and then use it to install existing
> Catalyst applications. The server administrator can then do  
> something like:
>
>
> $ perl myapp_setup.pl catalysty_app.tar.gz
>
>
> What this would do is extract the application to a temporary  
> location(/tmp
> on *nix, or B:\Users\paul\AppData\Local\Temp on Windows), check the
> dependencies in Makefile.PL and prompt the user if they are missing,  
> run the
> application's tests to verify that it works correctly, display the  
> GUI, get
> the configuration information, write that information to a file in a  
> chosen
> format, and install. The server administrator could also customize
> CatalystX::Installer's form in the way described earlier if he or  
> she so
> chose to.
>

Of these two, I prefer the first approach, as it's more in line with  
how Catalyst does other things.

[ ... ]
>
>
>
>   *Project Schedule*
>
>   -
>
>   May 26 – Project Begins
>
>   -
>
>   Monday, June 9 – Alpha 1 released – APIs for the basic program are
>   complete
>
>   -
>
>   Monday, June 30-- Alpha 2 released – User extension APIs are  
> complete
>
>   -
>
>   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
>
>
> *References and Likely Mentors*
>
> Marcus Ramberg was the one who originally suggested this idea to me  
> on the
> psoc mailing list.
>
> Eric Wilherm and Kieren Diment helped me to refine my ideas and  
> proposal.
> Also, I took the name suggested by Kieren.
>

If you want, I'd be happy to mentor this project.

Good luck with the process, and don't hestiate to contact me or any of  
the other catalyst developers on IRC again. Note that a lot of us are  
always connected (using screen or irc), so we get your messages even  
if we might be away from our computers, and are slow to respond)

Marcus