Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Upgrading Py2exe App

18 views
Skip to first unread message

T

unread,
Feb 18, 2010, 10:46:55 AM2/18/10
to
I have a Python app which I converted to an EXE (all files separate;
single EXE didn't work properly) via py2exe - I plan on distributing
this and would like the ability to remotely upgrade the program (for
example, via HTTP/HTTPS). Looks like it's not just the EXE that I
will need need to replace (DLLs, the library.zip, etc.). What would
be the best way to go about doing this?

Ryan Kelly

unread,
Feb 18, 2010, 7:19:32 PM2/18/10
to T, pytho...@python.org


I've been working on an auto-update framework for my own frozen apps,
you might find it useful:

http://pypi.python.org/pypi/esky

Docs are a little scarce at the moment, the next release will hopefully
come with a short tutorial (as well as support for cx_freeze and maybe
py2app, depending on how adventurous I'm feeling).


Cheers,

Ryan

--
Ryan Kelly
http://www.rfk.id.au | This message is digitally signed. Please visit
ry...@rfk.id.au | http://www.rfk.id.au/ramblings/gpg/ for details

signature.asc

CM

unread,
Feb 18, 2010, 11:32:08 PM2/18/10
to
On Feb 18, 7:19 pm, Ryan Kelly <r...@rfk.id.au> wrote:
> On Thu, 2010-02-18 at 07:46 -0800, T wrote:
> > I have a Python app which I converted to an EXE (all files separate;
> > single EXE didn't work properly) via py2exe - I plan on distributing
> > this and would like the ability to remotely upgrade the program (for
> > example, via HTTP/HTTPS).   Looks like it's not just the EXE that I
> > will need need to replace (DLLs, the library.zip, etc.).  What would
> > be the best way to go about doing this?
>
> I've been working on an auto-update framework for my own frozen apps,
> you might find it useful:
>
>  http://pypi.python.org/pypi/esky
>
> Docs are a little scarce at the moment, the next release will hopefully
> come with a short tutorial (as well as support for cx_freeze and maybe
> py2app, depending on how adventurous I'm feeling).
>
>   Cheers,
>
>      Ryan


This looks pretty interesting and useful.

Just to help me understand it a bit more: what is it that users will
download from some web page in order to initially get the py2exe'd app
on their system? Is it "really" an "esky", with the app's .exe file
inside it (but the esky is named the same as the app)? And then when
they want to update, the app's code calls the esky class to do the
work of swapping out the appropriate .exe file? Something like this?
Sorry if I am confused as to how this works.

Would this also work if one used InnoSetup to install the exe on the
user's system?

Thanks,
Che

T

unread,
Feb 19, 2010, 2:08:53 PM2/19/10
to
On Feb 18, 7:19 pm, Ryan Kelly <r...@rfk.id.au> wrote:
> On Thu, 2010-02-18 at 07:46 -0800, T wrote:
> > I have a Python app which I converted to an EXE (all files separate;
> > single EXE didn't work properly) via py2exe - I plan on distributing
> > this and would like the ability to remotely upgrade the program (for
> > example, via HTTP/HTTPS).   Looks like it's not just the EXE that I
> > will need need to replace (DLLs, the library.zip, etc.).  What would
> > be the best way to go about doing this?
>
> I've been working on an auto-update framework for my own frozen apps,
> you might find it useful:
>
>  http://pypi.python.org/pypi/esky
>
> Docs are a little scarce at the moment, the next release will hopefully
> come with a short tutorial (as well as support for cx_freeze and maybe
> py2app, depending on how adventurous I'm feeling).
>
>   Cheers,
>
>      Ryan
>
> --
> Ryan Kellyhttp://www.rfk.id.au |  This message is digitally signed. Please visit
> r...@rfk.id.au        |  http://www.rfk.id.au/ramblings/gpg/for details
>
>  signature.asc
> < 1KViewDownload

Thanks Ryan..this looks like it could be what I'm looking for, but I'm
still a bit unsure of how exactly how it works. Do you happen to have
an idea approx when the next release w/ tutorial will be out?

Ryan Kelly

unread,
Feb 19, 2010, 4:28:37 PM2/19/10
to CM, pytho...@python.org
On Thu, 2010-02-18 at 20:32 -0800, CM wrote:
> On Feb 18, 7:19 pm, Ryan Kelly <r...@rfk.id.au> wrote:
> > On Thu, 2010-02-18 at 07:46 -0800, T wrote:
> > > I have a Python app which I converted to an EXE (all files separate;
> > > single EXE didn't work properly) via py2exe - I plan on distributing
> > > this and would like the ability to remotely upgrade the program (for
> > > example, via HTTP/HTTPS). Looks like it's not just the EXE that I
> > > will need need to replace (DLLs, the library.zip, etc.). What would
> > > be the best way to go about doing this?
> >
> > I've been working on an auto-update framework for my own frozen apps,
> > you might find it useful:
> >
> > http://pypi.python.org/pypi/esky
> >
>
>
> This looks pretty interesting and useful.

Thanks :-)

> Just to help me understand it a bit more: what is it that users will
> download from some web page in order to initially get the py2exe'd app
> on their system? Is it "really" an "esky", with the app's .exe file
> inside it (but the esky is named the same as the app)?

Currently, it's just a zip file with the frozen app in it, which the
user unzips to wherever they want the app. When unzipped it looks like
this:

myapp.exe <-- actually the esky bootstrap exe
myapp-X.Y.Z.win32/
myapp.exe <-- the actual frozen app as produced by py2exe
python26.dll
...etc...

This could easily be wrapped in an installer - the important thing is
just that the files end up on the user's machine in the expected
directory structure.

> And then when
> they want to update, the app's code calls the esky class to do the
> work of swapping out the appropriate .exe file? Something like this?

Yes. The idea of having a "bootstrapping exe" is that actual
application code can be swapped out without having to overwrite the
executable file. As long as you don't change python versions, this
allows updates to be safe against system crashes, even on platforms
without atomic file replacement.

So the frozen app does this in a background thread:

Esky(sys.executable,"http://my.updates.com").auto_update()

And it hits the given url, grabs the latest zipfile, downloads and
unpacks and atomically places it into the application directory. Et
viola, your app is at the latest version.

From the packager's point of view, you run the "bdist_esky" distutils
command to generate the zipfile containing your latest version, then
simply upload it to your server.

> Would this also work if one used InnoSetup to install the exe on the
> user's system?

Yes, absolutely - in fact I plan to do this myself at some stage. All
that's required is that the files end up in the expected directory
structure.

signature.asc

Ryan Kelly

unread,
Feb 19, 2010, 4:32:16 PM2/19/10
to T, pytho...@python.org
On Fri, 2010-02-19 at 11:08 -0800, T wrote:
> On Feb 18, 7:19 pm, Ryan Kelly <r...@rfk.id.au> wrote:
> > On Thu, 2010-02-18 at 07:46 -0800, T wrote:
> > > I have a Python app which I converted to an EXE (all files separate;
> > > single EXE didn't work properly) via py2exe - I plan on distributing
> > > this and would like the ability to remotely upgrade the program (for
> > > example, via HTTP/HTTPS). Looks like it's not just the EXE that I
> > > will need need to replace (DLLs, the library.zip, etc.). What would
> > > be the best way to go about doing this?
> >
> > I've been working on an auto-update framework for my own frozen apps,
> > you might find it useful:
> >
> > http://pypi.python.org/pypi/esky
> >
> > Docs are a little scarce at the moment, the next release will hopefully
> > come with a short tutorial (as well as support for cx_freeze and maybe
> > py2app, depending on how adventurous I'm feeling).
> >
> Thanks Ryan..this looks like it could be what I'm looking for, but I'm
> still a bit unsure of how exactly how it works. Do you happen to have
> an idea approx when the next release w/ tutorial will be out?


If I punt on the py2app support, I should be able to get it done in the
next 3-4 days. I'll send a quick email to python-list when it's ready.

Here's a rough roadmap of where the project is heading:

v0.4.0: cx_freeze support and a tutorial [the next 3-4 days]
v0.4.1: py2app support [the next 2-3 weeks]
v0.5.0: differential updates using bsdiff [next few months]


Cheers,

Ryan

--
Ryan Kelly


http://www.rfk.id.au | This message is digitally signed. Please visit

signature.asc

CM

unread,
Feb 19, 2010, 11:55:15 PM2/19/10
to

Wow, it sounds great. Good luck with moving forward with it. I'm not
quite ready to release any apps, but as (if?) I come up on that, and
if I plan on updating them, I would love to make use of Esky. Thanks
for doing this. :D

Che

T

unread,
Feb 20, 2010, 11:38:07 AM2/20/10
to
> Ryan Kellyhttp://www.rfk.id.au |  This message is digitally signed. Please visit
> r...@rfk.id.au        |  http://www.rfk.id.au/ramblings/gpg/for details
>
>  signature.asc
> < 1KViewDownload

Excellent - I look forward to giving it a try. Thanks again!

Ryan Kelly

unread,
Feb 23, 2010, 1:10:58 AM2/23/10
to T, pytho...@python.org

Hi All,


As promised I have made a new release of esky, my auto-update
framework for frozen python apps. Details below for those who are
interested.

Cheers,

Ryan


-------------------------------


esky: keep frozen apps fresh

Esky is an auto-update framework for frozen Python applications. It
provides a simple API through which apps can find, fetch and install
updates, and a bootstrapping mechanism that keeps the app safe in the
face of failed or partial updates.

Esky is currently capable of freezing apps with bbfreeze, cxfreeze and
py2exe. Support for py2app is in the works.

The latest version is v0.4.0, with the following major changes:

* added support for freezing with cx_Freeze.
* improved support for freezing with py2exe.
* added ability to set the icon on each executable
(if the chosen freezer module supports it)
* made Esky.cleanup() catch and ignore common errors.
* added support for Python 3 (via distribute's "use_2to3" flag)
* added a brief tutorial and example application
* some backwards-incompatible API changes (see ChangeLog for details)


Downloads: http://pypi.python.org/pypi/esky/0.4.0/

Code, bugs, etc: http://github.com/rfk/esky/

Tutorial: http://github.com/rfk/esky/tree/master/tutorial/


--
Ryan Kelly


http://www.rfk.id.au | This message is digitally signed. Please visit

signature.asc

Aahz

unread,
Feb 24, 2010, 6:05:09 PM2/24/10
to
In article <mailman.2807.1266614...@python.org>,

Ryan Kelly <ry...@rfk.id.au> wrote:
>
>Yes. The idea of having a "bootstrapping exe" is that actual
>application code can be swapped out without having to overwrite the
>executable file. As long as you don't change python versions, this
>allows updates to be safe against system crashes, even on platforms
>without atomic file replacement.
>
>So the frozen app does this in a background thread:
>
> Esky(sys.executable,"http://my.updates.com").auto_update()
>
>And it hits the given url, grabs the latest zipfile, downloads and
>unpacks and atomically places it into the application directory. Et
>viola, your app is at the latest version.

How does this work with a running app? What if the app is a service?
--
Aahz (aa...@pythoncraft.com) <*> http://www.pythoncraft.com/

"Many customs in this life persist because they ease friction and promote
productivity as a result of universal agreement, and whether they are
precisely the optimal choices is much less important." --Henry Spencer

Ryan Kelly

unread,
Feb 24, 2010, 6:30:07 PM2/24/10
to Aahz, pytho...@python.org
On Wed, 2010-02-24 at 15:05 -0800, Aahz wrote:
> In article <mailman.2807.1266614...@python.org>,
> Ryan Kelly <ry...@rfk.id.au> wrote:
> >
> >Yes. The idea of having a "bootstrapping exe" is that actual
> >application code can be swapped out without having to overwrite the
> >executable file. As long as you don't change python versions, this
> >allows updates to be safe against system crashes, even on platforms
> >without atomic file replacement.
> >
> >So the frozen app does this in a background thread:
> >
> > Esky(sys.executable,"http://my.updates.com").auto_update()
> >
> >And it hits the given url, grabs the latest zipfile, downloads and
> >unpacks and atomically places it into the application directory. Et
> >viola, your app is at the latest version.
>
> How does this work with a running app? What if the app is a service?

The changes will only take effect the next time the app is started -
currently there's no support for "hot upgrading" a running app.

Would definitely be an interesting feature though...

signature.asc

Aahz

unread,
Feb 28, 2010, 2:44:44 PM2/28/10
to
In article <mailman.201.1267054...@python.org>,

Ryan Kelly <ry...@rfk.id.au> wrote:
>On Wed, 2010-02-24 at 15:05 -0800, Aahz wrote:
>> In article <mailman.2807.1266614...@python.org>,
>> Ryan Kelly <ry...@rfk.id.au> wrote:
>>>
>>>Yes. The idea of having a "bootstrapping exe" is that actual
>>>application code can be swapped out without having to overwrite the
>>>executable file. As long as you don't change python versions, this
>>>allows updates to be safe against system crashes, even on platforms
>>>without atomic file replacement.
>>>
>>>So the frozen app does this in a background thread:
>>>
>>> Esky(sys.executable,"http://my.updates.com").auto_update()
>>>
>>>And it hits the given url, grabs the latest zipfile, downloads and
>>>unpacks and atomically places it into the application directory. Et
>>>viola, your app is at the latest version.
>>
>> How does this work with a running app? What if the app is a service?
>
>The changes will only take effect the next time the app is started -
>currently there's no support for "hot upgrading" a running app.

From my POV, hot upgrading is less important than solid restart
capabilities, particularly for services. Performing tasks like modifying
the DB schema is also important (not the actual capability, but hooks for
it). E.g., the next time the app starts, it should know that it's been
upgraded.

0 new messages