Ideas for installer

Hey, I'm new to this, found about it as part of the Summer
of Code
project. I do have quite a bit of Perl experience, though. I
was
wondering: what do you think needs to be added to or changed
in the
installer?

On Wed, 26 Mar 2008, wandersoucsd.edu wrote:
> what do you think needs to be added to or changed in
the installer?

Have you tried it?  :}

On Mar 26, 2008, at 10:49, wandersoucsd.edu wrote:

> Hey, I'm new to this, found about it as part of the
Summer of Code
> project. I do have quite a bit of Perl experience,
though. I was
> wondering: what do you think needs to be added to or
changed in the
> installer?

Thanks for writing, wanderso (if that is your real name ).

I'm sure what Scott meant to say, in his reply, was:

Thank you for taking an interest in our little corner of the
open- 
source universe. If you're really interested in helping to
improve the  
Bricolage installer, we're really interested in helping you
to do it!

Now, for those of you on the list who have experienced the
pain of a  
Bricolage install, please do chime in now with how you think
the  
installer could/should be improved! You need to do it now,
because  
Google Summer of Code applications, such as what wanderso
might  
submit, are due on in just three days. So make your ideas
and thoughts  
available now!

Okay, back to your question:

The problem with the the Bricolage installer is that it
sucks. It  
sucks ass. Royally. It needs to be replaced with something
that sucks  
less.

I realize that's not very helpful, so let me explain what
the  
installer does, and why this one sucks.

Bricolage has a number of external dependencies, primarily
Perl,  
PostgreSQL or MySQL and Apache + mod_perl. Each has version 

requirements that must be met. Furthermore, there are some
optional  
dependencies that need to be detected and taken advantage of
(e.g.,  
SSL support in Apache). If these dependencies are not met,
the  
installer needs to give the user enough information to make
it easy  
for them to install them. The current installer does an
adequate job  
of detecting this stuff, but provides precious little
information on  
what users should do in the event that such dependencies are
not  
satisfied. Ideally it would detect the OS and suggest the
appropriate  
packages/ports/binaries, as well as offer links for those
who are  
inclined to compile from source.

Next, there are a shitload of CPAN modules that need to be
installed.  
Bricolage is not itself distributed via CPAN, but the
current  
installer uses CPAN.pm to install the dependencies. Here,
too, there  
are optional modules, such as Net::SSH. The biggest problems
people  
have installing Bricolage are getting the CPAN dependencies
installed,  
especially because of the optional CPAN modules, many of
which are  
very hard to install (Net::SSH requires, through its own
dependencies,  
the Math::Pari library, which only Sysadmin gods know how to
get  
working properly). I really have no idea how to make this
better,  
though it might help to switch to CPANPLUS. I believe that
Sam Tregar  
has had some ideas in the past, however, which led him to
found the  
matchstick project, though I don't believe anything has yet
been done  
with it.

   http://u
se.perl.org/~samtregar/journal/21989

If you wanted to work on that, and plug it into Bricolage,
that would  
be fantastic. Sam (cc'd here) has said in the past that he'd
be  
willing to co-mentor a student on a project like this, as it
would  
benefit both Bricolage and Krang, and potentially other
large-scale  
Perl applications (the RT installer is ass, too).

Next, Bricolage builds its database. It asks the user lots
of  
questions in order to get the database baack-end, the super
username,  
the new username, etc. It then uses psql or mysql to build
the  
database, and then uses the DBI to set the appropriate
permissions.  
The scripts that do this are probably okay, if ugly, but
this does  
remind me that it would be truly ideal if the Bricolage
installer  
could take a whole bunch of command-line arguments instead
of asking a  
bunch of bloody questions. Some work has been done on this
to allow  
environment variables and OS-specific defaults, IIRC, but
it's pretty  
ugly. It needs some love.

The next thing Bricolage does is to install itself. This is
fairly  
straight-forward, using a Makefile.PL to do most of the
work.

And finally, if it's an existing version of Bricolage that's
being  
upgraded, the installer determines what upgrade scripts need
to be run  
and then runs them with the appropriate permissions. (Side
note: You  
need to be careful to suid to an appropriate user when doing
database  
stuff, because certain moronic OS distributions that shall
here remain  
nameless install PostgreSQL packages that default to IDENT 

authentication. This goes for creating the database as well
as for  
running the upgrade scripts.)

The current installer is managed via a Makefile, and uses
Perl scripts  
to collect information, store it in Data:umper-fo
rmatted files so  
that other scripts can read in the information to do their
things. It  
all feels very Perl 4 to me, in all honesty (sorry Sam), and
needs  
help. Furthermore, I think that make is pretty evil, and
will get in  
the way of an eventual port to Windows.

Thinking about this, however, I think that a lot of the
stuff we have  
in place in the current installer is pretty good, so rather
than a  
complete rewrite or replacement, as I've though was required
in the  
past, I think that it just needs a lot of updating,
refactoring, and  
love.

To that end, leaving aside matchstick (Sam, please chime in
here with  
how you think it could fit in), the things I think primarily
need to  
be done are:

  * Replace the Makefile with a Perl script that reads in a
config  
file (YAML?) and an OS-specific config file

  * The install script should support a robust command-line
interface,  
so that installation of Bricolage can be scripted to run
unattended.  
That means that we have reasonable defaults in the config
files, and  
that there be corresponding command-line options to change
those  
settings.

  * The various Perl scripts that do much of the work of the
 
installation should be completely refactored and brought
up-to-date  
for Perl best practices. They're just hideous. They should
probably  
use Perl modules that provide the configuration data they
need, rather  
than `do`ing Data:umper-fo
rmatted files created by the main  
installer script. They should also move as much of their
processing as  
possible into Perl modules -- there is a lot of duplication
there.  
Perhaps they can take advantage of my App::Info modules, for
example  
(which were themselves inspired as refactorings of the
`inst/ 
required.pl` script).

  * Lots more information should be provided to users when
things go  
wrong, when dependencies aren't met, etc., with advice for
what to do  
about the problems.

So, to summarize, the installer should:

  * Be easy to use. Bricolage should be easy to install!
  * Should provide feedback and advice
  * Should be easy to modify and improve (modularized!)

Anyway, that's my executive summary. Please, those of you on
the list  
who have experienced the pain of a Bricolage installation
and have  
your own ideas for what needs to be done, chime in!

And wanderso, thanks again for your interest and please do
feel free  
to write back to the list with any questions and/or comments
you might  
have.

Best,

David

On Thu, 27 Mar 2008, David E. Wheeler wrote:
> I'm sure what Scott meant to say, in his reply, was:
>
> Thank you for taking an interest in our little corner
of the open-source 
> universe. If you're really interested in helping to
improve the Bricolage 
> installer, we're really interested in helping you to do
it!
>
> Now, for those of you on the list who have experienced
the pain of a 
> Bricolage install, please do chime in now with how you
think the installer 
> could/should be improved!

Whatever