Upgrading Py2exe App

[T]

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]

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 Kelly
http://www.rfk.id.au | This message is digitally signed. Please visit
(e-mail address removed) | http://www.rfk.id.au/ramblings/gpg/ for details


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEABECAAYFAkt92RAACgkQfI5S64uP50qmYgCgi0xUqW68n0OSRSlggHQgJ5SL
QZEAnR2ZOa/P3ZxzMbTQ4nNITED38mbf
=dmtE
-----END PGP SIGNATURE-----

 

[CM]

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]

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
(e-mail address removed)        |  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]

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.


Ryan


--
Ryan Kelly
http://www.rfk.id.au | This message is digitally signed. Please visit
(e-mail address removed) | http://www.rfk.id.au/ramblings/gpg/ for details


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEABECAAYFAkt/AoAACgkQfI5S64uP50oS4gCggL73kO/YkX5f/l1NCb+mDGl7
6TAAn2nGBGduXbCOA9lFf/eyg+pRovJt
=5eT8
-----END PGP SIGNATURE-----

 

[Ryan Kelly]

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
(e-mail address removed) | http://www.rfk.id.au/ramblings/gpg/ for details


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEABECAAYFAkt/A1wACgkQfI5S64uP50preQCgiyYoJNGuSS65ofaohdoAhgzd
+VkAoIA3oMaDbRSFMKTmCVB/1qj1yWuX
=sGq4
-----END PGP SIGNATURE-----

 

[CM]

Thanks


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.


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.


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.

   Ryan

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.

Che

 

[T]

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 Kellyhttp://www.rfk.id.au |  This message is digitally signed. Please visit
(e-mail address removed)        |  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]

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
(e-mail address removed) | http://www.rfk.id.au/ramblings/gpg/ for details


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEABECAAYFAkuDcW4ACgkQfI5S64uP50ofrACdGoc470Z4zPh0yU4u3+fYKDks
4SEAoMgGU204t4EHkmJnA6/GCqx5ZyI+
=VVi1
-----END PGP SIGNATURE-----

 

[Aahz]

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 ([email protected]) <*> 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]

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...


Ryan

--
Ryan Kelly
http://www.rfk.id.au | This message is digitally signed. Please visit
(e-mail address removed) | http://www.rfk.id.au/ramblings/gpg/ for details


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEABECAAYFAkuFtnsACgkQfI5S64uP50q+FACfcWvokNtQVLDDAOYM3NdiCtKW
77wAniJUXUEFI1DSr0X+V3sjs+6HKURd
=RZC/
-----END PGP SIGNATURE-----

 

[Aahz]

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.
--
Aahz ([email protected]) <*> 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