Prev: unit testing a routine that sends mail
Next: What happened to pyjamas?
From: Ryan Kelly on 19 Feb 2010 16:32
On Fri, 2010-02-19 at 11:08 -0800, T wrote:
> On Feb 18, 7:19 pm, Ryan Kelly <r...(a)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
ryan(a)rfk.id.au | http://www.rfk.id.au/ramblings/gpg/ for details

From: CM on 19 Feb 2010 23:55
On Feb 19, 4:28 pm, Ryan Kelly <r...(a)rfk.id.au> wrote:
> On Thu, 2010-02-18 at 20:32 -0800, CM wrote:
> > On Feb 18, 7:19 pm, Ryan Kelly <r...(a)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.
>
>    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. :D

Che
From: T on 20 Feb 2010 11:38
On Feb 19, 4:32 pm, Ryan Kelly <r...(a)rfk.id.au> wrote:
> On Fri, 2010-02-19 at 11:08 -0800, T wrote:
> > On Feb 18, 7:19 pm, Ryan Kelly <r...(a)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 Kellyhttp://www.rfk.id.au |  This message is digitally signed. Please visit
> r...(a)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!
From: Aahz on 24 Feb 2010 18:05
In article <mailman.2807.1266614926.28905.python-list(a)python.org>,
Ryan Kelly <ryan(a)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 (aahz(a)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
From: Ryan Kelly on 24 Feb 2010 18:30
On Wed, 2010-02-24 at 15:05 -0800, Aahz wrote:
> In article <mailman.2807.1266614926.28905.python-list(a)python.org>,
> Ryan Kelly <ryan(a)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...


Ryan

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

First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: unit testing a routine that sends mail
Next: What happened to pyjamas?