Wayne Watson wrote: > I've considered it, but it's way too time consuming to work out the > details. I spent a week some time ago dealing with a simple test > program, maybe 10 lines of code, trying to get it to work, which I think > I did. I just need to work what I've got.
There is a lot to be said for something that works already. However, I think it is generally a bad idea to distribute software based on python that relies on the standard python install with particular packages -- this will only work if you assume that that machine will not use python for anything else -- if two pieces of software both do this, but need different versions of packages, you are guaranteed breakage. RedHat did it with python way back when (I have no idea if they've changed that -- but it was pain). ESRI (GIS system) delivers the standard Windows Python version something with its GIS tools, and things break if you upgrade parts of it. Apple uses its system Python for some of its admin tools, and again, relies on who knows which versions of which packages. All this points to delivering python to your users separately from the standard install. If it's one app, use py2exe, py2app, pyInstaller, bbfreeze, whatever. If it's a collection of apps, you may want to built it on a custom python install, and/or maybe virtualenv. Anyway, if you know your users, and know they will, for sure, not use Python for anything else, then it's not a problem, but I think it's hard to know that. py2exe can be a pain, but it's usually short term pain -- once you have it working for your project, it keeps working (untill you add a new package anyway...) -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [email protected] _______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
