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 <dcassid...@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.janss...@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 <jpolk5...@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@riverbankcomputing.com >>> http://www.riverbankcomputing.com/mailman/listinfo/pyqt >>> > _______________________________________________ PyQt mailing list PyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt