[PyQt] Inter-office distribution/installation of packages/modules

Erik Janssens Erik.Janssens at conceptive.be
Sun Jul 3 10:31:11 BST 2011


That's indeed an interesting approach.  We only update a single
egg (that egg than contains our app and the libraries that change
most often).  The application is thus able to update itself and
restart itself with some kind of bootstrapper.  The egg itself
is in the User Data folder, so that any user is able to update
its app.

Don't you have issues with permissions and virus scanners and
such when updating DLL's and things in C:\Program Files\... ?

On Sat, 2011-07-02 at 18:43 +0000, Demetrius Cassidy wrote:
> Basically the updater is a separate python program, built using
> twisted. It is self contained, and can update any file on our project.
> The client queries the server for the client version, and if it's out
> of date, it launchers the patcher and quits. It's not part of py2exe
> itself, though it's packaged into a self contained exe with py2exe,
> just like our program.
> 
> 
> For our client, many dlls are updated on a regular basis for bug
> fixes. But you can update python code, since it's just stored in
> a .zip file (just have the updater dl the updated zip file and copy it
> over).
> 
> 
> On Tue, Jun 28, 2011 at 6:41 PM, Erik Janssens
> <Erik.Janssens at conceptive.be> wrote:
>         that's interesting, how do you handle the auto update with
>         py2exe ?
>         which part of the app gets updated ?
>         
>         On Fri, Jun 17, 2011 at 12:58 AM, Demetrius Cassidy
>         <dcassidy36 at gmail.com> wrote:
>         > We have an app which must be redistributed to multiple
>         groups, with 40+
>         > users and py2exe is the reason we are able to do this.
>         Gui2exe makes the
>         > building simpler.
>         >
>         > If you need to debug, you won't be running the bundled app,
>         so I don't see
>         > why you would need to so much other than making sure it runs
>         when bundled.
>         >
>         > If your packages are making assumptions on how your
>         enviroment is set up,
>         > IMO I think that is wrong and will only lead to problems
>         down the road.
>         >
>         > And the last thing, is that we have an auto updater, so new
>         releases only
>         > require a rebuild and push to the sever.
>         >
>         > On Jun 16, 2011 2:58 PM, "Erik Janssens"
>         <Erik.Janssens at conceptive.be>
>         > wrote:
>         >> Hi,
>         >>
>         >> I would not agree with using Py2exe, while the idea is
>         nice, we have had
>         >> many
>         >> issues with it, basically for 2 reasons :
>         >>
>         >> - it's dependency analysis, in combination with automatic
>         updates : if
>         >> your
>         >> update
>         >> uses a part of a package that was not used in the original
>         package, you
>         >> need to
>         >> redeploy everything, instead of just the part of your app
>         that you update
>         >>
>         >> - it changes the 'environment' your app runs in (eg
>         sys.path), while it is
>         >> possible
>         >> to work around it in your app, you need to make sure that
>         none of the
>         >> packages
>         >> you use make certain assumption on the environment
>         >>
>         >> This combination means that in order to properly test your
>         application,
>         >> you
>         >> need
>         >> to continuously rebuild your app with py2exe, and run it.
>         notice some
>         >> error,
>         >> fix it,
>         >> rebuild, etc. This takes far too much time.
>         >>
>         >> So what we did was :
>         >>
>         >> - build a custom python distro with all 'binary' packages
>         included we need
>         >> that
>         >> does not depend on registry settings and does not conflict
>         with
>         >> potentially other
>         >> pythons installed on the machine, so we can develop, test
>         and deploy in
>         >> exactly the same environment
>         >>
>         >> http://www.python-camelot.com/cpd.html
>         >>
>         >> - build an auto-update & monitoring service around it that
>         was integrated
>         >> with
>         >> setuptools and buildbot
>         >>
>         >>
>         >>
>         >>
>         http://www.conceptive.be/downloads/camelot/doc/sphinx/build/advanced/deployment.html
>         >>
>         >> we serve more than 100 sites with this combination.
>         updating the app is
>         >> just
>         >> pressing the buildbot button which will run unittests,
>         build a package and
>         >> push
>         >> it to the end users.
>         >>
>         >> Regards,
>         >>
>         >> Erik
>         >>
>         >> On Thu, Jun 16, 2011 at 7:13 PM, James Polk
>         <jpolk5001 at yahoo.com> wrote:
>         >>
>         >>>
>         >>> Apologies if this is too off-topic,....but I'd like to
>         propose a
>         >>> discussion
>         >>> of
>         >>> how-to's and where-fore's regarding distributing python
>         modules to a
>         >>> user-base.
>         >>>
>         >>> Recently, I've been using Mark Hammond's excellent pywin32
>         packages,
>         >>> along with NumPy and PyOpenGL,etc. I have a user-base of
>         approx 40 or so,
>         >>> who will need these packages added to their base Python
>         install.
>         >>>
>         >>> Rather than visit 40 separate desktops, I used "pip" (pip
>         freeze) to get
>         >>> a
>         >>> short list of packages outside the base install, and wrote
>         an app that
>         >>> each
>         >>> user can run to find what's missing, and initiate the
>         appropriate
>         >>> install,etc.
>         >>> Then I realized that "pip" itself was a 3rd party
>         package!..DOh!
>         >>>
>         >>> I can fall back and use "help('modules')" to generate a
>         new list, but it
>         >>> lists
>         >>> *everything* in the install,...usable but not as succinct,
>         for pywin32
>         >>> for
>         >>> example,
>         >>> it lists about a dozen things with a form of "win32" in
>         them,...and
>         >>> doesn't
>         >>> appear
>         >>> to return the real package name that is associated with
>         the binary
>         >>> installation file.
>         >>>
>         >>> Surely these issues are fairly common phenomena in many
>         workplaces,etc...
>         >>> I'm wondering if anybody out there has any knowledge,
>         tips, or
>         >>> experiences
>         >>> regarding this issue that they can share.
>         >>>
>         >>> I've found "moduleFinder", and various ideas about
>         searching "sys.path",
>         >>> pkgutils, but nothing else that seems like a long term
>         viable and/or
>         >>> elegant solution.
>         >>>
>         >>> Thoughts anyone?
>         >>>
>         >>> Thanks,
>         >>> -Jim
>         >>>
>         >>>
>         >>>
>         >>> _______________________________________________
>         >>> PyQt mailing list PyQt at riverbankcomputing.com
>         >>> http://www.riverbankcomputing.com/mailman/listinfo/pyqt
>         >>>
>         >
> 




More information about the PyQt mailing list