Re: Proposal: buildout-based Plone Installer for Windows (PLIP #227)

Sidnei da Silva wrote:
> Hi all,
> 
> I've wrote some of my ideas for the buildout-based Plone Installer
> for Windows into PLIP #227 [1].

Thanks for looking at this, Sidnei!

> I highly recommend that you read and comment on it. I am holding up 
> starting on the implementation until I can get a more concrete view
> of how things will look like. I'm mostly concerned about how/if 
> pre-compiled packages should be shipped and about upgrades. For 
> example, are people really expected to backup and manually merge
> their buildout.cfg when upgrading to a newer version of the
> installer? How does that work on the Unified Installer?
> 
> [1] http://plone.org/products/plone/roadmap/227

I think if at all possible, the Windows installer should be as close as
possible to the Unified one and the template you get from 'paster create
-t plone3_buildout'. That massively simplifies documentation and helps
people get a common starting point.

I'll try to answer your other questions here:

> Should the Installer for Windows be able to be uninstalled? That is
> when it is installed, should it create an entry in 'Add/Remove
> Programs' on Windows?  My suggestion is that it should not, for two
> reasons: 1. That could cause confusion with multiple installs. 2.
> When uninstalling, lots of cruft could be left behind.

I think people have an expectation that things they install get an 
uninstall entry, even if it does leave some cruft. Ideally, I think we 
should have an uninstall entry that was given a name to uniquely 
identify it in case of multiple installs (e.g. list the folder name), 
with a warning at the end that said "the files in C:\... were not 
removed since they may contain data you want to keep; you can delete 
them if you want.".

If this is a lot of work, though, it's probably secondary since the 
installation would be self-contained to a single folder and thus easily 
deletable.

> Should the Installer for Windows ship with a working buildout.cfg and override
> existing ones? My suggestion is that it should not. Otherwise we risk
> overwriting a customized buildout.cfg. Alternatively, we could ship
> with ZopeSkel pre-installed and have scripts for generating a
> buildout.cfg.

I don't really follow... I think shipping with ZopeSkel installed into 
the Python version that comes with the installer is important since it 
lets people create new buildouts, use the other templates and local 
commands.

However, when you've finished the installer, I think you should have a 
working buildout - one with a proper buildout.cfg that you can build on 
to install new products or change the configuration.

I think overwriting a custom buildout.cfg is only really an issue for 
re-installations. In this case, perhaps we can ask the user and/or save 
the old file with a different name as a backup?

Or am I missing something?

> Should the .buildout cache be shared between different
> installs? My suggestion is that it should. Otherwise if you run the
> installer multiple times (see first entry) you would end up with
> multiple copies of the .buildout cache, using a lot of space.

Completely agree. Shared caches are very useful. I'd set a default.cfg 
like this:

[buildout]
download-directory = .../downloads
download-cache = .../downloads
eggs-directory = .../eggs
zope-directory = .../zope

Cheers,
Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/