[pygtk] All-in-one installer (was Re: Packaging pygtk and friends as eggs)

Stephen George steve_geo at optusnet.com.au
Wed Apr 28 12:21:14 WST 2010

Hi John,

On 27/04/2010 11:21 AM, John Stowers wrote:
>     Not sure if I missed something, .. but what do you mean by an all
>     in one
>     installer?
>     I read it as you download one package from http://www.pygtk.org
>     and you
>     would get pyGTK, pyCairo, pyGObject installed as one monolithic
>     package.
>     I ask as I have previously put an NSIS wapper around GTK runtime,
>     pyGTK,
>     pyCario, pyGObject installers before, so the one setup.exe package
>     fires
>     off  4 separate installers, you still get 4 installation processes
>     happening (and 4 sets of confirmation screens) within the bundle,
>     but I
>     don't think that is what your talking about when you say all-in-one
>     installer.
> Well I would be satisfied with that initially, an installer that just 
> go and executes the other installers in turn. Considering only this 
> meta-installer there is still room for improvement from the basic 
> "install the runtime + pygtk etc". For example, this meta-installer 
> should consider
My wrapper doesn't do much thinking, .. it offers a selection of 
components for installation and leaves it to the user to think (uncheck 
option or leave checked) - this could be improved.

>  * is there already GTK in the path, and what version
 From the GTK runtime installers I've played with I have found they put 
an entry in the registry with fields for path and version. - I think 
this is probably the way to go, get the gtk version out of registry, 
check it exists on HD, then pre-select to install GTK if the packaged 
GTK is newer.

I have found a number of users prefer not to have GTK runtime on the 
path - instead running an .cmd launcher for their program that 
temporarily puts gtk runtime on the path (for that process), till their 
program ends.

I have been using the runtime from
I am starting to wonder if you are talking about another gtk runtime 
bundle as a better option ?, such as from 

>  * should it install python too
I did have python bundled with the installer I had created, it adds a 
bit of bulk to the installer, and pre-supposes which version of python a 
user wants.
(possibly not an issue someone who want to control such things probably 
wont use the all-in-one installer), but definitely option.

>  * what if the user already has pygtk etc installed
If there is a way to detect pygtk from the installer I guess we can 
pre-select the option as appropriate.

In another installer I made I called out to a python script to discover 
if pyGTK etc is installed and what version, however this causes a pause 
in the installer as the python runtime loads, and can be perceived as 
the installer freezing. maybe can probe for certain files existing in 
the python installation itself to satisfy the test.

>  * possible more...
Yes, I'm sure the possible scenarios and options to think about will 
grow once the idea of this installer gets pushed around more.

> However, we both recognise that there is much else that could be done, 
> I dont know if anyone else has investigated how much work it is to get 
> rid of the 4 confirmation screens (does setuptools create installers 
> that can be run with no user intervention?)
 From the little research I had done trying to get setuptools installers 
to run in quiet/silent mode, it seems unlikely

> or to combine them all into one in another safer manner.
Unsure about this option, haven't investigated

> What are your thoughts?

My only other thought, is the solution needs to support both 32 and 64 
bit windows/python/gtk++ , it seems nsis have supported 64bit for a 
couple of years, but I've never tried that out.

So the question: Is nsis the best solution, or should we be looking 

Do you want to me to post my nsis installer script somewhere.

- Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.daa.com.au/pipermail/pygtk/attachments/20100428/1fb028e1/attachment.htm 

More information about the pygtk mailing list