[pygtk] All-in-one installer (was Re: Packaging pygtk and friends as eggs)
steve_geo at optusnet.com.au
Wed Apr 28 12:21:14 WST 2010
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
> I read it as you download one package from http://www.pygtk.org
> and you
> would get pyGTK, pyCairo, pyGObject installed as one monolithic
> I ask as I have previously put an NSIS wapper around GTK runtime,
> pyCario, pyGObject installers before, so the one setup.exe package
> 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
> 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
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
(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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the pygtk