From Zsolt.Putnoky at alcatel.fr Wed Dec 1 08:27:05 2004 From: Zsolt.Putnoky at alcatel.fr (Zsolt.Putnoky@alcatel.fr) Date: Wed Dec 1 08:27:09 2004 Subject: [Pythonmac-SIG] Problem during installing MySQL module in Python - Other error In-Reply-To: Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 176 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20041201/b48641c4/attachment.gif From rkern at ucsd.edu Wed Dec 1 09:47:53 2004 From: rkern at ucsd.edu (Robert Kern) Date: Wed Dec 1 09:47:59 2004 Subject: [Pythonmac-SIG] python 2.3.4 on Mac OS X 10.3.6 is working - upgraded standard installation In-Reply-To: References: <2B2135FF-4196-11D9-8E30-000A9567635C@redivi.com> Message-ID: <41AD8539.1080202@ucsd.edu> Bob Ippolito wrote: > Once you know where this Makefile is, open it up with your favorite text > editor (probably using sudo). > Navigate to approximately line 98 and replace the two configuration > variables LDSHARED and BLDSHARED with the following: > > LDSHARED= env MACOSX_DEPLOYMENT_TARGET=10.3 $(CC) $(LDFLAGS) -bundle > -undefined dynamic_lookup > BLDSHARED= env MACOSX_DEPLOYMENT_TARGET=10.3 $(CC) $(LDFLAGS) -bundle > -undefined dynamic_lookup This is problematic for extensions that need to use something other than $(CC) to link, specifically C++ and FORTRAN extensions. distutils (and scipy_distutils in the FORTRAN case) splits $LDSHARED on whitespace and substitutes the appropriate tool into the first index. Thus you end up with distutils trying to run commands like c++ MACOSX_DEPLOYMENT_TARGET=10.3 gcc ... etc. -- Robert Kern rkern@ucsd.edu "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From takaanna at hotmail.com Wed Dec 1 11:09:32 2004 From: takaanna at hotmail.com (Paul Taka) Date: Wed Dec 1 11:10:11 2004 Subject: [Pythonmac-SIG] Problem with tkaqua Tkinter and some Kanji unicode values. In-Reply-To: Message-ID: >From: Read Roberts > >graphic UI calls. You might look on the the following news-lists. These >are in Japanese, so I can't read them - please let me know if there is >anything relevant. I can't read Japanese very well too.... (precisely, my app is for learning Japanese vocabulary..) So I can't read this mailing lists. Maybe Japanese input and display is easier with wxPython... Paul From bob at redivi.com Wed Dec 1 14:20:32 2004 From: bob at redivi.com (Bob Ippolito) Date: Wed Dec 1 14:20:41 2004 Subject: [Pythonmac-SIG] python 2.3.4 on Mac OS X 10.3.6 is working - upgraded standard installation In-Reply-To: <41AD8539.1080202@ucsd.edu> References: <2B2135FF-4196-11D9-8E30-000A9567635C@redivi.com> <41AD8539.1080202@ucsd.edu> Message-ID: On Dec 1, 2004, at 3:47 AM, Robert Kern wrote: > Bob Ippolito wrote: > >> Once you know where this Makefile is, open it up with your favorite >> text editor (probably using sudo). >> Navigate to approximately line 98 and replace the two configuration >> variables LDSHARED and BLDSHARED with the following: >> LDSHARED= env MACOSX_DEPLOYMENT_TARGET=10.3 $(CC) $(LDFLAGS) >> -bundle -undefined dynamic_lookup >> BLDSHARED= env MACOSX_DEPLOYMENT_TARGET=10.3 $(CC) $(LDFLAGS) >> -bundle -undefined dynamic_lookup > > This is problematic for extensions that need to use something other > than $(CC) to link, specifically C++ and FORTRAN extensions. distutils > (and scipy_distutils in the FORTRAN case) splits $LDSHARED on > whitespace and substitutes the appropriate tool into the first index. > Thus you end up with distutils trying to run commands like > > c++ MACOSX_DEPLOYMENT_TARGET=10.3 gcc ... etc. Well, that's just stupid! One of two things need to happen: - distutils and scipy_distutils need to be fixed to be able to mangle environment variables before invoking the toolchain - distutils and scipy_distutils need to do something reasonable instead, like replace the $(CC) variable before substitution, not the first word it sees after substitution. This may be an issue for 10.4 though, as the public sources in the WWDC build were a slightly modified 2.3.3 that used this style LDSHARED. I guess the solution in this case is to backport both patches back to 2.3.4 and get a 2.3.5 release cut, which Apple would hopefully pick up if enough bug reports are filed and emails sent :) -bob From bob at redivi.com Wed Dec 1 23:14:16 2004 From: bob at redivi.com (Bob Ippolito) Date: Wed Dec 1 23:14:22 2004 Subject: [Pythonmac-SIG] [ANN] misc scripts Message-ID: <56BD85AC-43E6-11D9-8939-000A9567635C@redivi.com> I've created a little repository for some of the misc. scripts I have lying around that may be of interest: http://svn.red-bean.com/bob/scripts/trunk Here's what's in there at the moment appwhich: finds the executable for a (non-CFM) application.. basically like "which", except it takes application names, creator codes, or CFBundleIdentifiers pywhich: finds a given Python module by import.name on the file system (will choose ".py" if available, otherwise it will return the .pyc or .so) tonative: converts a (hopefully text) file to native line-endings in place md5sum: does what you'd expect it to do, OS X doesn't come with /usr/bin/md5sum - so I wrote one in Python jagpython: sets up a somewhat working "SDK" environment to run a built-for-jaguar Python (installed to /Developer/SDKs/10.2.8/Library/Frameworks/Python). I use this to build 10.2 compatible applications w/ py2app. -bob From kevin at macosx.com Thu Dec 2 08:58:01 2004 From: kevin at macosx.com (kevin parks) Date: Thu Dec 2 08:58:11 2004 Subject: [Pythonmac-SIG] pretty printers, tabnanny and the like Message-ID: i used to. somehow, can't recall exactly... have a python script that i could use to clean up my python code and convert all the tabs spaces and insure that tabs and spaces were not mixed. It may have been tabnanny which use to come as a script and now, annoyingly may be a module, i dunno. but anyway i want something like tabnannny to check AND FIX my messed up files and i don't want to have to do it from the interpreter, i want to be able to do it from the terminal like: % fixthis messy_script.py boom and have my line endings and indents and tabs all fixed. I know that there used to be something like this, then i stupidly started using BBedit and now i don't have it anymore and i just want a thingy that will fix my stupid tabs and spaces. and a pretty printer like perl tidy would be nice too. Anyone know of one of these for python? interestingly i can import tabnanny but if i search for it on my hard drive, it doesn't appear. I have not idea where it is now... cheers, kevin From n8gray at gmail.com Thu Dec 2 10:18:26 2004 From: n8gray at gmail.com (Nathaniel Gray) Date: Thu Dec 2 10:18:29 2004 Subject: [Pythonmac-SIG] [ANN] misc scripts In-Reply-To: <56BD85AC-43E6-11D9-8939-000A9567635C@redivi.com> References: <56BD85AC-43E6-11D9-8939-000A9567635C@redivi.com> Message-ID: On Wed, 1 Dec 2004 17:14:16 -0500, Bob Ippolito wrote: > md5sum: > does what you'd expect it to do, OS X doesn't come with > /usr/bin/md5sum - so I wrote one in Python Is there something important that /sbin/md5 doesn't do? Cheers, -n8 -- >>>-- Nathaniel Gray -- Caltech Computer Science ------> >>>-- Mojave Project -- http://mojave.cs.caltech.edu --> From kp8 at mac.com Thu Dec 2 08:54:15 2004 From: kp8 at mac.com (kevin parks) Date: Thu Dec 2 11:37:50 2004 Subject: [Pythonmac-SIG] pretty printers, tabnanny and the like In-Reply-To: <20041129110006.785CD1E400B@bag.python.org> References: <20041129110006.785CD1E400B@bag.python.org> Message-ID: <5CB000AE-4437-11D9-BEA7-003065555ABC@mac.com> i used to. somehow, can't recall exactly... have a python script that i could use to clean up my python code and convert all the tabs spaces and insure that tabs and spaces were not mixed. It may have been tabnanny which use to come as a script and now, annoyingly may be a module, i dunno. but anyway i want something like tabnannny to check AND FIX my messed up files and i don't want to have to do it from the interpreter, i want to be able to do it from the terminal like: % fixthis messy_script.py boom and have my line endings and indents and tabs all fixed. I know that there used to be something like this, then i stupidly started using BBedit and now i don't have it anymore and i just want a thingy that will fix my stupid tabs and spaces. and a pretty printer like perl tidy would be nice too. Anyone know of one of these for python? interestingly i can import tabnanny but if i search for it on my hard drive, it doesn't appear. I have not idea where it is now... cheers, kevin From Jack.Jansen at cwi.nl Thu Dec 2 12:54:23 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Thu Dec 2 12:54:22 2004 Subject: [Pythonmac-SIG] Problem during installing MySQL module in Python - Other error In-Reply-To: References: Message-ID: On 1 Dec 2004, at 08:27, Zsolt.Putnoky@alcatel.fr wrote: > > I had rebuilt MySQL 4.0.22 from the source and rebuilt Python 2.3.4 > from the source. I tried to install the MySQL-Python module (version > 1.1.7), below is the result > > [Fiji:~/Temp/MySQL-python-1.1.7] zsoltput% set mysqlversion="4.0.22" > [Fiji:~/Temp/MySQL-python-1.1.7] zsoltput% set mysqloptlib="ssl crypto" > > [Fiji:~/Temp/MySQL-python-1.1.7] zsoltput% /usr/local/bin/python > setup.py build > running build > running build_py > running build_ext > building '_mysql' extension > gcc -bundle -bundle_loader /usr/local/bin/python2.3 > build/temp.darwin-7.6.0-Power_Macintosh-2.3/_mysql.o > -L/usr/local/mysql/lib -lmysqlclient -lz -lcrypt -o > build/lib.darwin-7.6.0-Power_Macintosh-2.3/_mysql.so -flat_namespace > ld: can't locate file for: -lcrypt > error: command 'gcc' failed with exit status 1 MacOSX doesn't have a library libcrypt. Check the setup.py script to see whether it has any suggestions for it could be expecting from that library. If it's the fairly standard unix "crypt" function: that's in the standard library so you can just remove the crypt library.. If it's something else you may need to hunt around for it. There's a /usr/lib/libcrypto.dylib, but I have no idea what it contains.. -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From Zsolt.Putnoky at alcatel.fr Thu Dec 2 13:02:29 2004 From: Zsolt.Putnoky at alcatel.fr (Zsolt.Putnoky@alcatel.fr) Date: Thu Dec 2 14:03:45 2004 Subject: [Pythonmac-SIG] Problem during installing MySQL module in Python - Other error In-Reply-To: Message-ID: Thanks Jack for the info. I will take a look once more. As far as I remember the setup.py does not contain specific information about the thing it expects to find in that library. /usr/lib/libcrypto.dylib - this sounds interesting, I will check if I can find something more detailed about this. Have a good day, Zsolt Putnoky To: Zsolt PUTNOKY/FR/ALCATEL@ALCATEL cc: pythonmac-sig@python.org Subject: Re: [Pythonmac-SIG] Problem during installing MySQL module in Python - Other error On 1 Dec 2004, at 08:27, Zsolt.Putnoky@alcatel.fr wrote: > > I had rebuilt MySQL 4.0.22 from the source and rebuilt Python 2.3.4 > from the source. I tried to install the MySQL-Python module (version > 1.1.7), below is the result > > [Fiji:~/Temp/MySQL-python-1.1.7] zsoltput% set mysqlversion="4.0.22" > [Fiji:~/Temp/MySQL-python-1.1.7] zsoltput% set mysqloptlib="ssl crypto" > > [Fiji:~/Temp/MySQL-python-1.1.7] zsoltput% /usr/local/bin/python > setup.py build > running build > running build_py > running build_ext > building '_mysql' extension > gcc -bundle -bundle_loader /usr/local/bin/python2.3 > build/temp.darwin-7.6.0-Power_Macintosh-2.3/_mysql.o > -L/usr/local/mysql/lib -lmysqlclient -lz -lcrypt -o > build/lib.darwin-7.6.0-Power_Macintosh-2.3/_mysql.so -flat_namespace > ld: can't locate file for: -lcrypt > error: command 'gcc' failed with exit status 1 MacOSX doesn't have a library libcrypt. Check the setup.py script to see whether it has any suggestions for it could be expecting from that library. If it's the fairly standard unix "crypt" function: that's in the standard library so you can just remove the crypt library.. If it's something else you may need to hunt around for it. There's a /usr/lib/libcrypto.dylib, but I have no idea what it contains.. -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20041202/aa39d99d/attachment.html From bob at redivi.com Thu Dec 2 15:33:41 2004 From: bob at redivi.com (Bob Ippolito) Date: Thu Dec 2 15:34:16 2004 Subject: [Pythonmac-SIG] [ANN] misc scripts In-Reply-To: References: <56BD85AC-43E6-11D9-8939-000A9567635C@redivi.com> Message-ID: <29D9BDF0-446F-11D9-BE3A-000A95BA5446@redivi.com> On Dec 2, 2004, at 4:18, Nathaniel Gray wrote: > On Wed, 1 Dec 2004 17:14:16 -0500, Bob Ippolito wrote: >> md5sum: >> does what you'd expect it to do, OS X doesn't come with >> /usr/bin/md5sum - so I wrote one in Python > > Is there something important that /sbin/md5 doesn't do? I guess not, it's just not named md5sum :) -bob From smithsm at samuelsmith.org Thu Dec 2 16:00:53 2004 From: smithsm at samuelsmith.org (Samuel M.Smith) Date: Thu Dec 2 16:00:56 2004 Subject: [Pythonmac-SIG] Building 2.4 In-Reply-To: References: <4C4BB602-541F-11D8-BF32-000393DB52E4@2xtreme.net> <82AB2C9C-54E8-11D8-B033-000A95C4B360@samuelsmith.org> Message-ID: Would anyone care to post step by step instructions for building a framework version of Python 2.4 that will peacefully cohabitate with the built in OS X Python 2.3. Does it build out of the box from the source? ********************************************************************** Samuel M. Smith Ph.D. 2966 Fort Hill Road Eagle Mountain, Utah 84043 801-768-2768 voice 801-768-2769 fax ********************************************************************** "The greatest source of failure and unhappiness in the world is giving up what we want most for what we want at the moment" ********************************************************************** From bob at redivi.com Thu Dec 2 16:11:33 2004 From: bob at redivi.com (Bob Ippolito) Date: Thu Dec 2 16:12:09 2004 Subject: [Pythonmac-SIG] Building 2.4 In-Reply-To: References: <4C4BB602-541F-11D8-BF32-000393DB52E4@2xtreme.net> <82AB2C9C-54E8-11D8-B033-000A95C4B360@samuelsmith.org> Message-ID: <740B2622-4474-11D9-BE3A-000A95BA5446@redivi.com> On Dec 2, 2004, at 10:00, Samuel M.Smith wrote: > Would anyone care to post step by step instructions for building a > framework version of Python 2.4 > that will peacefully cohabitate with the built in OS X Python 2.3. > > Does it build out of the box from the source? Patch your config/Makefile of your existing Python 2.3.0 installation (see a recent email of mine on the subject) Fetch 2.4 sources From the 2.4 source directory do the following: env MACOSX_DEPLOYMENT_TARGET=10.3 ./configure --enable-framework make sudo make frameworkinstall You probably want to add /usr/local/bin early on in your path if you haven't already, you may want to delete /usr/local/bin/python if you want python 2.3 to be "the default", because there is also a symlink named python2.4 that you could use. -bob From Chris.Barker at noaa.gov Thu Dec 2 18:06:24 2004 From: Chris.Barker at noaa.gov (Chris Barker) Date: Thu Dec 2 18:09:18 2004 Subject: [Pythonmac-SIG] pretty printers, tabnanny and the like In-Reply-To: References: Message-ID: <41AF4B90.4080901@noaa.gov> kevin parks wrote: > > i used to. somehow, can't recall exactly... have a python script that i > could use to clean up my python code and convert all the tabs spaces and > insure that tabs and spaces were not mixed. I've enclosed the one I use, borrowed from someone on the net (maybe Gordon McMillian?) It doesn't do line endings, but with the Universal text file mode, it would be a piece of cake to add that. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov -------------- next part -------------- #!/usr/bin/python import tokenize import string TABSONLY = 'TABSONLY' SPACESONLY = 'SPACESONLY' MIXED = 'MIXED' class PyText: def __init__(self, fnm, optdict): self.optdict = optdict self.fnm = fnm self.txt = open(self.fnm, 'r').readlines() self.indents = [(0, 0, )] self.lnndx = 0 self.indentndx = 0 def getline(self): if self.lnndx < len(self.txt): txt = self.txt[self.lnndx] self.lnndx = self.lnndx + 1 else: txt = '' return txt def tokeneater(self, type, token, start, end, line): if type == tokenize.INDENT: (lvl, s) = self.indents[-1] self.indents[-1] = (lvl, s, start[0]-1) self.indents.append((lvl+1, start[0]-1,)) elif type == tokenize.DEDENT: (lvl, s) = self.indents[-1] self.indents[-1] = (lvl, s, start[0]-1) self.indents.append((lvl-1, start[0]-1,)) elif type == tokenize.ENDMARKER: (lvl, s) = self.indents[-1] self.indents[-1] = (lvl, s, len(self.txt)) def split(self, ln): content = string.lstrip(ln) if not content: return ('', '\n') lead = ln[:len(ln) - len(content)] lead = string.expandtabs(lead) return (lead, content) def process(self): style = self.optdict.get('style', SPACESONLY) indent = string.atoi(self.optdict.get('indent', '4')) tabsz = string.atoi(self.optdict.get('tabs', '8')) print 'file %s -> style %s, tabsize %d, indent %d' % (self.fnm, style, tabsz, indent) tokenize.tokenize(self.getline, self.tokeneater) #import pprint #pprint.pprint(self.indents) new = [] for (lvl, s, e) in self.indents: if s >= len(self.txt): break if s == e: continue oldlead, content = self.split(self.txt[s]) #print "oldlead", len(oldlead), `oldlead` if style == TABSONLY: newlead = '\t'*lvl elif style == SPACESONLY: newlead = ' '*(indent*lvl) else: sz = indent*lvl t,spcs = divmod(sz, tabsz) newlead = '\t'*t + ' '*spcs new.append(newlead + content) for ln in self.txt[s+1:e]: lead, content = self.split(ln) #print "lead:", len(lead) new.append(newlead + lead[len(oldlead):] + content) self.save(new) #print "---", self.fnm #for ln in new: # print ln, #print def save(self, txt): bakname = os.path.splitext(self.fnm)[0]+'.bak' print "backing up", self.fnm, "to", bakname #print os.getcwd() try: os.rename(self.fnm, bakname) except os.error: os.remove(bakname) os.rename(self.fnm, bakname) open(self.fnm, 'w').writelines(txt) def test(): tc = PyText('test1.py') tc.process() tc = PyText('test1.py') tc.process(style=TABSONLY) tc = PyText('test1.py') tc.process(style=MIXED, indent=4, tabs=8) tc = PyText('test1.py') tc.process(style=MIXED, indent=2, tabs=8) def cleanfile(fnm, d): if os.path.isdir(fnm) and not os.path.islink(fnm): names = os.listdir(fnm) for name in names: fullnm = os.path.join(fnm, name) if (os.path.isdir(fullnm) and not os.path.islink(fullnm)) or \ os.path.normcase(fullnm[-3:]) == ".py": cleanfile(fullnm, d) return tc = PyText(fnm, d) tc.process() usage="""\ %s [options] [path...] options -T : reformat to TABS ONLY -S : reformat to SPACES ONLY ( -i option is important) -M : reformat to MIXED SPACES / TABS ( -t and -i options important) -t : tab is worth characters -i : indents should be characters -h : print this text path is file or directory """ if __name__ == '__main__': import sys, getopt, os opts, args = getopt.getopt(sys.argv[1:], "TSMht:i:") d = {} print `opts` for opt in opts: if opt[0] == '-T': d['style'] = TABSONLY elif opt[0] == '-S': d['style'] = SPACESONLY elif opt[0] == '-M': d['style'] = MIXED elif opt[0] == '-t': d['tabs'] = opt[1] elif opt[0] == '-i': d['indent'] = opt[1] elif opt[0] == '-h': print usage % sys.argv[0] sys.exit(0) if not args: print usage % sys.argv[0] for arg in args: cleanfile(arg, d) From jmc2006 at med.cornell.edu Thu Dec 2 18:19:18 2004 From: jmc2006 at med.cornell.edu (Janice Cheung) Date: Thu Dec 2 18:15:47 2004 Subject: [Pythonmac-SIG] Question using cvs2svn Message-ID: <41AF4E96.8070506@med.cornell.edu> Greetings! I recently installed cvs2svn (a version of subversion) on my Mac OS X 10.3.6. I've also installed Sleepycat Berkeley DB 4.3.21. When I attempt to run $"cvs2svn" at the prompt, I receive this error message: ERROR: your installation of Python does not contain a suitable DBM module. This script cannot continue. to solve: see http://python.org/doc/current/lib/module-anydbm.html for details. I have been assured by the cvs2svn group that this is a Python issue. I'm unsure as to how to proceed. I am using Python Version 2.3, which does indeed include "anydmb". Am I missing some sort of dbm backend modules that enables Python to use Berkeley? I already have a cvs web server set up ... I'm somewhat befuddled. Any guidance or help would be greatly appreciated. Happy Holidays! Best regards, Janice -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20041202/24c9f3e7/attachment-0001.html From dreedmac at columbus.rr.com Thu Dec 2 18:50:02 2004 From: dreedmac at columbus.rr.com (David Reed) Date: Thu Dec 2 18:50:09 2004 Subject: [Pythonmac-SIG] Building 2.4 In-Reply-To: <740B2622-4474-11D9-BE3A-000A95BA5446@redivi.com> References: <4C4BB602-541F-11D8-BF32-000393DB52E4@2xtreme.net> <82AB2C9C-54E8-11D8-B033-000A95C4B360@samuelsmith.org> <740B2622-4474-11D9-BE3A-000A95BA5446@redivi.com> Message-ID: <97DCFDFA-448A-11D9-A8F9-000D932F4414@columbus.rr.com> On Dec 2, 2004, at 10:11 AM, Bob Ippolito wrote: > On Dec 2, 2004, at 10:00, Samuel M.Smith wrote: > >> Would anyone care to post step by step instructions for building a >> framework version of Python 2.4 >> that will peacefully cohabitate with the built in OS X Python 2.3. >> >> Does it build out of the box from the source? > > Patch your config/Makefile of your existing Python 2.3.0 installation > (see a recent email of mine on the subject) > Fetch 2.4 sources > > From the 2.4 source directory do the following: > > env MACOSX_DEPLOYMENT_TARGET=10.3 ./configure --enable-framework > make > sudo make frameworkinstall > > You probably want to add /usr/local/bin early on in your path if you > haven't already, you may want to delete /usr/local/bin/python if you > want python 2.3 to be "the default", because there is also a symlink > named python2.4 that you could use. > > -bob > Can anyone explain or point me to something to read about the benefits/trade-offs of using the framework version (I'm a long time Linux/Solaris user, but new to OS X) vs. just a regular compilation? Thanks, Dave From bob at redivi.com Thu Dec 2 19:41:51 2004 From: bob at redivi.com (Bob Ippolito) Date: Thu Dec 2 19:42:01 2004 Subject: [Pythonmac-SIG] Building 2.4 In-Reply-To: <97DCFDFA-448A-11D9-A8F9-000D932F4414@columbus.rr.com> References: <4C4BB602-541F-11D8-BF32-000393DB52E4@2xtreme.net> <82AB2C9C-54E8-11D8-B033-000A95C4B360@samuelsmith.org> <740B2622-4474-11D9-BE3A-000A95BA5446@redivi.com> <97DCFDFA-448A-11D9-A8F9-000D932F4414@columbus.rr.com> Message-ID: On Dec 2, 2004, at 12:50 PM, David Reed wrote: > On Dec 2, 2004, at 10:11 AM, Bob Ippolito wrote: > >> On Dec 2, 2004, at 10:00, Samuel M.Smith wrote: >> >>> Would anyone care to post step by step instructions for building a >>> framework version of Python 2.4 >>> that will peacefully cohabitate with the built in OS X Python 2.3. >>> >>> Does it build out of the box from the source? >> >> Patch your config/Makefile of your existing Python 2.3.0 installation >> (see a recent email of mine on the subject) >> Fetch 2.4 sources >> >> From the 2.4 source directory do the following: >> >> env MACOSX_DEPLOYMENT_TARGET=10.3 ./configure --enable-framework >> make >> sudo make frameworkinstall >> >> You probably want to add /usr/local/bin early on in your path if you >> haven't already, you may want to delete /usr/local/bin/python if you >> want python 2.3 to be "the default", because there is also a symlink >> named python2.4 that you could use. > > Can anyone explain or point me to something to read about the > benefits/trade-offs of using the framework version (I'm a long time > Linux/Solaris user, but new to OS X) vs. just a regular compilation? It's supported by the people who know most about Python on Mac OS X, and it's the same type of install that Apple provides. Technically, the difference is mostly where the files go. It's a heck of a lot easier to move or remove a framework installation, or to naively embed Python into an application bundle. A normal install probably works too, but I have no need for one and thus haven't tested it in a long time. If you have problems with it, you're probably not going to get any help from me. -bob From Jack.Jansen at cwi.nl Thu Dec 2 22:58:16 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Thu Dec 2 22:58:27 2004 Subject: [Pythonmac-SIG] Question using cvs2svn In-Reply-To: <41AF4E96.8070506@med.cornell.edu> References: <41AF4E96.8070506@med.cornell.edu> Message-ID: <4572C2FF-44AD-11D9-B6BB-000D934FF6B4@cwi.nl> On 2-dec-04, at 18:19, Janice Cheung wrote: > ??? Greetings! > > ??? I recently installed cvs2svn (a version of subversion) on my Mac > OS X 10.3.6. > > ??? I've also installed Sleepycat Berkeley DB 4.3.21. > > ??? When I attempt to run $"cvs2svn" at the prompt, I receive this > error message: > > ??? ERROR: your installation of Python does not contain a suitable DBM > module.? This script cannot > ??? ?? ?? ?? ?????? continue.? > > ??? to solve:? see > http://python.org/doc/current/lib/module-anydbm.html for details. That is indeed a rather stupid error message: what it tries to say is that the only Python dbm modules that are available are not good enough for cvs2svn. So you need to install one that is good enough (such as Sleepycat Berkeley DB), but you also need to install the corresponding Python module. Does anyone happen to know about an easy to install DB + Python module? Bob, anything in your PackMan database, maybe? -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From Jack.Jansen at cwi.nl Thu Dec 2 23:09:02 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Thu Dec 2 23:09:05 2004 Subject: [Pythonmac-SIG] Building 2.4 In-Reply-To: <740B2622-4474-11D9-BE3A-000A95BA5446@redivi.com> References: <4C4BB602-541F-11D8-BF32-000393DB52E4@2xtreme.net> <82AB2C9C-54E8-11D8-B033-000A95C4B360@samuelsmith.org> <740B2622-4474-11D9-BE3A-000A95BA5446@redivi.com> Message-ID: On 2-dec-04, at 16:11, Bob Ippolito wrote: > > Patch your config/Makefile of your existing Python 2.3.0 installation > (see a recent email of mine on the subject) Here's an idea: could we somehow incorporate your patch into one of the Python Makefiles (Mac/OSX/Makefile comes to mind) and add a test for whether it's needed too? It would be nice if anyone building 2.4 framework Python on an unpatched 10.3 would get a warning along the lines of WARNING: your Apple-installed Python needs a path to coexist peacefully with MacPython 2.4 WARNING: run "sudo make patchpython2.3" in Mac/OSX to apply the patch. -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From bob at redivi.com Thu Dec 2 23:22:32 2004 From: bob at redivi.com (Bob Ippolito) Date: Thu Dec 2 23:23:07 2004 Subject: [Pythonmac-SIG] Question using cvs2svn In-Reply-To: <4572C2FF-44AD-11D9-B6BB-000D934FF6B4@cwi.nl> References: <41AF4E96.8070506@med.cornell.edu> <4572C2FF-44AD-11D9-B6BB-000D934FF6B4@cwi.nl> Message-ID: On Dec 2, 2004, at 16:58, Jack Jansen wrote: > > On 2-dec-04, at 18:19, Janice Cheung wrote: > >> ??? Greetings! >> >> ??? I recently installed cvs2svn (a version of subversion) on my Mac >> OS X 10.3.6. >> >> ??? I've also installed Sleepycat Berkeley DB 4.3.21. >> >> ??? When I attempt to run $"cvs2svn" at the prompt, I receive this >> error message: >> >> ??? ERROR: your installation of Python does not contain a suitable >> DBM module.? This script cannot >> ??? ?? ?? ?? ?????? continue.? >> >> ??? to solve:? see >> http://python.org/doc/current/lib/module-anydbm.html for details. > > That is indeed a rather stupid error message: what it tries to say is > that the only Python dbm modules that are available are not good > enough for cvs2svn. > > So you need to install one that is good enough (such as Sleepycat > Berkeley DB), but you also need to install the corresponding Python > module. > > Does anyone happen to know about an easy to install DB + Python > module? Bob, anything in your PackMan database, maybe? The one in my PackMan database may be too old.. building bsddb3 from source is probably a good idea. -bob From ronaldoussoren at mac.com Fri Dec 3 10:56:38 2004 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Fri Dec 3 10:56:46 2004 Subject: [Pythonmac-SIG] Building 2.4 In-Reply-To: References: <4C4BB602-541F-11D8-BF32-000393DB52E4@2xtreme.net> <82AB2C9C-54E8-11D8-B033-000A95C4B360@samuelsmith.org> <740B2622-4474-11D9-BE3A-000A95BA5446@redivi.com> Message-ID: <9FDF2616-4511-11D9-9361-000D93AD379E@mac.com> On 2-dec-04, at 23:09, Jack Jansen wrote: > > On 2-dec-04, at 16:11, Bob Ippolito wrote: >> >> Patch your config/Makefile of your existing Python 2.3.0 installation >> (see a recent email of mine on the subject) > > Here's an idea: could we somehow incorporate your patch into one of > the Python Makefiles (Mac/OSX/Makefile comes to mind) and add a test > for whether it's needed too? > > It would be nice if anyone building 2.4 framework Python on an > unpatched 10.3 would get a warning along the lines of > WARNING: your Apple-installed Python needs a path to coexist > peacefully with MacPython 2.4 > WARNING: run "sudo make patchpython2.3" in Mac/OSX to apply the patch. It would also be possible to monkey-patch the 2.3 install. IIRC I've posted one way to do a long time ago. That message should be in the archives. The advantage would be that you do not have to patch files in /System, we could even use this to install include files outside of /System while keeping them functional. The disadvantage is that my approach seems to induce vomitting in some people ;-) Ronald From Jack.Jansen at cwi.nl Fri Dec 3 15:23:56 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Fri Dec 3 15:23:44 2004 Subject: [Pythonmac-SIG] Building 2.4 In-Reply-To: <9FDF2616-4511-11D9-9361-000D93AD379E@mac.com> References: <4C4BB602-541F-11D8-BF32-000393DB52E4@2xtreme.net> <82AB2C9C-54E8-11D8-B033-000A95C4B360@samuelsmith.org> <740B2622-4474-11D9-BE3A-000A95BA5446@redivi.com> <9FDF2616-4511-11D9-9361-000D93AD379E@mac.com> Message-ID: On 3 Dec 2004, at 10:56, Ronald Oussoren wrote: > It would also be possible to monkey-patch the 2.3 install. IIRC I've > posted one way to do a long time ago. That message should be in the > archives. > > The advantage would be that you do not have to patch files in /System, > we could even use this to install include files outside of /System > while keeping them functional. The disadvantage is that my approach > seems to induce vomitting in some people ;-) I assume that was me:-) But I can't for the life of me remember how you did it. Do you have a reference? -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From smithsm at samuelsmith.org Fri Dec 3 16:55:29 2004 From: smithsm at samuelsmith.org (Samuel M.Smith) Date: Fri Dec 3 16:55:34 2004 Subject: [Pythonmac-SIG] Building 2.4 In-Reply-To: <740B2622-4474-11D9-BE3A-000A95BA5446@redivi.com> References: <4C4BB602-541F-11D8-BF32-000393DB52E4@2xtreme.net> <82AB2C9C-54E8-11D8-B033-000A95C4B360@samuelsmith.org> <740B2622-4474-11D9-BE3A-000A95BA5446@redivi.com> Message-ID: On Dec 2, 2004, at 08:11, Bob Ippolito wrote: > On Dec 2, 2004, at 10:00, Samuel M.Smith wrote: > >> Would anyone care to post step by step instructions for building a >> framework version of Python 2.4 >> that will peacefully cohabitate with the built in OS X Python 2.3. >> >> Does it build out of the box from the source? > > Patch your config/Makefile of your existing Python 2.3.0 installation > (see a recent email of mine on the subject) > Fetch 2.4 sources > Is this the patch you mean? > The correct linker settings are not adopted by any mainline version of > Python 2.3. I had thought they were in 2.3.4, but they're not. Only > Python 2.4 builds correctly by default. Also, Apple's build of Python > 2.3.3 in the WWDC 2004 preview > > adopts a similar method to this patch, but slightly modified so that > it does not depend on MACOSX_DEPLOYMENT_TARGET being set: > > (this is what a good > /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/config/Makefile should look like, starting on or around line > 98) > > LDSHARED= env MACOSX_DEPLOYMENT_TARGET=10.3 $(CC) $(LDFLAGS) -bundle > -undefined dynamic_lookup > BLDSHARED= env MACOSX_DEPLOYMENT_TARGET=10.3 $(CC) $(LDFLAGS) -bundle > -undefined dynamic_lookup > Sam From ronaldoussoren at mac.com Fri Dec 3 16:55:46 2004 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Fri Dec 3 16:55:53 2004 Subject: [Pythonmac-SIG] Building 2.4 In-Reply-To: References: <4C4BB602-541F-11D8-BF32-000393DB52E4@2xtreme.net> <82AB2C9C-54E8-11D8-B033-000A95C4B360@samuelsmith.org> <740B2622-4474-11D9-BE3A-000A95BA5446@redivi.com> <9FDF2616-4511-11D9-9361-000D93AD379E@mac.com> Message-ID: On 3-dec-04, at 15:23, Jack Jansen wrote: > > On 3 Dec 2004, at 10:56, Ronald Oussoren wrote: >> It would also be possible to monkey-patch the 2.3 install. IIRC I've >> posted one way to do a long time ago. That message should be in the >> archives. >> >> The advantage would be that you do not have to patch files in >> /System, we could even use this to install include files outside of >> /System while keeping them functional. The disadvantage is that my >> approach seems to induce vomitting in some people ;-) > > I assume that was me:-) Me too :-) > > But I can't for the life of me remember how you did it. Do you have a > reference? I don't have a reference, but I do remember what I did: 1) Create a .pth file containing:: import sys; sys.path.insert(0, '/Library/Python/2.3/python-fixes') 2) In /Library/Python/2.3 create a distutils package with only a __init__.py. That __init__.py should extend/set the __path__, to make sure we can import the rest of distutils. It should then 'execfile' the real distutils.__init__ and finally patch up distutils. This is a gross hack, but is a relatively clean way to perform non-invasive surgery on an existing python installation. At least it doesn't requiry people to use the shell and sudo (both of which are scary for lots of peoply). I'll see if I can build a working example for this tomorrow. Ronald From bob at redivi.com Fri Dec 3 18:04:37 2004 From: bob at redivi.com (Bob Ippolito) Date: Fri Dec 3 18:05:13 2004 Subject: [Pythonmac-SIG] Building 2.4 In-Reply-To: References: <4C4BB602-541F-11D8-BF32-000393DB52E4@2xtreme.net> <82AB2C9C-54E8-11D8-B033-000A95C4B360@samuelsmith.org> <740B2622-4474-11D9-BE3A-000A95BA5446@redivi.com> Message-ID: <699632D8-454D-11D9-81C9-000A95BA5446@redivi.com> On Dec 3, 2004, at 10:55, Samuel M. Smith wrote: > > On Dec 2, 2004, at 08:11, Bob Ippolito wrote: > >> On Dec 2, 2004, at 10:00, Samuel M.Smith wrote: >> >>> Would anyone care to post step by step instructions for building a >>> framework version of Python 2.4 >>> that will peacefully cohabitate with the built in OS X Python 2.3. >>> >>> Does it build out of the box from the source? >> >> Patch your config/Makefile of your existing Python 2.3.0 installation >> (see a recent email of mine on the subject) >> Fetch 2.4 sources >> > > Is this the patch you mean? > >> The correct linker settings are not adopted by any mainline version >> of Python 2.3. I had thought they were in 2.3.4, but they're not. >> Only Python 2.4 builds correctly by default. Also, Apple's build of >> Python 2.3.3 in the WWDC 2004 preview >> >> adopts a similar method to this patch, but slightly modified so that >> it does not depend on MACOSX_DEPLOYMENT_TARGET being set: >> >> (this is what a good >> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ >> python2.3/config/Makefile should look like, starting on or around >> line 98) >> >> LDSHARED= env MACOSX_DEPLOYMENT_TARGET=10.3 $(CC) $(LDFLAGS) >> -bundle -undefined dynamic_lookup >> BLDSHARED= env MACOSX_DEPLOYMENT_TARGET=10.3 $(CC) $(LDFLAGS) >> -bundle -undefined dynamic_lookup >> Yes. -bob From bob at redivi.com Fri Dec 3 18:05:47 2004 From: bob at redivi.com (Bob Ippolito) Date: Fri Dec 3 18:06:01 2004 Subject: [Pythonmac-SIG] Building 2.4 In-Reply-To: References: <4C4BB602-541F-11D8-BF32-000393DB52E4@2xtreme.net> <82AB2C9C-54E8-11D8-B033-000A95C4B360@samuelsmith.org> <740B2622-4474-11D9-BE3A-000A95BA5446@redivi.com> <9FDF2616-4511-11D9-9361-000D93AD379E@mac.com> Message-ID: <93D34686-454D-11D9-81C9-000A95BA5446@redivi.com> On Dec 3, 2004, at 10:55, Ronald Oussoren wrote: > > On 3-dec-04, at 15:23, Jack Jansen wrote: > >> >> On 3 Dec 2004, at 10:56, Ronald Oussoren wrote: >>> It would also be possible to monkey-patch the 2.3 install. IIRC I've >>> posted one way to do a long time ago. That message should be in the >>> archives. >>> >>> The advantage would be that you do not have to patch files in >>> /System, we could even use this to install include files outside of >>> /System while keeping them functional. The disadvantage is that my >>> approach seems to induce vomitting in some people ;-) >> >> I assume that was me:-) > > Me too :-) > >> >> But I can't for the life of me remember how you did it. Do you have a >> reference? > > I don't have a reference, but I do remember what I did: > > 1) Create a .pth file containing:: > > import sys; sys.path.insert(0, '/Library/Python/2.3/python-fixes') > > 2) In /Library/Python/2.3 create a distutils package with only a > __init__.py. > > That __init__.py should extend/set the __path__, to make sure we > can import the > rest of distutils. It should then 'execfile' the real > distutils.__init__ and finally > patch up distutils. > > This is a gross hack, but is a relatively clean way to perform > non-invasive surgery on an existing python installation. At least it > doesn't requiry people to use the shell and sudo (both of which are > scary for lots of peoply). > > I'll see if I can build a working example for this tomorrow. It would be easier to just build a .pkg installer that has a preflight script that checks for OS X 10.3.x, and does the patch. -bob From ronaldoussoren at mac.com Fri Dec 3 18:19:53 2004 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Fri Dec 3 18:20:15 2004 Subject: [Pythonmac-SIG] Building 2.4 In-Reply-To: <93D34686-454D-11D9-81C9-000A95BA5446@redivi.com> References: <4C4BB602-541F-11D8-BF32-000393DB52E4@2xtreme.net> <82AB2C9C-54E8-11D8-B033-000A95C4B360@samuelsmith.org> <740B2622-4474-11D9-BE3A-000A95BA5446@redivi.com> <9FDF2616-4511-11D9-9361-000D93AD379E@mac.com> <93D34686-454D-11D9-81C9-000A95BA5446@redivi.com> Message-ID: <552DEA63-328E-4BDA-84EA-DEEEF653711B@mac.com> On 3-dec-2004, at 18:05, Bob Ippolito wrote: > > It would be easier to just build a .pkg installer that has a preflight > script that checks for OS X 10.3.x, and does the patch. > Sure, but I like ugly hacks :-) Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20041203/cb1c84c7/smime.bin From janssen at parc.com Fri Dec 3 20:01:04 2004 From: janssen at parc.com (Bill Janssen) Date: Fri Dec 3 20:01:29 2004 Subject: [Pythonmac-SIG] Building Numeric Python on Panther Message-ID: <04Dec3.110105pst."58617"@synergy1.parc.xerox.com> I just downloaded the latest versions of numarray and Numeric Python. numarray builds and installs without problems, but Numeric fails -- it seems to have a bad setup.py file that references missing directories such as "/usr/include/atlas". Is there a set of patches for building this on Panther against the stock 2.3.0 Python release? (Bonus question: the Numeric Python documentation makes it clear that numarray should be used, but not how. Is numarray a substitute for all of Numeric? If not, should numarray be installed before NumPy?) Bill From bob at redivi.com Fri Dec 3 20:16:58 2004 From: bob at redivi.com (Bob Ippolito) Date: Fri Dec 3 20:17:39 2004 Subject: [Pythonmac-SIG] Building Numeric Python on Panther In-Reply-To: <04Dec3.110105pst."58617"@synergy1.parc.xerox.com> References: <04Dec3.110105pst."58617"@synergy1.parc.xerox.com> Message-ID: On Dec 3, 2004, at 14:01, Bill Janssen wrote: > I just downloaded the latest versions of numarray and Numeric Python. > numarray builds and installs without problems, but Numeric fails -- it > seems to have a bad setup.py file that references missing directories > such as "/usr/include/atlas". Is there a set of patches for building > this on Panther against the stock 2.3.0 Python release? http://mail.python.org/pipermail/pythonmac-sig/2004-November/012077.html > (Bonus question: the Numeric Python documentation makes it clear that > numarray should be used, but not how. Is numarray a substitute for > all of Numeric? If not, should numarray be installed before NumPy?) I think what they mean is that new applications should use numarray. I think the Python API is largely the same, but not everything is the same (the C API, for example). There are no interdependencies, so installation order isn't going to make a lick of difference. -bob From janssen at parc.com Fri Dec 3 21:02:05 2004 From: janssen at parc.com (Bill Janssen) Date: Fri Dec 3 21:02:23 2004 Subject: [Pythonmac-SIG] Building Numeric Python on Panther In-Reply-To: Your message of "Fri, 03 Dec 2004 11:16:58 PST." Message-ID: <04Dec3.120210pst."58617"@synergy1.parc.xerox.com> Thanks, Bob. Bill From Chris.Barker at noaa.gov Fri Dec 3 21:07:47 2004 From: Chris.Barker at noaa.gov (Chris Barker) Date: Fri Dec 3 21:10:45 2004 Subject: [Pythonmac-SIG] Building Numeric Python on Panther In-Reply-To: References: <04Dec3.110105pst."58617"@synergy1.parc.xerox.com> Message-ID: <41B0C793.9070602@noaa.gov> Bob Ippolito wrote: >> (Bonus question: the Numeric Python documentation makes it clear that >> numarray should be used, but not how. Is numarray a substitute for >> all of Numeric? If not, should numarray be installed before NumPy?) > > I think what they mean is that new applications should use numarray. I > think the Python API is largely the same, but not everything is the same > (the C API, for example). there are also differences in the Python API, but not much and there is a numarray C api that is similar. > There are no interdependencies, so installation order isn't going to > make a lick of difference. correct, they can co-exist quite peacefully. They even do a pretty good job of existing together in the same app! Rules of thumb: If you are using or modifying an app that already uses one or the other, stick with it. If you are starting from scratch, you probably want to use numarray, unless: -- you are also using SciPy, which used Numeric -- you do a lot with small arrays. numarray has substantially worse performance with small arrays than Numeric, but somewhat better with very large arrays Despite the idea that Numarray will replace Numeric, Numeric is still actively maintained (except that darn mistake in setup.py, which has persisted across a couple releases!) -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov From rowen at cesmail.net Sat Dec 4 00:01:04 2004 From: rowen at cesmail.net (Russell E. Owen) Date: Sat Dec 4 00:01:14 2004 Subject: [Pythonmac-SIG] Re: Building 2.4 References: <4C4BB602-541F-11D8-BF32-000393DB52E4@2xtreme.net> <82AB2C9C-54E8-11D8-B033-000A95C4B360@samuelsmith.org> <740B2622-4474-11D9-BE3A-000A95BA5446@redivi.com> <97DCFDFA-448A-11D9-A8F9-000D932F4414@columbus.rr.com> Message-ID: In article <97DCFDFA-448A-11D9-A8F9-000D932F4414@columbus.rr.com>, David Reed wrote: > Can anyone explain or point me to something to read about the > benefits/trade-offs of using the framework version (I'm a long time > Linux/Solaris user, but new to OS X) vs. just a regular compilation? Framework python is already installed (good if you are OK with 2.3). that saves trouble, plus Mac binaries that use or extend Python will expect to find that. Also, it is easy to run with native windowing GUI toolkits (Tk, wxPython and PyQt all have aqua versions, I believe). Unix installs are very easy to get working with X11. I don't know if they can be made to work with aqua GUI toolkits -- I've never tried. On my own MacOS X box I have the standard framework Python 2.3 that came pre-installed, plus a unix/x11 python 2.4. I write a cross-platform TKinter app and it's nice to be able to see it from both a Mac perspective and a unix user's perspective on one computer. Of course for any extra python packages I use I have to install them twice, but it's easy enough to do that. Other than that, it seems to "just work" (though when building x11 stuff that uses tcl/tk I move my /Library Tcl and Tk frameworks first, so they aren't seen; there is probably a smarter way to handle this, but it does the job.) I have found that some packages are easier to install with one python or the other. Also, the Framework python has a lot of prebuilt binaries (though a lot of those are very out of date). Just my two bits. -- Russell From janssen at parc.com Sat Dec 4 02:40:45 2004 From: janssen at parc.com (Bill Janssen) Date: Sat Dec 4 02:41:06 2004 Subject: [Pythonmac-SIG] Building Numeric Python on Panther In-Reply-To: Your message of "Fri, 03 Dec 2004 12:07:47 PST." <41B0C793.9070602@noaa.gov> Message-ID: <04Dec3.174047pst."58617"@synergy1.parc.xerox.com> Thanks, Chris. I'll work with numarray, then, since it just installs on my Macs. I want to do a lot of document clustering in various ways, so I'm building term vectors, etc. There doesn't seem to be anything in the API specifically about that. Bill From bob at redivi.com Sat Dec 4 17:45:21 2004 From: bob at redivi.com (Bob Ippolito) Date: Sat Dec 4 17:46:00 2004 Subject: [Pythonmac-SIG] Re: [Pyobjc-dev] PyObjC py2app-branch merged to trunk In-Reply-To: References: <54F492AE-41C3-11D9-813B-000A9567635C@redivi.com> Message-ID: What version of Mac OS X is this? On Dec 4, 2004, at 10:36, Victor Ng wrote: > I'm having problems with buliding the example applications - not > really sure what I'm doing wrong. > > I've just installed py2app from it's svn trunk, and pyobjc from svn > trunk. > > When I run setup.py py2app on the CurrencyConverter example, I get an > error dialog popping up with: > > ImportError: > '/Users/victorng/dev/pyobjc/trunk/pyobjc/Examples/CurrencyConverter/ > dist/CurrencyConverter.app/Contents/Resources/Python/lib-dynload/objc/ > _objc.so' > not found > > When I try looking in the lib-dynload directory - I don't have any > objc, AppKit or other directories that I think I'm supposed to be > getting. > > Any pointers? > vic > > > On Sun, 28 Nov 2004 23:58:38 -0500, Bob Ippolito > wrote: >> The py2app-branch of PyObjC has been merged to trunk, and development >> will continue on trunk. For those of you that have checked out >> py2app-branch, please svn switch back to >> http://svn.red-bean.com/pyobjc/trunk/pyobjc >> >> Enhancements include but are not limited to: >> >> - All buildapp.py scripts are gone, bundlebuilder is no longer used >> anywhere. Examples now have setup.py scripts and are built with >> "python setup.py py2app". >> - The way setup.py works has changed significantly. It now supports a >> bdist_mpkg command to build a .mpkg distribution containing both >> PyObjC >> and py2app >> - Includes a copy of what will be py2app 0.1.6 (or possibly 0.2.0 .. >> depending on what else I change) >> - Enhanced compatibility with the Apple Objective C runtime >> - Bugfixes and minor feature additions on several other fronts >> - A sandbox directory with some new half-baked ideas for a new >> Objective C header parser >> >> The Xcode template still does not support py2app. I would recommend >> that if you use Xcode, you should only use it for development. >> Deployment should be done using py2app. >> >> -bob >> >> ------------------------------------------------------- >> SF email is sponsored by - The IT Product Guide >> Read honest & candid reviews on hundreds of IT Products from real >> users. >> Discover which products truly live up to the hype. Start reading now. >> http://productguide.itmanagersjournal.com/ >> _______________________________________________ >> Pyobjc-dev mailing list >> Pyobjc-dev@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev >> From bob at redivi.com Sat Dec 4 18:02:05 2004 From: bob at redivi.com (Bob Ippolito) Date: Sat Dec 4 18:02:41 2004 Subject: [Pythonmac-SIG] Re: [Pyobjc-dev] PyObjC py2app-branch merged to trunk In-Reply-To: References: <54F492AE-41C3-11D9-813B-000A9567635C@redivi.com> Message-ID: <398CE00E-4616-11D9-81C9-000A95BA5446@redivi.com> After waking up a bit I realized this is could possibly be because you didn't remove an old PyObjC installation first. Do that, and then reinstall. Using the bdist_mpkg installer (which will also install py2app) is another way to wipe the old installation clean. From the pyobjc source tree: % python setup.py bdist_mpkg --open If that doesn't work, I'm not sure what to tell you, because it works just fine on three computers here (one OS X 10.2 and two OS X 10.3) with standard-enough configurations. -bob On Dec 4, 2004, at 11:45, Bob Ippolito wrote: > What version of Mac OS X is this? > > On Dec 4, 2004, at 10:36, Victor Ng wrote: > >> I'm having problems with buliding the example applications - not >> really sure what I'm doing wrong. >> >> I've just installed py2app from it's svn trunk, and pyobjc from svn >> trunk. >> >> When I run setup.py py2app on the CurrencyConverter example, I get an >> error dialog popping up with: >> >> ImportError: >> '/Users/victorng/dev/pyobjc/trunk/pyobjc/Examples/CurrencyConverter/ >> dist/CurrencyConverter.app/Contents/Resources/Python/lib-dynload/ >> objc/_objc.so' >> not found >> >> When I try looking in the lib-dynload directory - I don't have any >> objc, AppKit or other directories that I think I'm supposed to be >> getting. >> >> Any pointers? >> vic >> >> >> On Sun, 28 Nov 2004 23:58:38 -0500, Bob Ippolito >> wrote: >>> The py2app-branch of PyObjC has been merged to trunk, and development >>> will continue on trunk. For those of you that have checked out >>> py2app-branch, please svn switch back to >>> http://svn.red-bean.com/pyobjc/trunk/pyobjc >>> >>> Enhancements include but are not limited to: >>> >>> - All buildapp.py scripts are gone, bundlebuilder is no longer used >>> anywhere. Examples now have setup.py scripts and are built with >>> "python setup.py py2app". >>> - The way setup.py works has changed significantly. It now supports >>> a >>> bdist_mpkg command to build a .mpkg distribution containing both >>> PyObjC >>> and py2app >>> - Includes a copy of what will be py2app 0.1.6 (or possibly 0.2.0 .. >>> depending on what else I change) >>> - Enhanced compatibility with the Apple Objective C runtime >>> - Bugfixes and minor feature additions on several other fronts >>> - A sandbox directory with some new half-baked ideas for a new >>> Objective C header parser >>> >>> The Xcode template still does not support py2app. I would recommend >>> that if you use Xcode, you should only use it for development. >>> Deployment should be done using py2app. >>> >>> -bob >>> >>> ------------------------------------------------------- >>> SF email is sponsored by - The IT Product Guide >>> Read honest & candid reviews on hundreds of IT Products from real >>> users. >>> Discover which products truly live up to the hype. Start reading now. >>> http://productguide.itmanagersjournal.com/ >>> _______________________________________________ >>> Pyobjc-dev mailing list >>> Pyobjc-dev@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev >>> > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real > users. > Discover which products truly live up to the hype. Start reading > now.http://productguide.itmanagersjournal.com/ > _______________________________________________ > Pyobjc-dev mailing list > Pyobjc-dev@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/pyobjc-dev From bob at redivi.com Sun Dec 5 16:37:19 2004 From: bob at redivi.com (Bob Ippolito) Date: Sun Dec 5 16:37:56 2004 Subject: [Pythonmac-SIG] Re: [Pyobjc-dev] PyObjC py2app-branch merged to trunk In-Reply-To: <7292DABC-46D2-11D9-8179-000A95C5186E@mac.com> References: <54F492AE-41C3-11D9-813B-000A9567635C@redivi.com> <398CE00E-4616-11D9-81C9-000A95BA5446@redivi.com> <7292DABC-46D2-11D9-8179-000A95C5186E@mac.com> Message-ID: <8C56FA0C-46D3-11D9-81C9-000A95BA5446@redivi.com> On Dec 5, 2004, at 10:29, Victor Ng wrote: > Thanks for the tips - I'm on 10.3 and I've just gone through and > deleted py2app and PyObjC files from /Library/Python/2.3/ and > /System/Library/.../site-packages, reinstalled using the bdist pkg and > still no luck. These are separate directories!@"?# site-packages should be a symlink to /Library/Python/2.3. Maybe wxPython broke your symlink? > I just tried everything on another 10.3 machine and everything works > without any issues. Weird. I've been getting other strange behavior > on my computer - time to reinstall Panther. crap. Yeah. It does work fine on a normal setup :) -bob From kranki at mac.com Sun Dec 5 16:39:52 2004 From: kranki at mac.com (Robert White) Date: Sun Dec 5 16:39:58 2004 Subject: [Pythonmac-SIG] Compiling Embedded Programs using autoconf et al update Message-ID: This is just an update of what I have been doing to figure out how to create a platform-independent means of compiling programs that embed python. Since I am really new to most all of this, please let me know if you think I am going in the wrong direction. First, I grabbed runFunc.c from python.org to use for testing and read the embedding and extending document. Then, since I had read the book, "GNU Autoconf, Automake, and Libtool", I started using it to create configure.in and appropriate Makefile.am's. However, I haven't gotten very far with this since it requires a little more knowledge than what I have accumulated to date. Well, I was thinking about going back and starting to use the XChat2 autoconf stuff for Python when it dawned on me that compiling extensions is very similar to compiling embedded programs. So, I went back to the "Python Cookbook" which has an example of an extension, elemlist, and it pointed me to the standard for installing extensions is to use distutils and create a fairly simple setup.py. Since "python setup.py install" seems to be cross-platform, I created a simple shell script from its output (using --dry-run) and used that to compile and link runFunc. It seems that compiling and linking extensions and embedded programs is very similar. (Please correct me if I am wrong on this.) So, next I am now going thru the source for distutils with the hope that I can learn how to use it to generate the compile and link commands that I need for an autoconf setup. If it won't then I hope to create patches that will allow me to and try to get them implemented by the distutils team if that is possible. I do know in looking at the --dry-run stuff that at least for MacOSX 10.3, it knows everything that needs to be done and it is much simpler than trying to work with the LINKFORSHARED variable of sysconfig. Anyway, that it the direction that I am currently pursuing unless someone here indicates that that is not a good path to follow. Thanks for your help. BTW, I installed Darwin 7.2.1 on a spare Powerbook G4 that I have and got the information from sysconfig from it. I was pleased to find out that it installs quite easily and had python and cvs built into it. From vng1 at mac.com Sun Dec 5 18:14:20 2004 From: vng1 at mac.com (Victor Ng) Date: Sun Dec 5 18:14:28 2004 Subject: [Pythonmac-SIG] Re: [Pyobjc-dev] PyObjC py2app-branch merged to trunk In-Reply-To: <8C56FA0C-46D3-11D9-81C9-000A95BA5446@redivi.com> References: <54F492AE-41C3-11D9-813B-000A9567635C@redivi.com> <398CE00E-4616-11D9-81C9-000A95BA5446@redivi.com> <7292DABC-46D2-11D9-8179-000A95C5186E@mac.com> <8C56FA0C-46D3-11D9-81C9-000A95BA5446@redivi.com> Message-ID: <1A724A71-46E1-11D9-82CF-000A95C5186E@mac.com> On 5-Dec-04, at 10:37 AM, Bob Ippolito wrote: > On Dec 5, 2004, at 10:29, Victor Ng wrote: > >> Thanks for the tips - I'm on 10.3 and I've just gone through and >> deleted py2app and PyObjC files from /Library/Python/2.3/ and >> /System/Library/.../site-packages, reinstalled using the bdist pkg >> and still no luck. > > These are separate directories!@"?# site-packages should be a symlink > to /Library/Python/2.3. Maybe wxPython broke your symlink? Success! I moved my site-packages to /Library/Python/2.3 and rebuilt the symlink - everything works great now. I _do_ remember that when I first installed wxPython I first noticed the /Library/Python/2.3 vs /System/Library/.../site-packages discrepancy. I just assumed that this was a weird setup thing that Apple had done and I only noticed it when wx was installed. Thanks Bob! vic -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3901 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20041205/8a4127ad/smime.bin From robert at xtrafone.com Sun Dec 5 20:21:31 2004 From: robert at xtrafone.com (=?ISO-8859-1?Q?Robert_Valsj=F6?=) Date: Sun Dec 5 20:21:34 2004 Subject: [Pythonmac-SIG] Building 2.4 In-Reply-To: <740B2622-4474-11D9-BE3A-000A95BA5446@redivi.com> References: <4C4BB602-541F-11D8-BF32-000393DB52E4@2xtreme.net> <82AB2C9C-54E8-11D8-B033-000A95C4B360@samuelsmith.org> <740B2622-4474-11D9-BE3A-000A95BA5446@redivi.com> Message-ID: On 2004-12-02, at 16.11, Bob Ippolito wrote: > On Dec 2, 2004, at 10:00, Samuel M.Smith wrote: > >> Would anyone care to post step by step instructions for building a >> framework version of Python 2.4 >> that will peacefully cohabitate with the built in OS X Python 2.3. >> >> Does it build out of the box from the source? > > Patch your config/Makefile of your existing Python 2.3.0 installation > (see a recent email of mine on the subject) > Fetch 2.4 sources > > From the 2.4 source directory do the following: > > env MACOSX_DEPLOYMENT_TARGET=10.3 ./configure --enable-framework > make > sudo make frameworkinstall > > You probably want to add /usr/local/bin early on in your path if you > haven't already, you may want to delete /usr/local/bin/python if you > want python 2.3 to be "the default", because there is also a symlink > named python2.4 that you could use. > > -bob Hi! When I do this I get: esac Traceback (most recent call last): File "./setup.py", line 1061, in ? class PyBuildInstallLib(install_lib): File "./setup.py", line 1067, in PyBuildInstallLib so_ext = sysconfig.get_config_var("SO") File "/Users/robert/Desktop/Python-2.4/Lib/distutils/sysconfig.py", line 509, in get_config_var return get_config_vars().get(name) File "/Users/robert/Desktop/Python-2.4/Lib/distutils/sysconfig.py", line 486, in get_config_vars func() File "/Users/robert/Desktop/Python-2.4/Lib/distutils/sysconfig.py", line 371, in _init_posix raise DistutilsPlatformError(my_msg) distutils.errors.DistutilsPlatformError: $MACOSX_DEPLOYMENT_TARGET mismatch: now "" but "10.3" during configure make: *** [sharedmods] Error 1 Any suggestion? /rob Robert Valsj? Xtrafone www.xtrafone.com E-mail: robert@xtrafone.com From bob at redivi.com Mon Dec 6 04:22:33 2004 From: bob at redivi.com (Bob Ippolito) Date: Mon Dec 6 04:23:12 2004 Subject: [Pythonmac-SIG] Building 2.4 In-Reply-To: References: <4C4BB602-541F-11D8-BF32-000393DB52E4@2xtreme.net> <82AB2C9C-54E8-11D8-B033-000A95C4B360@samuelsmith.org> <740B2622-4474-11D9-BE3A-000A95BA5446@redivi.com> Message-ID: <11739DB3-4736-11D9-8917-000A9567635C@redivi.com> On Dec 5, 2004, at 2:21 PM, Robert Valsj? wrote: > On 2004-12-02, at 16.11, Bob Ippolito wrote: > >> On Dec 2, 2004, at 10:00, Samuel M.Smith wrote: >> >>> Would anyone care to post step by step instructions for building a >>> framework version of Python 2.4 >>> that will peacefully cohabitate with the built in OS X Python 2.3. >>> >>> Does it build out of the box from the source? >> >> Patch your config/Makefile of your existing Python 2.3.0 installation >> (see a recent email of mine on the subject) >> Fetch 2.4 sources >> >> From the 2.4 source directory do the following: >> >> env MACOSX_DEPLOYMENT_TARGET=10.3 ./configure --enable-framework >> make >> sudo make frameworkinstall >> >> You probably want to add /usr/local/bin early on in your path if you >> haven't already, you may want to delete /usr/local/bin/python if you >> want python 2.3 to be "the default", because there is also a symlink >> named python2.4 that you could use. >> >> -bob > > Hi! > > When I do this I get: > > esac > Traceback (most recent call last): > File "./setup.py", line 1061, in ? > class PyBuildInstallLib(install_lib): > File "./setup.py", line 1067, in PyBuildInstallLib > so_ext = sysconfig.get_config_var("SO") > File "/Users/robert/Desktop/Python-2.4/Lib/distutils/sysconfig.py", > line 509, in get_config_var > return get_config_vars().get(name) > File "/Users/robert/Desktop/Python-2.4/Lib/distutils/sysconfig.py", > line 486, in get_config_vars > func() > File "/Users/robert/Desktop/Python-2.4/Lib/distutils/sysconfig.py", > line 371, in _init_posix > raise DistutilsPlatformError(my_msg) > distutils.errors.DistutilsPlatformError: $MACOSX_DEPLOYMENT_TARGET > mismatch: now "" but "10.3" during configure > make: *** [sharedmods] Error 1 Yes, also set the environment variables for make. -bob From vng1 at mac.com Sun Dec 5 16:29:25 2004 From: vng1 at mac.com (Victor Ng) Date: Mon Dec 6 10:45:03 2004 Subject: [Pythonmac-SIG] Re: [Pyobjc-dev] PyObjC py2app-branch merged to trunk In-Reply-To: <398CE00E-4616-11D9-81C9-000A95BA5446@redivi.com> References: <54F492AE-41C3-11D9-813B-000A9567635C@redivi.com> <398CE00E-4616-11D9-81C9-000A95BA5446@redivi.com> Message-ID: <7292DABC-46D2-11D9-8179-000A95C5186E@mac.com> Thanks for the tips - I'm on 10.3 and I've just gone through and deleted py2app and PyObjC files from /Library/Python/2.3/ and /System/Library/.../site-packages, reinstalled using the bdist pkg and still no luck. I just tried everything on another 10.3 machine and everything works without any issues. Weird. I've been getting other strange behavior on my computer - time to reinstall Panther. crap. vic On 4-Dec-04, at 12:02 PM, Bob Ippolito wrote: > After waking up a bit I realized this is could possibly be because you > didn't remove an old PyObjC installation first. Do that, and then > reinstall. > > Using the bdist_mpkg installer (which will also install py2app) is > another way to wipe the old installation clean. From the pyobjc > source tree: > % python setup.py bdist_mpkg --open > > If that doesn't work, I'm not sure what to tell you, because it works > just fine on three computers here (one OS X 10.2 and two OS X 10.3) > with standard-enough configurations. > > -bob > > On Dec 4, 2004, at 11:45, Bob Ippolito wrote: > >> What version of Mac OS X is this? >> >> On Dec 4, 2004, at 10:36, Victor Ng wrote: >> >>> I'm having problems with buliding the example applications - not >>> really sure what I'm doing wrong. >>> >>> I've just installed py2app from it's svn trunk, and pyobjc from svn >>> trunk. >>> >>> When I run setup.py py2app on the CurrencyConverter example, I get an >>> error dialog popping up with: >>> >>> ImportError: >>> '/Users/victorng/dev/pyobjc/trunk/pyobjc/Examples/CurrencyConverter/ >>> dist/CurrencyConverter.app/Contents/Resources/Python/lib-dynload/ >>> objc/_objc.so' >>> not found >>> >>> When I try looking in the lib-dynload directory - I don't have any >>> objc, AppKit or other directories that I think I'm supposed to be >>> getting. >>> >>> Any pointers? >>> vic >>> >>> >>> On Sun, 28 Nov 2004 23:58:38 -0500, Bob Ippolito >>> wrote: >>>> The py2app-branch of PyObjC has been merged to trunk, and >>>> development >>>> will continue on trunk. For those of you that have checked out >>>> py2app-branch, please svn switch back to >>>> http://svn.red-bean.com/pyobjc/trunk/pyobjc >>>> >>>> Enhancements include but are not limited to: >>>> >>>> - All buildapp.py scripts are gone, bundlebuilder is no longer used >>>> anywhere. Examples now have setup.py scripts and are built with >>>> "python setup.py py2app". >>>> - The way setup.py works has changed significantly. It now >>>> supports a >>>> bdist_mpkg command to build a .mpkg distribution containing both >>>> PyObjC >>>> and py2app >>>> - Includes a copy of what will be py2app 0.1.6 (or possibly 0.2.0 .. >>>> depending on what else I change) >>>> - Enhanced compatibility with the Apple Objective C runtime >>>> - Bugfixes and minor feature additions on several other fronts >>>> - A sandbox directory with some new half-baked ideas for a new >>>> Objective C header parser >>>> >>>> The Xcode template still does not support py2app. I would recommend >>>> that if you use Xcode, you should only use it for development. >>>> Deployment should be done using py2app. >>>> >>>> -bob >>>> >>>> ------------------------------------------------------- >>>> SF email is sponsored by - The IT Product Guide >>>> Read honest & candid reviews on hundreds of IT Products from real >>>> users. >>>> Discover which products truly live up to the hype. Start reading >>>> now. >>>> http://productguide.itmanagersjournal.com/ >>>> _______________________________________________ >>>> Pyobjc-dev mailing list >>>> Pyobjc-dev@lists.sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev >>>> >> >> >> >> ------------------------------------------------------- >> SF email is sponsored by - The IT Product Guide >> Read honest & candid reviews on hundreds of IT Products from real >> users. >> Discover which products truly live up to the hype. Start reading >> now.http://productguide.itmanagersjournal.com/ >> _______________________________________________ >> Pyobjc-dev mailing list >> Pyobjc-dev@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3901 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20041205/25bf73a9/smime-0001.bin From vm at klankschap.nl Mon Dec 6 10:52:20 2004 From: vm at klankschap.nl (Floris van Manen) Date: Mon Dec 6 10:52:24 2004 Subject: [Pythonmac-SIG] Building 2.4 In-Reply-To: <11739DB3-4736-11D9-8917-000A9567635C@redivi.com> References: <4C4BB602-541F-11D8-BF32-000393DB52E4@2xtreme.net> <82AB2C9C-54E8-11D8-B033-000A95C4B360@samuelsmith.org> <740B2622-4474-11D9-BE3A-000A95BA5446@redivi.com> <11739DB3-4736-11D9-8917-000A9567635C@redivi.com> Message-ID: <12486359.20041206105220@klankschap.nl> BI> Yes, also set the environment variables for make. Being a novice python programmer for at least some years to come, a simple question came up. How difficult would it be for the eminent mac python gurus to provide a python script (GetGoing.py :-) doing all the installation needed to install the new 2.4 version as a *replacement* for the pre-installed 2.3 version on osx 10.3 ? thanks! Floris van Manen From ronaldoussoren at mac.com Mon Dec 6 14:12:51 2004 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Mon Dec 6 14:13:01 2004 Subject: [Pythonmac-SIG] Building 2.4 In-Reply-To: References: <4C4BB602-541F-11D8-BF32-000393DB52E4@2xtreme.net> <82AB2C9C-54E8-11D8-B033-000A95C4B360@samuelsmith.org> <740B2622-4474-11D9-BE3A-000A95BA5446@redivi.com> <9FDF2616-4511-11D9-9361-000D93AD379E@mac.com> Message-ID: <88DBB6D6-4788-11D9-B7E2-000D93AD379E@mac.com> On 3-dec-04, at 16:55, Ronald Oussoren wrote: > > I'll see if I can build a working example for this tomorrow. The timemachine failed, but I managed to create something that actually works. The attached pseudo-package patches distutils when you try to import it. It performs two patches: 1) The changed linking command as mentioned before in this thread 2) Distutils will now install scripts and include-files in /Library/Python/2.3/additional-files. The buildext command should also pick up the include-files that are installed in additional-files. Item 2 takes away the need to change the permissions and/or ownership of files in /System/Library/Python.framework. NOTE: this code is barely tested. Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: distutils-hack.tar.gz Type: application/x-gzip Size: 2708 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20041206/3e0fafed/distutils-hack.tar.bin From bob at redivi.com Mon Dec 6 15:26:35 2004 From: bob at redivi.com (Bob Ippolito) Date: Mon Dec 6 15:26:47 2004 Subject: [Pythonmac-SIG] Building 2.4 In-Reply-To: <12486359.20041206105220@klankschap.nl> References: <4C4BB602-541F-11D8-BF32-000393DB52E4@2xtreme.net> <82AB2C9C-54E8-11D8-B033-000A95C4B360@samuelsmith.org> <740B2622-4474-11D9-BE3A-000A95BA5446@redivi.com> <11739DB3-4736-11D9-8917-000A9567635C@redivi.com> <12486359.20041206105220@klankschap.nl> Message-ID: On Dec 6, 2004, at 4:52, Floris van Manen wrote: > > BI> Yes, also set the environment variables for make. > > > Being a novice python programmer for at least some years to come, a > simple question came up. > How difficult would it be for the eminent mac python gurus to provide > a python script (GetGoing.py :-) doing all the installation needed to > install the new 2.4 version as a *replacement* for the pre-installed > 2.3 > version on osx 10.3 ? Extremely difficult, because nobody who knows what they're doing is going to encourage you to replace *ANY* pre-installed Apple software. Touching files in /System and /usr (except /usr/local) is primarily reserved for Apple, and changing anything in there is almost guaranteed to break something. Install it to the standard place, and change your $PATH such that /usr/local/bin comes before /usr/bin. Then when you type "python" you get Python 2.4. That's probably what you actually want, anyway. -bob From whamoo at rknet.it Mon Dec 6 18:44:10 2004 From: whamoo at rknet.it (whamoo) Date: Mon Dec 6 18:43:19 2004 Subject: [Pythonmac-SIG] Building 2.4 In-Reply-To: References: <4C4BB602-541F-11D8-BF32-000393DB52E4@2xtreme.net> <82AB2C9C-54E8-11D8-B033-000A95C4B360@samuelsmith.org> <740B2622-4474-11D9-BE3A-000A95BA5446@redivi.com> <11739DB3-4736-11D9-8917-000A9567635C@redivi.com> <12486359.20041206105220@klankschap.nl> Message-ID: <6F83EEA3-47AE-11D9-A1AB-000A95C62238@rknet.it> >> > > Extremely difficult, because nobody who knows what they're doing is > going to encourage you to replace *ANY* pre-installed Apple software. > Touching files in /System and /usr (except /usr/local) is primarily > reserved for Apple, and changing anything in there is almost > guaranteed to break something. > > Install it to the standard place, and change your $PATH such that > /usr/local/bin comes before /usr/bin. Then when you type "python" you > get Python 2.4. That's probably what you actually want, anyway. > > -bob But in this way i need to reinstall all third part modules.... There is a way to use old modules with python2.4 without reinstall all? (i have all modulen in (Library/Python/2.3) Whamoo www.rknet.it Powered by: - MacOsX - Gnu / Linux Debian Sarge - Amiga Os 3.9 - Milk From bob at redivi.com Mon Dec 6 19:00:18 2004 From: bob at redivi.com (Bob Ippolito) Date: Mon Dec 6 19:00:58 2004 Subject: [Pythonmac-SIG] Building 2.4 In-Reply-To: <6F83EEA3-47AE-11D9-A1AB-000A95C62238@rknet.it> References: <4C4BB602-541F-11D8-BF32-000393DB52E4@2xtreme.net> <82AB2C9C-54E8-11D8-B033-000A95C4B360@samuelsmith.org> <740B2622-4474-11D9-BE3A-000A95BA5446@redivi.com> <11739DB3-4736-11D9-8917-000A9567635C@redivi.com> <12486359.20041206105220@klankschap.nl> <6F83EEA3-47AE-11D9-A1AB-000A95C62238@rknet.it> Message-ID: On Dec 6, 2004, at 12:44 PM, whamoo wrote: >>> >> >> Extremely difficult, because nobody who knows what they're doing is >> going to encourage you to replace *ANY* pre-installed Apple software. >> Touching files in /System and /usr (except /usr/local) is primarily >> reserved for Apple, and changing anything in there is almost >> guaranteed to break something. >> >> Install it to the standard place, and change your $PATH such that >> /usr/local/bin comes before /usr/bin. Then when you type "python" >> you get Python 2.4. That's probably what you actually want, anyway. > > But in this way i need to reinstall all third part modules.... > There is a way to use old modules with python2.4 without reinstall all? > (i have all modulen in (Library/Python/2.3) No! You must reinstall all third party modules that have compiled extensions. Python 2.3 and Python 2.4 DO NOT have binary compatible C APIs. -bob From bob at redivi.com Tue Dec 7 06:49:28 2004 From: bob at redivi.com (Bob Ippolito) Date: Tue Dec 7 06:50:05 2004 Subject: [Pythonmac-SIG] [ANN] py2app 0.1.6 Message-ID: I've rolled together a new 0.1.6 release of py2app that includes the following feature enhancements and probably a few bug fixes: modulegraph: - This is now a top-level package and should be cross-platformish and not at all py2app specific (if someone wants a project, integrate this into py2exe/cx_Freeze/etc.) altgraph: - Some common code between modulegraph and macholib was moved into altgraph (the ObjectGraph data structure, for example) macholib: - Lots of code in its supporting library, ptypes, was removed, rewritten and optimized for performance and simplicity. - The API has totally been changed (I don't think anyone else uses it, so I don't feel bad about it :) - It uses altgraph for its data structure now - More correct algorithms for locating dylibs and frameworks based upon a thorough reading of the dyld source code bdist_mpkg: - Made the dependency checking more specific for better Installer compatibility - Fixed some minor bugs py2app: - New "plugin" target for building loadable bundles (i.e. Interface Builder palettes). This is a crazy hack, and will never work perfectly due to the icky globalness of the Python interpreter, but works well enough in practice. - Plugin example - Sets a new ARGVZERO environment variable that points to the argv[0] that was passed to main(...). - Sets a new EXECUTABLEPATH environment variable that points to the actual path of the executable that was run (which will be == to ARGVZERO most of the time) - suboptimal PyQt support (sip and PyQt are built in really strange ways and have lots of interdependencies at the C/C++ level so whenever you use ANY sip module you use ALL sip modules) - PyQt example - suboptimal PyOpenGL support (PyOpenGL has a stupid way of finding its version that prevents it from being easily bundled) - PyOpenGL example - py2applet command line tool (performs the same function as the GUI app) -bob From bob at redivi.com Tue Dec 7 10:18:49 2004 From: bob at redivi.com (Bob Ippolito) Date: Tue Dec 7 10:19:29 2004 Subject: [Pythonmac-SIG] Re: [Pyobjc-dev] [ANN] py2app 0.1.6 In-Reply-To: <838D9B37-482E-11D9-9D88-000D93C455C0@knuddl.org> References: <838D9B37-482E-11D9-9D88-000D93C455C0@knuddl.org> Message-ID: <00F4B6A1-4831-11D9-8917-000A9567635C@redivi.com> I did some reorganization of the packages (I put them in a .pth'ed directory). It does clean out some of the old py2app, but fails to clean out macholib and altgraph. If you do this, then it should work, because the "py2app" directory was indeed cleaned when you upgraded: rm -rf /Library/Python/2.3/macholib rm -rf /Library/Python/2.3/altgraph Typically bdist_mpkg installers *do* clean their target first, but in this case, it's installing to a different location entirely (py2app/macholib, py2app/altgraph, etc..), so the old targets were not removed. I didn't bother to test the upgrade scenario when cutting the release, so I didn't think to add these additional steps in the preflight script. Future upgrades won't have this problem, as I don't see a need to move things around like this again anytime soon :) -bob On Dec 7, 2004, at 4:00 AM, Kaweh Kazemi wrote: > bob, > > i've installed py2app-0.1.6.mpkg (i had previously 0.1.5 installed, > which i didn't de-install, presuming that this will be done > automatically). that's what i get: > > Traceback (most recent call last): > File "setup.py", line 6, in ? > import py2app > File "/purelib/py2app/py2app/__init__.py", line 33, in ? > File "/purelib/py2app/py2app/install.py", line 15, in ? > File "/purelib/py2app/py2app/command/__init__.py", line 1, in ? > File "/purelib/py2app/py2app/build_app.py", line 20, in ? > File "/purelib/py2app/modulegraph/find_modules.py", line 21, in ? > File "/purelib/py2app/modulegraph/modulegraph.py", line 15, in ? > ImportError: No module named ObjectGraph > > did i miss anything? > > thanks, > kw. > > > On 07.12.2004, at 06:49, Bob Ippolito wrote: > >> I've rolled together a new 0.1.6 release of py2app >> that includes the following >> feature enhancements and probably a few bug fixes: >> >> modulegraph: >> - This is now a top-level package and should be cross-platformish and >> not at all py2app specific (if someone wants a project, integrate >> this into py2exe/cx_Freeze/etc.) >> >> altgraph: >> - Some common code between modulegraph and macholib was moved into >> altgraph (the ObjectGraph data structure, for example) >> >> macholib: >> - Lots of code in its supporting library, ptypes, was removed, >> rewritten and optimized for performance and simplicity. >> - The API has totally been changed (I don't think anyone else uses >> it, so I don't feel bad about it :) >> - It uses altgraph for its data structure now >> - More correct algorithms for locating dylibs and frameworks based >> upon a thorough reading of the dyld source code >> >> bdist_mpkg: >> - Made the dependency checking more specific for better Installer >> compatibility >> - Fixed some minor bugs >> >> py2app: >> - New "plugin" target for building loadable bundles (i.e. Interface >> Builder palettes). This is a crazy hack, and will never work >> perfectly due to the icky globalness of the Python interpreter, but >> works well enough in practice. >> - Plugin example >> - Sets a new ARGVZERO environment variable that points to the argv[0] >> that was passed to main(...). >> - Sets a new EXECUTABLEPATH environment variable that points to the >> actual path of the executable that was run (which will be == to >> ARGVZERO most of the time) >> - suboptimal PyQt support (sip and PyQt are built in really strange >> ways and have lots of interdependencies at the C/C++ level so >> whenever you use ANY sip module you use ALL sip modules) >> - PyQt example >> - suboptimal PyOpenGL support (PyOpenGL has a stupid way of finding >> its version that prevents it from being easily bundled) >> - PyOpenGL example >> - py2applet command line tool (performs the same function as the GUI >> app) >> >> -bob >> >> >> >> ------------------------------------------------------- >> SF email is sponsored by - The IT Product Guide >> Read honest & candid reviews on hundreds of IT Products from real >> users. >> Discover which products truly live up to the hype. Start reading now. >> http://productguide.itmanagersjournal.com/ >> _______________________________________________ >> Pyobjc-dev mailing list >> Pyobjc-dev@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev >> > From bob at redivi.com Tue Dec 7 10:22:26 2004 From: bob at redivi.com (Bob Ippolito) Date: Tue Dec 7 10:23:11 2004 Subject: [Pythonmac-SIG] Re: [Pyobjc-dev] [ANN] py2app 0.1.6 In-Reply-To: <00F4B6A1-4831-11D9-8917-000A9567635C@redivi.com> References: <838D9B37-482E-11D9-9D88-000D93C455C0@knuddl.org> <00F4B6A1-4831-11D9-8917-000A9567635C@redivi.com> Message-ID: <82B12A8A-4831-11D9-8917-000A9567635C@redivi.com> er.. missed one: rm -rf /Library/Python/2.3/bdist_mpkg On Dec 7, 2004, at 4:18 AM, Bob Ippolito wrote: > I did some reorganization of the packages (I put them in a .pth'ed > directory). It does clean out some of the old py2app, but fails to > clean out macholib and altgraph. > > If you do this, then it should work, because the "py2app" directory > was indeed cleaned when you upgraded: > rm -rf /Library/Python/2.3/macholib > rm -rf /Library/Python/2.3/altgraph > > Typically bdist_mpkg installers *do* clean their target first, but in > this case, it's installing to a different location entirely > (py2app/macholib, py2app/altgraph, etc..), so the old targets were not > removed. I didn't bother to test the upgrade scenario when cutting > the release, so I didn't think to add these additional steps in the > preflight script. > > Future upgrades won't have this problem, as I don't see a need to move > things around like this again anytime soon :) > > -bob > > On Dec 7, 2004, at 4:00 AM, Kaweh Kazemi wrote: > >> bob, >> >> i've installed py2app-0.1.6.mpkg (i had previously 0.1.5 installed, >> which i didn't de-install, presuming that this will be done >> automatically). that's what i get: >> >> Traceback (most recent call last): >> File "setup.py", line 6, in ? >> import py2app >> File "/purelib/py2app/py2app/__init__.py", line 33, in ? >> File "/purelib/py2app/py2app/install.py", line 15, in ? >> File "/purelib/py2app/py2app/command/__init__.py", line 1, in ? >> File "/purelib/py2app/py2app/build_app.py", line 20, in ? >> File "/purelib/py2app/modulegraph/find_modules.py", line 21, in ? >> File "/purelib/py2app/modulegraph/modulegraph.py", line 15, in ? >> ImportError: No module named ObjectGraph >> >> did i miss anything? >> >> thanks, >> kw. >> >> >> On 07.12.2004, at 06:49, Bob Ippolito wrote: >> >>> I've rolled together a new 0.1.6 release of py2app >>> that includes the following >>> feature enhancements and probably a few bug fixes: >>> >>> modulegraph: >>> - This is now a top-level package and should be cross-platformish >>> and not at all py2app specific (if someone wants a project, >>> integrate this into py2exe/cx_Freeze/etc.) >>> >>> altgraph: >>> - Some common code between modulegraph and macholib was moved into >>> altgraph (the ObjectGraph data structure, for example) >>> >>> macholib: >>> - Lots of code in its supporting library, ptypes, was removed, >>> rewritten and optimized for performance and simplicity. >>> - The API has totally been changed (I don't think anyone else uses >>> it, so I don't feel bad about it :) >>> - It uses altgraph for its data structure now >>> - More correct algorithms for locating dylibs and frameworks based >>> upon a thorough reading of the dyld source code >>> >>> bdist_mpkg: >>> - Made the dependency checking more specific for better Installer >>> compatibility >>> - Fixed some minor bugs >>> >>> py2app: >>> - New "plugin" target for building loadable bundles (i.e. Interface >>> Builder palettes). This is a crazy hack, and will never work >>> perfectly due to the icky globalness of the Python interpreter, but >>> works well enough in practice. >>> - Plugin example >>> - Sets a new ARGVZERO environment variable that points to the >>> argv[0] that was passed to main(...). >>> - Sets a new EXECUTABLEPATH environment variable that points to the >>> actual path of the executable that was run (which will be == to >>> ARGVZERO most of the time) >>> - suboptimal PyQt support (sip and PyQt are built in really strange >>> ways and have lots of interdependencies at the C/C++ level so >>> whenever you use ANY sip module you use ALL sip modules) >>> - PyQt example >>> - suboptimal PyOpenGL support (PyOpenGL has a stupid way of finding >>> its version that prevents it from being easily bundled) >>> - PyOpenGL example >>> - py2applet command line tool (performs the same function as the GUI >>> app) >>> >>> -bob >>> >>> >>> >>> ------------------------------------------------------- >>> SF email is sponsored by - The IT Product Guide >>> Read honest & candid reviews on hundreds of IT Products from real >>> users. >>> Discover which products truly live up to the hype. Start reading >>> now. http://productguide.itmanagersjournal.com/ >>> _______________________________________________ >>> Pyobjc-dev mailing list >>> Pyobjc-dev@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev >>> >> > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real > users. > Discover which products truly live up to the hype. Start reading now. > http://productguide.itmanagersjournal.com/ > _______________________________________________ > Pyobjc-dev mailing list > Pyobjc-dev@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/pyobjc-dev From robert at xtrafone.com Wed Dec 8 10:06:50 2004 From: robert at xtrafone.com (=?ISO-8859-1?Q?Robert_Valsj=F6?=) Date: Wed Dec 8 10:06:53 2004 Subject: [Pythonmac-SIG] How-To upgrade Apples python installation in Mac OS X 10.3 from python 2.3 to 2.4 Message-ID: <7F11470B-48F8-11D9-888D-000D932AD2CC@xtrafone.com> How to upgrade Apples python installation in Mac OS X 10.3 from python 2.3 to 2.4 * Download python sourde from http://www.python.org/ftp/python/2.4/Python-2.4.tgz Save the source on ~/Desktop >cd ~/Desktop >tar zxvf Python-2.4.tgz Download http://www.merzwaren.com/bin/waste/waste-21b1.sit Save it in ~/Desktop Unpack waste-21b1.sit and copy all contents to a folder called waste. >cd ~/Desktop You should now have one folder called Python-2.4 and one folder called waste on the desktop. Now you must patch your Apple python installation: >cd /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/ config/ >emacs Makefile Change in Makefile: LDSHARED= $(CC) $(LDFLAGS) -bundle -framework $(PYTHONFRAMEWORK) BLDSHARED= $(CC) $(LDFLAGS) -bundle -framework $(PYTHONFRAMEWORK) to LDSHARED= env MACOSX_DEPLOYMENT_TARGET=10.3 $(CC) $(LDFLAGS) -bundle -undefined dynamic_lookup BLDSHARED= env MACOSX_DEPLOYMENT_TARGET=10.3 $(CC) $(LDFLAGS) -bundle -undefined dynamic_lookup Start building: >cd ~/Desktop/Python-2.4 >MACOSX_DEPLOYMENT_TARGET=10.3 >export MACOSX_DEPLOYMENT_TARGET >env MACOSX_DEPLOYMENT_TARGET=10.3 ./configure --enable-framework >make >make frameworkinstall >make frameworkinstallextras Change you PATH: >emacs ~/.bashrc Add: PATH=/usr/local/bin:$PATH export PATH This seems to work for me. Please let me know if something is missing. Robert Valsj? Xtrafone www.xtrafone.com E-mail: robert@xtrafone.com From abecassi at drecam.saclay.cea.fr Tue Dec 7 17:57:48 2004 From: abecassi at drecam.saclay.cea.fr (=?ISO-8859-1?Q?Benjamin_Ab=E9cassis?=) Date: Wed Dec 8 10:12:26 2004 Subject: [Pythonmac-SIG] Won't Install Numarray-1.1.1 or Numeric_23.6 Message-ID: <1F9E33FF-4871-11D9-B594-000D93554544@drecam.saclay.cea.fr> Hi everyone, I can't install Numarray-1.1.1 or Numeric_23.6 After typing, python setup.py install it tells, error: command 'gcc' failed with exit status 1 Here is the complete log : running install running build running build_py running build_ext building '_numpy' extension gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I/System/Library/Frameworks/vecLib.framework/Headers -IInclude -IPackages/FFT/Include -IPackages/RNG/Include -I/System/Library/Frameworks/Python.framework/Versions/2.3/include/ python2.3 -c Src/arrayobject.c -o build/temp.darwin-7.6.0-Power_Macintosh-2.3/Src/arrayobject.o unable to execute gcc: No such file or directory error: command 'gcc' failed with exit status 1 If anyone is aware of that problem ??!! Apart from that python seems to mork pretty well... Thanks in advance. B.A. From bob at redivi.com Wed Dec 8 15:13:08 2004 From: bob at redivi.com (Bob Ippolito) Date: Wed Dec 8 15:13:18 2004 Subject: [Pythonmac-SIG] Won't Install Numarray-1.1.1 or Numeric_23.6 In-Reply-To: <1F9E33FF-4871-11D9-B594-000D93554544@drecam.saclay.cea.fr> References: <1F9E33FF-4871-11D9-B594-000D93554544@drecam.saclay.cea.fr> Message-ID: <4923DADE-4923-11D9-8733-000A95BA5446@redivi.com> On Dec 7, 2004, at 11:57, Benjamin Ab?cassis wrote: > > Hi everyone, > I can't install Numarray-1.1.1 or Numeric_23.6 > After typing, python setup.py install > it tells, > > error: command 'gcc' failed with exit status 1 > > Here is the complete log : > > running install > running build > running build_py > running build_ext > building '_numpy' extension > gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp > -mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3 -Wall > -Wstrict-prototypes > -I/System/Library/Frameworks/vecLib.framework/Headers -IInclude > -IPackages/FFT/Include -IPackages/RNG/Include > -I/System/Library/Frameworks/Python.framework/Versions/2.3/include/ > python2.3 -c Src/arrayobject.c -o > build/temp.darwin-7.6.0-Power_Macintosh-2.3/Src/arrayobject.o > unable to execute gcc: No such file or directory > error: command 'gcc' failed with exit status 1 > > > If anyone is aware of that problem ??!! Apart from that python seems > to mork pretty well... You're going to need to install Xcode. A default installation of Mac OS X does not have a C compiler. You could get a binary installer for Numeric 23.6 from here in the meantime, though: http://mail.python.org/pipermail/pythonmac-sig/2004-November/012077.html -bob From dreedmac at columbus.rr.com Wed Dec 8 15:15:48 2004 From: dreedmac at columbus.rr.com (David Reed) Date: Wed Dec 8 15:15:56 2004 Subject: [Pythonmac-SIG] Won't Install Numarray-1.1.1 or Numeric_23.6 In-Reply-To: <1F9E33FF-4871-11D9-B594-000D93554544@drecam.saclay.cea.fr> References: <1F9E33FF-4871-11D9-B594-000D93554544@drecam.saclay.cea.fr> Message-ID: On Dec 7, 2004, at 11:57 AM, Benjamin Ab?cassis wrote: > > Hi everyone, > I can't install Numarray-1.1.1 or Numeric_23.6 > After typing, python setup.py install > it tells, > > error: command 'gcc' failed with exit status 1 > > Here is the complete log : > > running install > running build > running build_py > running build_ext > building '_numpy' extension > gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp > -mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3 -Wall > -Wstrict-prototypes > -I/System/Library/Frameworks/vecLib.framework/Headers -IInclude > -IPackages/FFT/Include -IPackages/RNG/Include > -I/System/Library/Frameworks/Python.framework/Versions/2.3/include/ > python2.3 -c Src/arrayobject.c -o > build/temp.darwin-7.6.0-Power_Macintosh-2.3/Src/arrayobject.o > unable to execute gcc: No such file or directory > error: command 'gcc' failed with exit status 1 > > > If anyone is aware of that problem ??!! Apart from that python seems > to mork pretty well... > > Thanks in advance. I'm fairly new to OSX, but it looks to me like you don't have gcc installed. At your terminal window try: "which gcc" (w/o the quotes). It should return: /usr/bin/gcc If not, you need to install Apple's XCode which contains gcc and other development tools. XCode may be on the CD or in an directory on your harddrive, but I would recommend downloading the latest version from apple.com since it has some bug fixes you'll want. Dave From cmeesters at ucdavis.edu Wed Dec 8 19:53:48 2004 From: cmeesters at ucdavis.edu (Christian Meesters) Date: Wed Dec 8 19:53:54 2004 Subject: [Pythonmac-SIG] How-To upgrade Apples python installation in Mac OS X 10.3 from python 2.3 to 2.4 In-Reply-To: <7F11470B-48F8-11D9-888D-000D932AD2CC@xtrafone.com> References: <7F11470B-48F8-11D9-888D-000D932AD2CC@xtrafone.com> Message-ID: <7EE28975-494A-11D9-BD76-000393D8EC3A@ucdavis.edu> Thanks, interesting. But does anybody know how this will effect pythonw (e.g. for use with wxPython)? Admittingly I'm a bit hesitant to try out. Cheers Christian On Dec 8, 2004, at 1:06 AM, Robert Valsj? wrote: > How to upgrade Apples python installation in Mac OS X 10.3 from python > 2.3 to 2.4 > > * Download python sourde from > http://www.python.org/ftp/python/2.4/Python-2.4.tgz > Save the source on ~/Desktop > >cd ~/Desktop > >tar zxvf Python-2.4.tgz > > Download http://www.merzwaren.com/bin/waste/waste-21b1.sit > Save it in ~/Desktop > Unpack waste-21b1.sit and copy all contents to a folder called waste. > > >cd ~/Desktop > > You should now have one folder called Python-2.4 and one folder called > waste on the desktop. > > Now you must patch your Apple python installation: > > >cd > /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/config/ > >emacs Makefile > > Change in Makefile: > > LDSHARED= $(CC) $(LDFLAGS) -bundle -framework $(PYTHONFRAMEWORK) > BLDSHARED= $(CC) $(LDFLAGS) -bundle -framework $(PYTHONFRAMEWORK) > > to > > LDSHARED= env MACOSX_DEPLOYMENT_TARGET=10.3 $(CC) $(LDFLAGS) -bundle > -undefined dynamic_lookup > BLDSHARED= env MACOSX_DEPLOYMENT_TARGET=10.3 $(CC) $(LDFLAGS) -bundle > -undefined dynamic_lookup > > > Start building: > > >cd ~/Desktop/Python-2.4 > >MACOSX_DEPLOYMENT_TARGET=10.3 > >export MACOSX_DEPLOYMENT_TARGET > >env MACOSX_DEPLOYMENT_TARGET=10.3 ./configure --enable-framework > >make > >make frameworkinstall > >make frameworkinstallextras > > Change you PATH: > > >emacs ~/.bashrc > > Add: > > PATH=/usr/local/bin:$PATH > export PATH > > This seems to work for me. Please let me know if something is missing. > > Robert Valsj? > Xtrafone > www.xtrafone.com > E-mail: robert@xtrafone.com > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From bob at redivi.com Wed Dec 8 20:04:29 2004 From: bob at redivi.com (Bob Ippolito) Date: Wed Dec 8 20:05:14 2004 Subject: [Pythonmac-SIG] How-To upgrade Apples python installation in Mac OS X 10.3 from python 2.3 to 2.4 In-Reply-To: <7EE28975-494A-11D9-BD76-000393D8EC3A@ucdavis.edu> References: <7F11470B-48F8-11D9-888D-000D932AD2CC@xtrafone.com> <7EE28975-494A-11D9-BD76-000393D8EC3A@ucdavis.edu> Message-ID: On Dec 8, 2004, at 1:53 PM, Christian Meesters wrote: > On Dec 8, 2004, at 1:06 AM, Robert Valsj? wrote: > >> How to upgrade Apples python installation in Mac OS X 10.3 from >> python 2.3 to 2.4 ... > Thanks, interesting. But does anybody know how this will effect > pythonw (e.g. for use with wxPython)? > Admittingly I'm a bit hesitant to try out. The title is incorrect, it doesn't upgrade anything. It installs a new Python that is entirely separate from the existing installation. /usr/local/bin/python is Python 2.4.0 /usr/bin/python is Python 2.3.0 /usr/local/bin/pythonw is Python 2.4.0 /usr/bin/pythonw is Python 2.3.0 The only "upgrade" is the change to the PATH environment variable, which prioritizes /usr/local/bin over anything else when looking for what to execute if a full path isn't specified. Your wxPython for Python 2.3.0 is still there, and will be available from /usr/bin/pythonw. Of course, it won't be available from Python 2.4.0 unless you compile and install such a version of wxPython. -bob From cmeesters at ucdavis.edu Wed Dec 8 20:13:56 2004 From: cmeesters at ucdavis.edu (Christian Meesters) Date: Wed Dec 8 20:14:02 2004 Subject: [Pythonmac-SIG] How-To upgrade Apples python installation in Mac OS X 10.3 from python 2.3 to 2.4 In-Reply-To: References: <7F11470B-48F8-11D9-888D-000D932AD2CC@xtrafone.com> <7EE28975-494A-11D9-BD76-000393D8EC3A@ucdavis.edu> Message-ID: <4E9B070C-494D-11D9-BD76-000393D8EC3A@ucdavis.edu> On Dec 8, 2004, at 11:04 AM, Bob Ippolito wrote: > On Dec 8, 2004, at 1:53 PM, Christian Meesters wrote: > >> On Dec 8, 2004, at 1:06 AM, Robert Valsj? wrote: >> >>> How to upgrade Apples python installation in Mac OS X 10.3 from >>> python 2.3 to 2.4 > ... > >> Thanks, interesting. But does anybody know how this will effect >> pythonw (e.g. for use with wxPython)? >> Admittingly I'm a bit hesitant to try out. > > The title is incorrect, it doesn't upgrade anything. It installs a > new Python that is entirely separate from the existing installation. > > /usr/local/bin/python is Python 2.4.0 > /usr/bin/python is Python 2.3.0 > > /usr/local/bin/pythonw is Python 2.4.0 > /usr/bin/pythonw is Python 2.3.0 Sure, I realised that we are dealing here with a fresh installation, but wasn't aware that this will include the pythonw framework. I guess your explicit statement is enough for people like me to understand ;-). I'll try it out this afternoon. > > The only "upgrade" is the change to the PATH environment variable, > which prioritizes /usr/local/bin over anything else when looking for > what to execute if a full path isn't specified. Your wxPython for > Python 2.3.0 is still there, and will be available from > /usr/bin/pythonw. Of course, it won't be available from Python 2.4.0 > unless you compile and install such a version of wxPython. Alas, this has to wait until wxPython will be upgraded. Thanks Bob and Robert, Christian From bob at redivi.com Wed Dec 8 20:19:20 2004 From: bob at redivi.com (Bob Ippolito) Date: Wed Dec 8 20:19:59 2004 Subject: [Pythonmac-SIG] How-To upgrade Apples python installation in Mac OS X 10.3 from python 2.3 to 2.4 In-Reply-To: <4E9B070C-494D-11D9-BD76-000393D8EC3A@ucdavis.edu> References: <7F11470B-48F8-11D9-888D-000D932AD2CC@xtrafone.com> <7EE28975-494A-11D9-BD76-000393D8EC3A@ucdavis.edu> <4E9B070C-494D-11D9-BD76-000393D8EC3A@ucdavis.edu> Message-ID: <0F7FC59A-494E-11D9-8CCD-000A9567635C@redivi.com> On Dec 8, 2004, at 2:13 PM, Christian Meesters wrote: > > On Dec 8, 2004, at 11:04 AM, Bob Ippolito wrote: > >> On Dec 8, 2004, at 1:53 PM, Christian Meesters wrote: >> >>> On Dec 8, 2004, at 1:06 AM, Robert Valsj? wrote: >>> >>>> How to upgrade Apples python installation in Mac OS X 10.3 from >>>> python 2.3 to 2.4 >> ... >> >>> Thanks, interesting. But does anybody know how this will effect >>> pythonw (e.g. for use with wxPython)? >>> Admittingly I'm a bit hesitant to try out. >> >> The title is incorrect, it doesn't upgrade anything. It installs a >> new Python that is entirely separate from the existing installation. >> >> /usr/local/bin/python is Python 2.4.0 >> /usr/bin/python is Python 2.3.0 >> >> /usr/local/bin/pythonw is Python 2.4.0 >> /usr/bin/pythonw is Python 2.3.0 > Sure, I realised that we are dealing here with a fresh installation, > but wasn't aware that this will include the pythonw framework. I guess > your explicit statement is enough for people like me to understand > ;-). I'll try it out this afternoon. pythonw is a shell script that has always shipped with framework builds of Python 2.3.0 and later, just like a pythonw.exe has shipped with the Windows version of Python for quite some time. There's nothing special about it. The fact that it happens to use a "fake" application bundle that lives in the deep dark depths of Python.framework is really just an implementation detail. -bob From cmeesters at ucdavis.edu Wed Dec 8 20:25:23 2004 From: cmeesters at ucdavis.edu (Christian Meesters) Date: Wed Dec 8 20:25:28 2004 Subject: [Pythonmac-SIG] How-To upgrade Apples python installation in Mac OS X 10.3 from python 2.3 to 2.4 In-Reply-To: <0F7FC59A-494E-11D9-8CCD-000A9567635C@redivi.com> References: <7F11470B-48F8-11D9-888D-000D932AD2CC@xtrafone.com> <7EE28975-494A-11D9-BD76-000393D8EC3A@ucdavis.edu> <4E9B070C-494D-11D9-BD76-000393D8EC3A@ucdavis.edu> <0F7FC59A-494E-11D9-8CCD-000A9567635C@redivi.com> Message-ID: >> > > pythonw is a shell script that has always shipped with framework > builds of Python 2.3.0 and later, just like a pythonw.exe has shipped > with the Windows version of Python for quite some time. There's > nothing special about it. The fact that it happens to use a "fake" > application bundle that lives in the deep dark depths of > Python.framework is really just an implementation detail. Hm, uh, stupid me. Well, I wasn't aware of it. But now that I looked into it ... Well, this is something even I could write ... Thanks for pointing me on it - guess there's a lot to learn here for me. Cheers Christian From millikel at neumann.edu Wed Dec 8 19:21:46 2004 From: millikel at neumann.edu (Lawrence Milliken) Date: Wed Dec 8 23:27:34 2004 Subject: [Pythonmac-SIG] trouble with mysql-python, I think Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- BEGIN:VCARD VERSION:2.1 X-GWTYPE:USER FN:Lawrence Milliken TEL;WORK:610-558-5541 ORG:Neumann College;Library EMAIL;WORK;PREF;NGW:MILLIKEL@neumann.edu N:Milliken;Lawrence TITLE:Reference Librarian ADR;DOM;WORK;PARCEL;POSTAL:;;One Neumann Dr.;Aston;PA;19014 LABEL;DOM;WORK;PARCEL;POSTAL;ENCODING=QUOTED-PRINTABLE:Lawrence Milliken=0A= One Neumann Dr.=0A= Aston, PA 19014 END:VCARD From MILLIKEL at neumann.edu Wed Dec 8 23:17:10 2004 From: MILLIKEL at neumann.edu (Lawrence Milliken) Date: Wed Dec 8 23:27:35 2004 Subject: [Pythonmac-SIG] need help connecting to mysql with mysql-python Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- BEGIN:VCARD VERSION:2.1 X-GWTYPE:USER FN:Lawrence Milliken TEL;WORK:610-558-5541 ORG:Neumann College;Library EMAIL;WORK;PREF;NGW:MILLIKEL@neumann.edu N:Milliken;Lawrence TITLE:Reference Librarian ADR;DOM;WORK;PARCEL;POSTAL:;;One Neumann Dr.;Aston;PA;19014 LABEL;DOM;WORK;PARCEL;POSTAL;ENCODING=QUOTED-PRINTABLE:Lawrence Milliken=0A= One Neumann Dr.=0A= Aston, PA 19014 X-GWUSERID:MILLIKEL END:VCARD From cmeesters at ucdavis.edu Thu Dec 9 02:52:05 2004 From: cmeesters at ucdavis.edu (Christian Meesters) Date: Thu Dec 9 02:52:09 2004 Subject: [Pythonmac-SIG] How-To upgrade Apples python installation in Mac OS X 10.3 from python 2.3 to 2.4 In-Reply-To: <7F11470B-48F8-11D9-888D-000D932AD2CC@xtrafone.com> References: <7F11470B-48F8-11D9-888D-000D932AD2CC@xtrafone.com> Message-ID: Well, I followed Robert's instructions and it failed. I then tried to install 'directly' and got the same error message. Guess I must admit that I simply have no clue how to solve this problem. typing 'make' results in this: building 'waste' extension gcc -bundle -undefined dynamic_lookup build/temp.darwin-7.6.0-Power_Macintosh-2.4/wastemodule.o build/temp.darwin-7.6.0-Power_Macintosh-2.4/WEObjectHandlers.o build/temp.darwin-7.6.0-Power_Macintosh-2.4/WETabHooks.o build/temp.darwin-7.6.0-Power_Macintosh-2.4/WETabs.o -L../waste/Static Libraries -L/usr/local/lib -lWASTE -o build/lib.darwin-7.6.0-Power_Macintosh-2.4/waste.so -framework Carbon ld: table of contents for archive: ../waste/Static Libraries/libWASTE.a is out of date; rerun ranlib(1) (can't load from it) running build_scripts Can anybody give me a hint on what to do here? For the record: My machine runs with 10.3.6, and is an iBook (PowerPC G3). Thanks a lot in advance, Christian From bob at redivi.com Thu Dec 9 03:07:28 2004 From: bob at redivi.com (Bob Ippolito) Date: Thu Dec 9 03:08:14 2004 Subject: [Pythonmac-SIG] How-To upgrade Apples python installation in Mac OS X 10.3 from python 2.3 to 2.4 In-Reply-To: References: <7F11470B-48F8-11D9-888D-000D932AD2CC@xtrafone.com> Message-ID: <13780C1E-4987-11D9-8CCD-000A9567635C@redivi.com> On Dec 8, 2004, at 8:52 PM, Christian Meesters wrote: > Well, I followed Robert's instructions and it failed. I then tried to > install 'directly' and got the same error message. > Guess I must admit that I simply have no clue how to solve this > problem. > > typing 'make' results in this: > > building 'waste' extension > gcc -bundle -undefined dynamic_lookup > build/temp.darwin-7.6.0-Power_Macintosh-2.4/wastemodule.o > build/temp.darwin-7.6.0-Power_Macintosh-2.4/WEObjectHandlers.o > build/temp.darwin-7.6.0-Power_Macintosh-2.4/WETabHooks.o > build/temp.darwin-7.6.0-Power_Macintosh-2.4/WETabs.o -L../waste/Static > Libraries -L/usr/local/lib -lWASTE -o > build/lib.darwin-7.6.0-Power_Macintosh-2.4/waste.so -framework Carbon > ld: table of contents for archive: ../waste/Static > Libraries/libWASTE.a is out of date; rerun ranlib(1) (can't load from > it) > running build_scripts > > Can anybody give me a hint on what to do here? Yeah, do what it says: ranlib ../waste/Static\ Libraries/libWASTE.a -bob From johnlichtenstein at mac.com Thu Dec 9 05:08:57 2004 From: johnlichtenstein at mac.com (john lichtenstein) Date: Thu Dec 9 05:08:00 2004 Subject: [Pythonmac-SIG] Numarray 1.1 and Numeric 23.6 In-Reply-To: <20041208110040.186871E4013@bag.python.org> References: <20041208110040.186871E4013@bag.python.org> Message-ID: <0C8F4D4D-4998-11D9-B8C1-000D936DCF8C@mac.com> Due to a combination of bad luck (dropping laptop onto stone) and good luck (new job) I just got a clean machine. I installed in order X11 and XCode from Apple, Fink, and Darinports. Then I used Darwinports to update Python, Numeric, and Numarray. In this was it required very little skill to set to [Python, numarray, Numeric] = [2.4, 1.1, 23.6]. > From: Benjamin Ab?cassis > Date: December 7, 2004 8:57:48 AM PST > To: pythonmac-sig@python.org > Subject: [Pythonmac-SIG] Won't Install Numarray-1.1.1 or Numeric_23.6 > > > > Hi everyone, > I can't install Numarray-1.1.1 or Numeric_23.6 > After typing, python setup.py install > it tells, > > error: command 'gcc' failed with exit status 1 > > Here is the complete log : > > running install > running build > running build_py > running build_ext > building '_numpy' extension > gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp > -mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3 -Wall > -Wstrict-prototypes > -I/System/Library/Frameworks/vecLib.framework/Headers -IInclude > -IPackages/FFT/Include -IPackages/RNG/Include > -I/System/Library/Frameworks/Python.framework/Versions/2.3/include/ > python2.3 -c Src/arrayobject.c -o > build/temp.darwin-7.6.0-Power_Macintosh-2.3/Src/arrayobject.o > unable to execute gcc: No such file or directory > error: command 'gcc' failed with exit status 1 > > > If anyone is aware of that problem ??!! Apart from that python seems > to mork pretty well... > > Thanks in advance. > > B.A. > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 1727 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20041208/778a8c34/attachment.bin From bob at redivi.com Thu Dec 9 05:11:09 2004 From: bob at redivi.com (Bob Ippolito) Date: Thu Dec 9 05:11:49 2004 Subject: [Pythonmac-SIG] Numarray 1.1 and Numeric 23.6 In-Reply-To: <0C8F4D4D-4998-11D9-B8C1-000D936DCF8C@mac.com> References: <20041208110040.186871E4013@bag.python.org> <0C8F4D4D-4998-11D9-B8C1-000D936DCF8C@mac.com> Message-ID: <5B27ABC0-4998-11D9-8CCD-000A9567635C@redivi.com> Darwinports isn't going to do anything for you without Xcode installed either! :) On Dec 8, 2004, at 11:08 PM, john lichtenstein wrote: > Due to a combination of bad luck (dropping laptop onto stone) and good > luck (new job) I just got a clean machine. I installed in order X11 > and XCode from Apple, Fink, and Darinports. Then I used Darwinports to > update Python, Numeric, and Numarray. In this was it required very > little skill to set to [Python, numarray, Numeric] = [2.4, 1.1, 23.6]. > > >> From: Benjamin Ab?cassis >> Date: December 7, 2004 8:57:48 AM PST >> To: pythonmac-sig@python.org >> Subject: [Pythonmac-SIG] Won't Install Numarray-1.1.1 or Numeric_23.6 >> >> >> >> Hi everyone, >> I can't install Numarray-1.1.1 or Numeric_23.6 >> After typing, python setup.py install >> it tells, >> >> error: command 'gcc' failed with exit status 1 >> >> Here is the complete log : >> >> running install >> running build >> running build_py >> running build_ext >> building '_numpy' extension >> gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp >> -mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3 -Wall >> -Wstrict-prototypes >> -I/System/Library/Frameworks/vecLib.framework/Headers -IInclude >> -IPackages/FFT/Include -IPackages/RNG/Include >> -I/System/Library/Frameworks/Python.framework/Versions/2.3/include/ >> python2.3 -c Src/arrayobject.c -o >> build/temp.darwin-7.6.0-Power_Macintosh-2.3/Src/arrayobject.o >> unable to execute gcc: No such file or directory >> error: command 'gcc' failed with exit status 1 >> >> >> If anyone is aware of that problem ??!! Apart from that python seems >> to mork pretty well... >> >> Thanks in advance. >> >> B.A. >> >> >> >> > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 2043 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20041208/9b6afc26/attachment.bin From MILLIKEL at neumann.edu Thu Dec 9 15:30:24 2004 From: MILLIKEL at neumann.edu (Lawrence Milliken) Date: Thu Dec 9 15:30:37 2004 Subject: [Pythonmac-SIG] need help connecting to mysql with mysql-python Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- BEGIN:VCARD VERSION:2.1 X-GWTYPE:USER FN:Lawrence Milliken TEL;WORK:610-558-5541 ORG:Neumann College;Library EMAIL;WORK;PREF;NGW:MILLIKEL@neumann.edu N:Milliken;Lawrence TITLE:Reference Librarian ADR;DOM;WORK;PARCEL;POSTAL:;;One Neumann Dr.;Aston;PA;19014 LABEL;DOM;WORK;PARCEL;POSTAL;ENCODING=QUOTED-PRINTABLE:Lawrence Milliken=0A= One Neumann Dr.=0A= Aston, PA 19014 X-GWUSERID:MILLIKEL END:VCARD From MILLIKEL at neumann.edu Thu Dec 9 17:05:23 2004 From: MILLIKEL at neumann.edu (Lawrence Milliken) Date: Thu Dec 9 17:05:42 2004 Subject: [Pythonmac-SIG] need help connecting to mysql withmysql-python Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- BEGIN:VCARD VERSION:2.1 X-GWTYPE:USER FN:Lawrence Milliken TEL;WORK:610-558-5541 ORG:Neumann College;Library EMAIL;WORK;PREF;NGW:MILLIKEL@neumann.edu N:Milliken;Lawrence TITLE:Reference Librarian ADR;DOM;WORK;PARCEL;POSTAL:;;One Neumann Dr.;Aston;PA;19014 LABEL;DOM;WORK;PARCEL;POSTAL;ENCODING=QUOTED-PRINTABLE:Lawrence Milliken=0A= One Neumann Dr.=0A= Aston, PA 19014 X-GWUSERID:MILLIKEL END:VCARD From bob at redivi.com Fri Dec 10 02:17:21 2004 From: bob at redivi.com (Bob Ippolito) Date: Fri Dec 10 02:18:00 2004 Subject: [Pythonmac-SIG] Proposed Mac OS X change for 2.3.5 and 2.4.1 - MACOSX_DEPLOYMENT_TARGET vs. Python, round two, fight! Message-ID: <3DBFC242-4A49-11D9-8CCD-000A9567635C@redivi.com> I've included a lot of background information here, if you just want to know the details of the proposed change, skip to the bottom. As some of you may know, Python 2.4's configure script and distutils has some tricky behavior with regard to the ``MACOSX_DEPLOYMENT_TARGET`` environment variable on Mac OS X 10.3 and later. Unless otherwise specified, assume that I am talking about a build environment of Mac OS X 10.3 or later. This behavior is as follows: If ``MACOSX_DEPLOYMENT_TARGET`` is not set during configure: 1. distutils builds modules with ``-F/Python/Installation/Location -framework Python`` as per usual 2.3.x behavior if it is also not set 2. If ``MACOSX_DEPLOYMENT_TARGET`` is set during a later run of distutils, then distutils complains that "10.3" mismatches the configure time setting of "" This Python framework has the following misfeatures: 1. All your extensions are dependent on the installation location of this particular Python 2. This installation of Python 2.4 *may break the building of extensions* for any previous version of Python that uses the same distutils behavior. It will certainly break them if they are installed to the same framework directory, but if the version of Python 2.3 is early enough, such as the stock 2.3.0, it will break that too. Also, any future version of Python installed to the same frameworks directory *will break the building of extensions* for this Python installation! 3. The Python framework will not be compatible with versions of Mac OS X earlier than 10.3 anyway due to changes in libSystem! This is stupid, and it should NOT be default behavior! If ``MACOSX_DEPLOYMENT_TARGET`` is set to "10.3" or higher during configure: 1. distutils builds modules with ``-undefined dynamic_lookup`` 2. If ``MACOSX_DEPLOYMENT_TARGET`` is set to something other than "10.3", or unset, it will complain that the current setting mismatches the configure setting of "10.3" The features: 1. All your extensions are independent of the Python installation location, and are thus compatible with any other Python with the same major version. 2. This installation of Python 2.4 will still, unavoidably, break the building of extensions for any previous version of Python using the bad distutils behavior mentioned above. This installation is not susceptible to breakage, however. The misfeatures: 1. You need to have ``MACOSX_DEPLOYMENT_TARGET`` set during configure, most people don't know to do this. 2. You also need to have ``MACOSX_DEPLOYMENT_TARGET`` set when using distutils. Even less people know to do this. The solution to this is to have the following behavior instead: 1. If no ``MACOSX_DEPLOYMENT_TARGET`` is set during configure, and the build machine is Mac OS X 10.3 or later, then set it to "10.3". 2. If no ``MACOSX_DEPLOYMENT_TARGET`` is set during distutils, but it WAS set during configure, then set it to the configure time value. 3. Otherwise, if it is set to a LOWER value, then fail. Checking for an exact match is bad, because the user or extension author should be free to build a particular extension using 10.4 specific features against a Python that is 10.3+ compatible. For a build machine running Mac OS X 10.2 or earlier, it should ignore all of this behavior as per usual. Unless anyone has a reasonable objection to this proposed solution, then we should make sure it goes into Python 2.4.1 and Python 2.3.5. These threads might also be of interest: http://mail.python.org/pipermail/pythonmac-sig/2004-November/012192.html http://mail.python.org/pipermail/pythonmac-sig/2004-December/012237.html http://mail.python.org/pipermail/pythonmac-sig/2004-December/012275.html -bob From pythonmac at gisborne.emailuser.net Fri Dec 10 08:17:40 2004 From: pythonmac at gisborne.emailuser.net (pythonmac@gisborne.emailuser.net) Date: Fri Dec 10 08:18:21 2004 Subject: [Pythonmac-SIG] Re: How-To upgrade Apples python installation in Mac OS X 10.3 from python 2.3 to 2.4 Message-ID: <940ACCBA-4A7B-11D9-8C37-000393C9524C@gisborne.emailuser.net> From: gisborne@emailuser.net Subject: Re: Pythonmac-SIG Digest, Vol 20, Issue 11 Date: December 10, 2004 1:08:54 CST To: pythonmac-sig@python.org Ran into some troubles with the below. Comments interspersed. > From: Robert Valsj? > Date: December 8, 2004 3:06:50 CST > To: PythonMac-sig@python.org > Cc: Subject: [Pythonmac-SIG] How-To upgrade Apples python installation > in Mac OS X 10.3 from python 2.3 to 2.4 > > > How to upgrade Apples python installation in Mac OS X 10.3 from python > 2.3 to 2.4 > >make > >make frameworkinstall make frameworkinstall pbxcp: error: open(): ///Applications/MacPython-2.4/PythonLauncher.app/Contents/Info.plist: Permission denied ...failed PBXCp ///Applications/MacPython-2.4/PythonLauncher.app/Contents/Info.plist ... ** BUILD FAILED ** make[1]: *** [install_PythonLauncher] Error 1 make: *** [frameworkinstallapps] Error 2 Fine: I did sudo make frameworkinstall, which executes without error. > >make frameworkinstallextras Same privileges complaint; same solution. > > Change you PATH: > > >emacs ~/.bashrc > > Add: > > PATH=/usr/local/bin:$PATH > export PATH OK. Then I do: python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> > This seems to work for me. Please let me know if something is missing. Many thanks, but something is missing. Guyren G Howe From bob at redivi.com Fri Dec 10 08:29:53 2004 From: bob at redivi.com (Bob Ippolito) Date: Fri Dec 10 08:30:30 2004 Subject: [Pythonmac-SIG] Re: How-To upgrade Apples python installation in Mac OS X 10.3 from python 2.3 to 2.4 In-Reply-To: <940ACCBA-4A7B-11D9-8C37-000393C9524C@gisborne.emailuser.net> References: <940ACCBA-4A7B-11D9-8C37-000393C9524C@gisborne.emailuser.net> Message-ID: <48AAB07A-4A7D-11D9-8912-000A9567635C@redivi.com> On Dec 10, 2004, at 2:17 AM, pythonmac@gisborne.emailuser.net wrote: > From: gisborne@emailuser.net > Subject: Re: Pythonmac-SIG Digest, Vol 20, Issue 11 > Date: December 10, 2004 1:08:54 CST > To: pythonmac-sig@python.org > > Ran into some troubles with the below. Comments interspersed. > >> From: Robert Valsj? >> Date: December 8, 2004 3:06:50 CST >> To: PythonMac-sig@python.org >> Cc: Subject: [Pythonmac-SIG] How-To upgrade Apples python >> installation in Mac OS X 10.3 from python 2.3 to 2.4 >> >> >> How to upgrade Apples python installation in Mac OS X 10.3 from >> python 2.3 to 2.4 > > > >> >make >> >make frameworkinstall > > make frameworkinstall > pbxcp: error: open(): > ///Applications/MacPython-2.4/PythonLauncher.app/Contents/Info.plist: > Permission denied > ...failed PBXCp > ///Applications/MacPython-2.4/PythonLauncher.app/Contents/Info.plist > ... > ** BUILD FAILED ** > make[1]: *** [install_PythonLauncher] Error 1 > make: *** [frameworkinstallapps] Error 2 > > Fine: I did sudo make frameworkinstall, which executes without error. > >> >make frameworkinstallextras > > Same privileges complaint; same solution. Everything in the /Applications folder should be writable by anyone in the admin group, so your configuration is to blame here, not the instructions. Some package you installed probably had bad permissions... This should work for most systems. If you open up Disk Utility, there is a button that will repair permissions on a volume. With correct permissions, these steps should've succeeded. Given this error, you should probably do it. >> Change you PATH: >> >> >emacs ~/.bashrc >> >> Add: >> >> PATH=/usr/local/bin:$PATH >> export PATH > > OK. Then I do: > > python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> You also need to set the PATH from the shell prompt, or start a new terminal window. Editing .bashrc doesn't do anything to a currently running bash process. -bob From pythonmac at gisborne.emailuser.net Fri Dec 10 17:59:09 2004 From: pythonmac at gisborne.emailuser.net (pythonmac@gisborne.emailuser.net) Date: Fri Dec 10 17:59:18 2004 Subject: [Pythonmac-SIG] How-To upgrade Apples python installation in Mac OS X 10.3 from python 2.3 to 2.4 Message-ID: > From: Bob Ippolito > Date: December 10, 2004 1:29:53 CST > To: pythonmac@gisborne.emailuser.net > Cc: pythonmac-sig@python.org > Subject: Re: [Pythonmac-SIG] Re: How-To upgrade Apples python > installation in Mac OS X 10.3 from python 2.3 to 2.4 >>> >make >>> >make frameworkinstall >> >> make frameworkinstall >> pbxcp: error: open(): >> ///Applications/MacPython-2.4/PythonLauncher.app/Contents/Info.plist: >> Permission denied >> ...failed PBXCp >> ///Applications/MacPython-2.4/PythonLauncher.app/Contents/Info.plist >> ... >> ** BUILD FAILED ** >> make[1]: *** [install_PythonLauncher] Error 1 >> make: *** [frameworkinstallapps] Error 2 >> >> Fine: I did sudo make frameworkinstall, which executes without error. >> >>> >make frameworkinstallextras >> >> Same privileges complaint; same solution. > > Everything in the /Applications folder should be writable by anyone in > the admin group, so your configuration is to blame here, not the > instructions. Some package you installed probably had bad > permissions... This should work for most systems. > > If you open up Disk Utility, there is a button that will repair > permissions on a volume. With correct permissions, these steps > should've succeeded. Given this error, you should probably do it. I know this is somewhat off-topic, but I ran repair permissions using Disk Utility, and then manually went in and did chmod on both Contents and Info.plist so that both owner (root) and group (wheel) could rwx and rw the folder and file, respectively. I still get the permission error shown above. Weird, huh? > >>> Change you PATH: >>> >>> >emacs ~/.bashrc >>> >>> Add: >>> >>> PATH=/usr/local/bin:$PATH >>> export PATH >> >> OK. Then I do: >> >> python >> Python 2.3 (#1, Sep 13 2003, 00:49:11) >> [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin >> Type "help", "copyright", "credits" or "license" for more information. >> >>> > > You also need to set the PATH from the shell prompt, or start a new > terminal window. Editing .bashrc doesn't do anything to a currently > running bash process. Works now, but only after having run the two latter makes as root. I hope that won't cause problems. Thanks for your help. Guyren G Howe From bob at redivi.com Fri Dec 10 18:10:08 2004 From: bob at redivi.com (Bob Ippolito) Date: Fri Dec 10 18:10:15 2004 Subject: [Pythonmac-SIG] How-To upgrade Apples python installation in Mac OS X 10.3 from python 2.3 to 2.4 In-Reply-To: References: Message-ID: <5830E482-4ACE-11D9-B056-000A95BA5446@redivi.com> On Dec 10, 2004, at 11:59, pythonmac@gisborne.emailuser.net wrote: >> From: Bob Ippolito >> Date: December 10, 2004 1:29:53 CST >> To: pythonmac@gisborne.emailuser.net >> Cc: pythonmac-sig@python.org >> Subject: Re: [Pythonmac-SIG] Re: How-To upgrade Apples python >> installation in Mac OS X 10.3 from python 2.3 to 2.4 >>>> >make >>>> >make frameworkinstall >>> >>> make frameworkinstall >>> pbxcp: error: open(): >>> ///Applications/MacPython-2.4/PythonLauncher.app/Contents/ >>> Info.plist: Permission denied >>> ...failed PBXCp >>> ///Applications/MacPython-2.4/PythonLauncher.app/Contents/Info.plist >>> ... >>> ** BUILD FAILED ** >>> make[1]: *** [install_PythonLauncher] Error 1 >>> make: *** [frameworkinstallapps] Error 2 >>> >>> Fine: I did sudo make frameworkinstall, which executes without error. >>> >>>> >make frameworkinstallextras >>> >>> Same privileges complaint; same solution. >> >> Everything in the /Applications folder should be writable by anyone >> in the admin group, so your configuration is to blame here, not the >> instructions. Some package you installed probably had bad >> permissions... This should work for most systems. >> >> If you open up Disk Utility, there is a button that will repair >> permissions on a volume. With correct permissions, these steps >> should've succeeded. Given this error, you should probably do it. > > I know this is somewhat off-topic, but I ran repair permissions using > Disk Utility, and then manually went in and did chmod on both Contents > and Info.plist so that both owner (root) and group (wheel) could rwx > and rw the folder and file, respectively. > > I still get the permission error shown above. Weird, huh? Not really, Disk Utility is only responsible for repairing permissions that it knows about, namely, stuff it finds in package receipts. Since you installed this via make, and not Apple's Installer, it comes as no surprise that these files still have root permissions after a repair. -bob From jacob at jacobian.org Sat Dec 11 00:23:03 2004 From: jacob at jacobian.org (Jacob Kaplan-Moss) Date: Sat Dec 11 00:23:11 2004 Subject: [Pythonmac-SIG] PyCon 2005 Message-ID: <7078483A-4B02-11D9-98A3-000D933647EE@jacobian.org> Hey all -- I'm thinking of proposing a talk at PyCon 2005 about MacPython, and I'd like to run my idea by the list: As I see it, there are three killer features in MacPython that you can't get anywhere else: PyObjC, CoreGraphics, and scripting with appscript. Given that 30 or 45 minutes won't be nearly enough to talk about all three, I'm thinking of focusing on the general topic of "scripting OS X" using appscript and CoreGraphics (AFAIK there's been a number of "Intro to PyObjC" talks given in the past, and I don't really want to reinvent the wheel). If there's anyone else proposing a talk at PyCon, I'd like to avoid stepping on any toes (as far as I'm concerned, the more MacPython talks the better), so if this overlaps/competes with your cool idea, please let me know. Jacob From bob at redivi.com Sat Dec 11 00:50:47 2004 From: bob at redivi.com (Bob Ippolito) Date: Sat Dec 11 00:51:23 2004 Subject: [Pythonmac-SIG] PyCon 2005 In-Reply-To: <7078483A-4B02-11D9-98A3-000D933647EE@jacobian.org> References: <7078483A-4B02-11D9-98A3-000D933647EE@jacobian.org> Message-ID: <504FBAD1-4B06-11D9-80F2-000A9567635C@redivi.com> On Dec 10, 2004, at 6:23 PM, Jacob Kaplan-Moss wrote: > I'm thinking of proposing a talk at PyCon 2005 about MacPython, and > I'd like to run my idea by the list: > > As I see it, there are three killer features in MacPython that you > can't get anywhere else: PyObjC, CoreGraphics, and scripting with > appscript. Given that 30 or 45 minutes won't be nearly enough to talk > about all three, I'm thinking of focusing on the general topic of > "scripting OS X" using appscript and CoreGraphics (AFAIK there's been > a number of "Intro to PyObjC" talks given in the past, and I don't > really want to reinvent the wheel). > > If there's anyone else proposing a talk at PyCon, I'd like to avoid > stepping on any toes (as far as I'm concerned, the more MacPython > talks the better), so if this overlaps/competes with your cool idea, > please let me know. I did the "60 Minutes of MacPython" talk at PyCon 2004. I was initially thinking about doing another one this year, but I'm leaning towards doing a talk on just PyObjC. So, it would be awesome if you did a talk on CoreGraphics and appscript. That would leave me to talk about what I know best and am most interested in :) My slides, proposal, slide-creation-scripts, and notes taken during my presentation by the audience last year are available here: http://svn.red-bean.com/bob/pycon/2004/trunk/ I will likely break my PyObjC talk it into two separate 30 minute sessions: "intro to PyObjC" and "hacking with PyObjC". The first of which would be more like a tutorial and go over the obvious rapid development facilities that you have available such as Cocoa Bindings, using WebKit, table views, writing py2app scripts, using the Xcode template, using Renaissance instead of Interface Builder, what people are doing with PyObjC, etc. The second would go into writing plugins for existing applications, hacking existing classes with categories, injecting Python into arbitrary pids using pyject (a wrapper bbum and I wrote around mach_inject), wrapping near-arbitrary not-ObjC functions with loadBundleFunctions (a la ctypes), and possibly talk a little about the gritty implementation details of PyObjC if there's time/interest. If you have any questions or would like to collaborate a bit on our proposals/slides/scripts then feel free to contact me on or off list. -bob From keithn at 2xtreme.net Sat Dec 11 07:24:33 2004 From: keithn at 2xtreme.net (Keith Nemitz) Date: Sat Dec 11 07:24:36 2004 Subject: [Pythonmac-SIG] [ANN] SIGnificant Mac Game Ships, Written in Python Message-ID: <52654746-4B3D-11D9-A750-000393DB52E4@2xtreme.net> Hello everyone. I'd like to thank this SIG, and especially Jack and Bob for their consistent and excellent help that made my product a reality. This project represents not only my first product written in Python, it represents my new life as an aspiring independent game developer. I look forward to contributing source code from the game to this community, as a way of saying thanks. If you'd like to know more about the game, I append below, the latest draft of my press release. The full Macintosh downloadable is available today. (What the P.R. doesn't mention is, it's a game designed for the women segment of the casual game market. The male coders on this list may find that their wives, girlfriends, mothers and even grandmothers enjoy the game much more. Let them give it a try.) The release: Mousechief Tickles the Web with The Witch's Yarn Emeryville, CA, Dec 13, 2004 -- Mousechief (www.mousechief.com) proudly releases, The Witch's Yarn, the first adventure game developed specifically for the downloadable market. Tired of clones and renovations? Finally, there's something new to play instead of puzzlers and simple action games. Isn't it time to wrap yourself up in a rich, delightful story? The Witch?s Yarn tells an upbeat tale of modern living served with a lighthearted dish of fantasy. Although suitable for audiences of all ages, adults will fully appreciate its humor and content. It is a story about relationships, community, self-empowerment, and simple living. Challenges in the game arise from the very same issues but present themselves by adding to, not interrupting, the story. Built with the CineProse(tm) adventure engine, YOU decide what happens, how the plot thickens, and most importantly, how it ends. Combining the best of movies, live theater, and the written word, the CineProse experience is a wonderful new, interactive entertainment! Anyone who likes to sink into a pile of couch cushions for "a good read" will enjoy this humor-filled tale about making a new life in unfamiliar territory. Play for one minute or one hour. The Witch's Yarn was designed to be as easy to pick up and enjoy as reading a book. Versions for Macintosh and Windows are available immediately for free download. After previewing the first two chapters, unlock the full game for $19.95 (USD). One published review had this to say, "...provides very innovative game play that will likely get this game noticed. ...I think it is something that everyone can appreciate." The Witch's Yarn can be securely downloaded at http://www.witchsyarn.com/ Registered users are entitled to unlimited play, free updates and technical support. About Mousechief Co. Founded in 2003, Mousechief is lead by a 12 year veteran of the computer gaming industry. We believe that current adventure games do not address the constraints of the casual game market. In our user testing, the majority of a sample population was unable to perform basic control over the main character. That's why we re-invented the genre specifically for this market. Thus, the CineProse style of adventure game was born. Subsequent testing of computer novices showed that 100% of ages 8 to 78 were able to pick up and play The Witch's Yarn. Working with art talents from famous jazz musicians to highly skilled illustrators, Mousechief crafts unique, fun-filled experiences for the casual game market. Our games will delight your senses as much as they will expand your heart. We make play worthwhile. # # # For more information about The Witch's Yarn: Contact: Keith Nemitz Company: Mousechief Co. E-mail: chief@mousechief.com Company site: http://www.Mousechief.com/ Company logo: http://www.Mousechief.com/mousechief_logo2.png Game site: http://www.TheWitchsYarn.com/ Game logo: http://www.Mousechief.com/wheel.png Screenshots: http://www.TheWitchsYarn.com/ss1.html http://www.TheWitchsYarn.com/ss2.html http://www.TheWitchsYarn.com/ss3.html http://www.TheWitchsYarn.com/ss4.html Mac download: http://p4.hostingprod.com/@mousechief.com/TheWitchsYarn.dmg PC download: http://p4.hostingprod.com/@mousechief.com/TheWitchsYarn.zip From rroberts at adobe.com Mon Dec 13 20:36:33 2004 From: rroberts at adobe.com (Read Roberts) Date: Mon Dec 13 20:36:48 2004 Subject: [Pythonmac-SIG] Problem with tkaqua Tkinter and some Kanji unicode values. In-Reply-To: References: Message-ID: Thank you for your response! I followed your advice to ask on the " tcl-mac" list, and was told that the problem is known, and a patch exists: The patch has not yet been integrated into the TkAcqua main branch because it slows text processing down a lot. Someone is working on this, and it may be folded into the main branch soon. For description of the patch see "[ 638966 ] Font rendering on MacOSX with ATSU": http://sourceforge.net/tracker/index.php?func=detail&aid=638966&group_id=12997&atid=312997 >On 17-nov-04, at 23:13, Read Roberts wrote: > >>Thanks for confirming that it is not just my system! >> >> I'm pretty sure that it the problem is in Tk rather than >>Python/Tkinter , as I can do Entry_widget.cget('txt') and get the >>right string back, and can even cut and paste from the Entry widget >>to other apps and still get the original Unicode back ( well, >>UTF-8, but it is still correct). >> >>Looks like I will have to go spelunking in TK to find the cause - >>anyone have suggestions about where to start? > >First ask on the mailing list for Mac Tcl/Tk developers, >. It may be a known problem. And >they're friendly to Python/Tkinter users over there, too:-) >-- >Jack Jansen, , http://www.cwi.nl/~jack >If I can't dance I don't want to be part of your revolution -- Emma Goldman From abecassi at drecam.saclay.cea.fr Wed Dec 15 14:31:54 2004 From: abecassi at drecam.saclay.cea.fr (=?ISO-8859-1?Q?Benjamin_Ab=E9cassis?=) Date: Wed Dec 15 14:30:52 2004 Subject: [Pythonmac-SIG] Won't Install Numarray-1.1.1 or Numeric_23.6 + Scipy In-Reply-To: References: <1F9E33FF-4871-11D9-B594-000D93554544@drecam.saclay.cea.fr> Message-ID: thanks to David and Bob for your answers, i've installed gcc and now everything is working well. Though i still have a problem when trying to install Sci-py the installer tells : x11_info: NOT AVAILABLE Fatal Python error: Interpreter not initialized (version mismatch?) Abort trap any idea ?? Thanks again for your very fast answer, i'm new to MacOS10 and not an expert in computing in general ;-) Le 8 d?c. 04, ? 15:15, David Reed a ?crit : > > On Dec 7, 2004, at 11:57 AM, Benjamin Ab?cassis wrote: > >> >> Hi everyone, >> I can't install Numarray-1.1.1 or Numeric_23.6 >> After typing, python setup.py install >> it tells, >> >> error: command 'gcc' failed with exit status 1 >> >> Here is the complete log : >> >> running install >> running build >> running build_py >> running build_ext >> building '_numpy' extension >> gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp >> -mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3 -Wall >> -Wstrict-prototypes >> -I/System/Library/Frameworks/vecLib.framework/Headers -IInclude >> -IPackages/FFT/Include -IPackages/RNG/Include >> -I/System/Library/Frameworks/Python.framework/Versions/2.3/include/ >> python2.3 -c Src/arrayobject.c -o >> build/temp.darwin-7.6.0-Power_Macintosh-2.3/Src/arrayobject.o >> unable to execute gcc: No such file or directory >> error: command 'gcc' failed with exit status 1 >> >> >> If anyone is aware of that problem ??!! Apart from that python seems >> to mork pretty well... >> >> Thanks in advance. > > I'm fairly new to OSX, but it looks to me like you don't have gcc > installed. > > At your terminal window try: "which gcc" (w/o the quotes). It should > return: /usr/bin/gcc > > If not, you need to install Apple's XCode which contains gcc and other > development tools. XCode may be on the CD or in an directory on your > harddrive, but I would recommend downloading the latest version from > apple.com since it has some bug fixes you'll want. > > Dave > > ------------------------------------------------------------------------ ----------------------------------------- Benjamin Ab?cassis Laboratoire Interdisciplinaire sur l'Organisation Nanom?trique et Supramol?culaire CEA/SACLAY, Service de Chimie Mol?culaire, 91191 Gif sur Yvette Cedex, France tel : 33 (0)-1 69 08 67 65 fax : 33 (0)-1 69 08 66 40 ------------------------------------------------------------------------ ---------------------------------------------- From riko at anubics.org Wed Dec 15 18:01:25 2004 From: riko at anubics.org (Enrico Franchi) Date: Wed Dec 15 18:01:37 2004 Subject: [Pythonmac-SIG] Won't Install Numarray-1.1.1 or Numeric_23.6 + Scipy In-Reply-To: <1A7586CE-4EA2-11D9-B812-000D93554544@drecam.saclay.cea.fr> References: <1F9E33FF-4871-11D9-B594-000D93554544@drecam.saclay.cea.fr> <46952A52-4EA0-11D9-806B-000A957FDD16@anubics.org> <1A7586CE-4EA2-11D9-B812-000D93554544@drecam.saclay.cea.fr> Message-ID: On 15/dic/04, at 15:03, Benjamin Ab?cassis wrote: > yes i've installed both, it now says (after reboot) : > > x11_info: > FOUND: > libraries = ['X11'] > library_dirs = ['/usr/X11R6/lib'] > include_dirs = ['/usr/X11R6/include'] Good. > Fatal Python error: Interpreter not initialized (version mismatch?) I suppose you have installed two different python versions. For example I had this problem when I tried to install QT having both 2.4 and 2.3 installed. I had some misconfigurations, and while installing for 2.4 was straightforward, 2.3 gave me problems. This should be easily fixable. Anyway, which versions did you install (or am I totally wrong)? >> On 15/dic/04, at 14:31, Benjamin Ab?cassis wrote: >> >>> x11_info: >>> NOT AVAILABLE >> >> Have you installed X11? >> And what about X11 SDK (I don't remember the exact name) >> >> The first one should be in some of your installation disks. The >> second one is available on Apple Developer Connection for free (IIRC) >> for free. >> >> -enrico >> >> > ----------------------------------------------------------------------- > ------------------------------------------ > Benjamin Ab?cassis > Laboratoire Interdisciplinaire sur l'Organisation Nanom?trique et > Supramol?culaire > CEA/SACLAY, Service de Chimie Mol?culaire, > 91191 Gif sur Yvette Cedex, France > tel : 33 (0)-1 69 08 67 65 > fax : 33 (0)-1 69 08 66 40 > ----------------------------------------------------------------------- > ----------------------------------------------- > > > -enrico From bob at redivi.com Wed Dec 15 18:31:04 2004 From: bob at redivi.com (Bob Ippolito) Date: Wed Dec 15 18:31:20 2004 Subject: [Pythonmac-SIG] Won't Install Numarray-1.1.1 or Numeric_23.6 + Scipy In-Reply-To: References: <1F9E33FF-4871-11D9-B594-000D93554544@drecam.saclay.cea.fr> <46952A52-4EA0-11D9-806B-000A957FDD16@anubics.org> <1A7586CE-4EA2-11D9-B812-000D93554544@drecam.saclay.cea.fr> Message-ID: <1895EF4C-4EBF-11D9-BA86-000A95BA5446@redivi.com> On Dec 15, 2004, at 12:01, Enrico Franchi wrote: > > On 15/dic/04, at 15:03, Benjamin Ab?cassis wrote: > >> yes i've installed both, it now says (after reboot) : >> >> x11_info: >> FOUND: >> libraries = ['X11'] >> library_dirs = ['/usr/X11R6/lib'] >> include_dirs = ['/usr/X11R6/include'] > > Good. > >> Fatal Python error: Interpreter not initialized (version mismatch?) > > I suppose you have installed two different python versions. > For example I had this problem when I tried to install QT having both > 2.4 and 2.3 installed. I had some misconfigurations, and while > installing for 2.4 was straightforward, 2.3 gave me problems. > > This should be easily fixable. Anyway, which versions did you install > (or am I totally wrong)? If you have a framework Python 2.4 installed, then you have broken extension building for any unpatched Python 2.3 installation. Please search the archives for more posts by me on this issue. -bob From abecassi at drecam.saclay.cea.fr Wed Dec 15 18:48:01 2004 From: abecassi at drecam.saclay.cea.fr (=?ISO-8859-1?Q?Benjamin_Ab=E9cassis?=) Date: Wed Dec 15 18:46:57 2004 Subject: [Pythonmac-SIG] Won't Install Numarray-1.1.1 or Numeric_23.6 + Scipy In-Reply-To: <1895EF4C-4EBF-11D9-BA86-000A95BA5446@redivi.com> References: <1F9E33FF-4871-11D9-B594-000D93554544@drecam.saclay.cea.fr> <46952A52-4EA0-11D9-806B-000A957FDD16@anubics.org> <1A7586CE-4EA2-11D9-B812-000D93554544@drecam.saclay.cea.fr> <1895EF4C-4EBF-11D9-BA86-000A95BA5446@redivi.com> Message-ID: <76ABB3A8-4EC1-11D9-B812-000D93554544@drecam.saclay.cea.fr> it works OK now, i just de-installed the first version, python works fine now (well just like before i installed Xcode, gcc etc... !!!) but i still have problems with scipy...it seems like the installer can not find a particular library, i've installed FFTW, F2PY though here is the log : fftw_info: FOUND: libraries = ['rfftw', 'fftw'] library_dirs = ['/usr/local/lib'] define_macros = [('SCIPY_FFTW_H', None)] include_dirs = ['/usr/local/include'] djbfft_info: NOT AVAILABLE DJBFFT (http://cr.yp.to/djbfft.html) libraries not found. Directories to search for the libraries can be specified in the scipy_distutils/site.cfg file (section [djbfft]) or by setting the DJBFFT environment variable. blas_opt_info: FOUND: extra_link_args = ['-Wl,-framework', '-Wl,Accelerate'] define_macros = [('NO_ATLAS_INFO', 3)] extra_compile_args = ['-faltivec', '-framework', 'Accelerate'] lapack_opt_info: FOUND: extra_link_args = ['-Wl,-framework', '-Wl,Accelerate'] define_macros = [('NO_ATLAS_INFO', 3)] extra_compile_args = ['-faltivec', '-framework', 'Accelerate'] numpy_info: FOUND: define_macros = [('NUMERIC_VERSION', '"\\"23.6\\""')] include_dirs = ['/System/Library/Frameworks/Python.framework/Versions/2.3/include/ python2.3'] x11_info: FOUND: libraries = ['X11'] library_dirs = ['/usr/X11R6/lib'] include_dirs = ['/usr/X11R6/include'] SciPy Version 0.3.2 **************************************************************** Using fortran_libraries setup option is depreciated --------------------------------------------------- Use libraries option instead. Yes, scipy_distutils now supports Fortran sources in libraries. **************************************************************** running install running build running config_fc running build_src building extension "scipy.cluster._vq" sources building extension "scipy.fftpack._fftpack" sources adding 'build/src/fortranobject.c' to sources. adding 'build/src' to include_dirs. building extension "scipy.fftpack.convolve" sources adding 'build/src/fortranobject.c' to sources. building extension "scipy.integrate._quadpack" sources building extension "scipy.integrate._odepack" sources building extension "scipy.integrate.vode" sources adding 'build/src/fortranobject.c' to sources. adding 'build/src' to include_dirs. building extension "scipy.interpolate._fitpack" sources building extension "scipy.interpolate.dfitpack" sources adding 'build/src/fortranobject.c' to sources. adding 'build/src' to include_dirs. adding 'build/src/Lib/interpolate/dfitpack-f2pywrappers.f' to sources. building extension "scipy.io.numpyio" sources building extension "scipy.linalg.fblas" sources adding 'build/src/scipy/linalg/fblas.pyf' to sources. adding 'build/src/fortranobject.c' to sources. adding 'build/src' to include_dirs. adding 'build/src/build/src/scipy/linalg/fblas-f2pywrappers.f' to sources. building extension "scipy.linalg.cblas" sources adding 'build/src/scipy/linalg/cblas.pyf' to sources. adding 'build/src/fortranobject.c' to sources. adding 'build/src' to include_dirs. building extension "scipy.linalg.flapack" sources adding 'build/src/scipy/linalg/flapack.pyf' to sources. adding 'build/src/fortranobject.c' to sources. adding 'build/src' to include_dirs. building extension "scipy.linalg.clapack" sources adding 'build/src/scipy/linalg/clapack.pyf' to sources. adding 'build/src/fortranobject.c' to sources. adding 'build/src' to include_dirs. building extension "scipy.linalg._flinalg" sources adding 'build/src/fortranobject.c' to sources. adding 'build/src' to include_dirs. building extension "scipy.linalg.calc_lwork" sources adding 'build/src/fortranobject.c' to sources. adding 'build/src' to include_dirs. building extension "scipy.linalg.atlas_version" sources building extension "scipy.linalg._iterative" sources adding 'build/src/fortranobject.c' to sources. adding 'build/src' to include_dirs. building extension "scipy.optimize._minpack" sources building extension "scipy.optimize._zeros" sources building extension "scipy.optimize._lbfgsb" sources adding 'build/src/fortranobject.c' to sources. adding 'build/src' to include_dirs. building extension "scipy.optimize.moduleTNC" sources building extension "scipy.optimize._cobyla" sources adding 'build/src/fortranobject.c' to sources. adding 'build/src' to include_dirs. building extension "scipy.optimize.minpack2" sources adding 'build/src/fortranobject.c' to sources. adding 'build/src' to include_dirs. building extension "scipy.signal.sigtools" sources building extension "scipy.signal.spline" sources building extension "scipy.sparse._zsuperlu" sources building extension "scipy.sparse._dsuperlu" sources building extension "scipy.sparse._csuperlu" sources building extension "scipy.sparse._ssuperlu" sources building extension "scipy.sparse.sparsetools" sources adding 'build/src/fortranobject.c' to sources. adding 'build/src' to include_dirs. building extension "scipy.special.cephes" sources building extension "scipy.special.specfun" sources adding 'build/src/fortranobject.c' to sources. adding 'build/src' to include_dirs. building extension "scipy.stats.rand" sources building extension "scipy.stats.statlib" sources adding 'build/src/fortranobject.c' to sources. adding 'build/src' to include_dirs. building extension "scipy.stats.futil" sources adding 'build/src/fortranobject.c' to sources. adding 'build/src' to include_dirs. building extension "scipy.xxx.spam" sources adding 'build/temp.darwin-7.6.0-Power_Macintosh-2.3/Lib/xxx/spam.pyf' to sources. adding 'build/src/fortranobject.c' to sources. adding 'build/src' to include_dirs. building extension "scipy_base.fastumath" sources adding 'scipy_core/scipy_base/fastumathmodule.c' to sources. building extension "scipy_base._compiled_base" sources building extension "scipy_base.display_test" sources building extension "scipy.config" sources adding 'build/src/scipy/scipy/config.py' to sources. building library "rootfind" sources building library "c_misc" sources building library "cephes" sources building library "dfftpack" sources building library "fitpack" sources building library "mach" sources building library "amos" sources building library "toms" sources building library "cdf" sources building library "specfun" sources building library "statlib" sources building library "quadpack_src" sources building library "linpack_lite_src" sources building library "mach_src" sources building library "odepack_src" sources building library "minpack" sources building library "superlu_src" sources running build_py copying build/src/scipy/scipy/config.py -> build/lib.darwin-7.6.0-Power_Macintosh-2.3/scipy package init file 'Lib/tests/__init__.py' not found (or not a regular file) package init file '/Users/benjaminabecassis/.Trash/SciPy_complete-0.3.2/Lib/cluster/ tests/__init__.py' not found (or not a regular file) package init file '/Users/benjaminabecassis/.Trash/SciPy_complete-0.3.2/Lib/fftpack/ tests/__init__.py' not found (or not a regular file) package init file '/Users/benjaminabecassis/.Trash/SciPy_complete-0.3.2/Lib/fftpack/ tests/__init__.py' not found (or not a regular file) package init file '/Users/benjaminabecassis/.Trash/SciPy_complete-0.3.2/Lib/gui_thread/ tests/__init__.py' not found (or not a regular file) package init file '/Users/benjaminabecassis/.Trash/SciPy_complete-0.3.2/Lib/interpolate/ tests/__init__.py' not found (or not a regular file) package init file '/Users/benjaminabecassis/.Trash/SciPy_complete-0.3.2/Lib/io/tests/ __init__.py' not found (or not a regular file) package init file '/Users/benjaminabecassis/.Trash/SciPy_complete-0.3.2/Lib/linalg/tests/ __init__.py' not found (or not a regular file) package init file '/Users/benjaminabecassis/.Trash/SciPy_complete-0.3.2/Lib/optimize/ tests/__init__.py' not found (or not a regular file) package init file '/Users/benjaminabecassis/.Trash/SciPy_complete-0.3.2/Lib/signal/tests/ __init__.py' not found (or not a regular file) package init file '/Users/benjaminabecassis/.Trash/SciPy_complete-0.3.2/Lib/sparse/tests/ __init__.py' not found (or not a regular file) package init file '/Users/benjaminabecassis/.Trash/SciPy_complete-0.3.2/Lib/special/ tests/__init__.py' not found (or not a regular file) package init file '/Users/benjaminabecassis/.Trash/SciPy_complete-0.3.2/Lib/stats/tests/ __init__.py' not found (or not a regular file) package init file '/Users/benjaminabecassis/.Trash/SciPy_complete-0.3.2/Lib/xxx/tests/ __init__.py' not found (or not a regular file) package init file '/Users/benjaminabecassis/.Trash/SciPy_complete-0.3.2/Lib/xxx/yyy/ tests/__init__.py' not found (or not a regular file) package init file '/Users/benjaminabecassis/.Trash/SciPy_complete-0.3.2/scipy_core/ scipy_base/tests/__init__.py' not found (or not a regular file) package init file 'scipy_core/weave/tests/__init__.py' not found (or not a regular file) package init file 'scipy_core/weave/tests/__init__.py' not found (or not a regular file) package init file 'Lib/tests/__init__.py' not found (or not a regular file) package init file '/Users/benjaminabecassis/.Trash/SciPy_complete-0.3.2/Lib/cluster/ tests/__init__.py' not found (or not a regular file) package init file '/Users/benjaminabecassis/.Trash/SciPy_complete-0.3.2/Lib/fftpack/ tests/__init__.py' not found (or not a regular file) package init file '/Users/benjaminabecassis/.Trash/SciPy_complete-0.3.2/Lib/fftpack/ tests/__init__.py' not found (or not a regular file) package init file '/Users/benjaminabecassis/.Trash/SciPy_complete-0.3.2/Lib/gui_thread/ tests/__init__.py' not found (or not a regular file) package init file '/Users/benjaminabecassis/.Trash/SciPy_complete-0.3.2/Lib/interpolate/ tests/__init__.py' not found (or not a regular file) package init file '/Users/benjaminabecassis/.Trash/SciPy_complete-0.3.2/Lib/io/tests/ __init__.py' not found (or not a regular file) package init file '/Users/benjaminabecassis/.Trash/SciPy_complete-0.3.2/Lib/linalg/tests/ __init__.py' not found (or not a regular file) package init file '/Users/benjaminabecassis/.Trash/SciPy_complete-0.3.2/Lib/optimize/ tests/__init__.py' not found (or not a regular file) package init file '/Users/benjaminabecassis/.Trash/SciPy_complete-0.3.2/Lib/signal/tests/ __init__.py' not found (or not a regular file) package init file '/Users/benjaminabecassis/.Trash/SciPy_complete-0.3.2/Lib/sparse/tests/ __init__.py' not found (or not a regular file) package init file '/Users/benjaminabecassis/.Trash/SciPy_complete-0.3.2/Lib/special/ tests/__init__.py' not found (or not a regular file) package init file '/Users/benjaminabecassis/.Trash/SciPy_complete-0.3.2/Lib/stats/tests/ __init__.py' not found (or not a regular file) package init file '/Users/benjaminabecassis/.Trash/SciPy_complete-0.3.2/Lib/xxx/tests/ __init__.py' not found (or not a regular file) package init file '/Users/benjaminabecassis/.Trash/SciPy_complete-0.3.2/Lib/xxx/yyy/ tests/__init__.py' not found (or not a regular file) package init file '/Users/benjaminabecassis/.Trash/SciPy_complete-0.3.2/scipy_core/ scipy_base/tests/__init__.py' not found (or not a regular file) package init file 'scipy_core/weave/tests/__init__.py' not found (or not a regular file) package init file 'scipy_core/weave/tests/__init__.py' not found (or not a regular file) running build_clib customize UnixCCompiler customize UnixCCompiler using build_clib customize NAGFCompiler customize AbsoftFCompiler customize IbmFCompiler Could not locate executable g77 Could not locate executable f77 customize GnuFCompiler customize GnuFCompiler customize NAGFCompiler customize NAGFCompiler using build_clib building 'dfftpack' library compiling Fortran sources f95(f77) options: '-fixed -O4' f95(f90) options: '-O4' f95(fix) options: '-fixed -O4' compile options: '-c' f95:f77: Lib/fftpack/dfftpack/dcosqb.f sh: line 1: f95: command not found sh: line 1: f95: command not found error: Command "f95 -fixed -O4 -c -c Lib/fftpack/dfftpack/dcosqb.f -o build/temp.darwin-7.6.0-Power_Macintosh-2.3/Lib/fftpack/dfftpack/ dcosqb.o" failed with exit status 127 thanks again fo your help... benjamin Le 15 d?c. 04, ? 18:31, Bob Ippolito a ?crit : > > On Dec 15, 2004, at 12:01, Enrico Franchi wrote: > >> >> On 15/dic/04, at 15:03, Benjamin Ab?cassis wrote: >> >>> yes i've installed both, it now says (after reboot) : >>> >>> x11_info: >>> FOUND: >>> libraries = ['X11'] >>> library_dirs = ['/usr/X11R6/lib'] >>> include_dirs = ['/usr/X11R6/include'] >> >> Good. >> >>> Fatal Python error: Interpreter not initialized (version mismatch?) >> >> I suppose you have installed two different python versions. >> For example I had this problem when I tried to install QT having both >> 2.4 and 2.3 installed. I had some misconfigurations, and while >> installing for 2.4 was straightforward, 2.3 gave me problems. >> >> This should be easily fixable. Anyway, which versions did you install >> (or am I totally wrong)? > > If you have a framework Python 2.4 installed, then you have broken > extension building for any unpatched Python 2.3 installation. Please > search the archives for more posts by me on this issue. > > -bob > > ------------------------------------------------------------------------ ----------------------------------------- Benjamin Ab?cassis Laboratoire Interdisciplinaire sur l'Organisation Nanom?trique et Supramol?culaire CEA/SACLAY, Service de Chimie Mol?culaire, 91191 Gif sur Yvette Cedex, France tel : 33 (0)-1 69 08 67 65 fax : 33 (0)-1 69 08 66 40 ------------------------------------------------------------------------ ---------------------------------------------- From rkern at ucsd.edu Wed Dec 15 19:20:44 2004 From: rkern at ucsd.edu (Robert Kern) Date: Wed Dec 15 19:20:52 2004 Subject: [Pythonmac-SIG] Won't Install Numarray-1.1.1 or Numeric_23.6 + Scipy In-Reply-To: <76ABB3A8-4EC1-11D9-B812-000D93554544@drecam.saclay.cea.fr> References: <1F9E33FF-4871-11D9-B594-000D93554544@drecam.saclay.cea.fr> <46952A52-4EA0-11D9-806B-000A957FDD16@anubics.org> <1A7586CE-4EA2-11D9-B812-000D93554544@drecam.saclay.cea.fr> <1895EF4C-4EBF-11D9-BA86-000A95BA5446@redivi.com> <76ABB3A8-4EC1-11D9-B812-000D93554544@drecam.saclay.cea.fr> Message-ID: <41C0807C.6070207@ucsd.edu> Benjamin Ab?cassis wrote: > it works OK now, i just de-installed the first version, python works > fine now (well just like before i installed Xcode, gcc etc... !!!) > > but i still have problems with scipy...it seems like the installer can > not find a particular library, i've installed FFTW, F2PY though > here is the log : [etc] Scipy also requires a FORTRAN compiler. If you have Fink, install the package g77. Otherwise, install g77 from http://hpc.sf.net . -- Robert Kern rkern@ucsd.edu "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From bob at redivi.com Wed Dec 15 19:31:50 2004 From: bob at redivi.com (Bob Ippolito) Date: Wed Dec 15 19:32:10 2004 Subject: [Pythonmac-SIG] Won't Install Numarray-1.1.1 or Numeric_23.6 + Scipy In-Reply-To: <41C0807C.6070207@ucsd.edu> References: <1F9E33FF-4871-11D9-B594-000D93554544@drecam.saclay.cea.fr> <46952A52-4EA0-11D9-806B-000A957FDD16@anubics.org> <1A7586CE-4EA2-11D9-B812-000D93554544@drecam.saclay.cea.fr> <1895EF4C-4EBF-11D9-BA86-000A95BA5446@redivi.com> <76ABB3A8-4EC1-11D9-B812-000D93554544@drecam.saclay.cea.fr> <41C0807C.6070207@ucsd.edu> Message-ID: <962885F3-4EC7-11D9-A7DA-000A9567635C@redivi.com> On Dec 15, 2004, at 1:20 PM, Robert Kern wrote: > Benjamin Ab?cassis wrote: >> it works OK now, i just de-installed the first version, python works >> fine now (well just like before i installed Xcode, gcc etc... !!!) >> but i still have problems with scipy...it seems like the installer >> can not find a particular library, i've installed FFTW, F2PY though >> here is the log : > > [etc] > > Scipy also requires a FORTRAN compiler. If you have Fink, install the > package g77. Otherwise, install g77 from http://hpc.sf.net . It's also called g77 in darwinports -bob From hengist.podd at virgin.net Thu Dec 16 17:47:21 2004 From: hengist.podd at virgin.net (has) Date: Thu Dec 16 17:47:29 2004 Subject: [Pythonmac-SIG] py2app standalone options Message-ID: Hi, One for Bob really, but I'm trying to figure out how to build a non-standalone app using py2app. This was easy (albeit clumsy) with bundlebuilder - just set both 'standalone' and 'semi-standalone' options to False. I see a 'semi-standalone' option in py2app, but that still includes a big wadge of stuff I don't want/need, and I don't see any obvious, simple way to tell it not to include ANY external dependencies. Have I've missed something? (The current documentation is minimal, and the main docstring in particular appears out of date.) Or is it an oversight in the API/UI design, in which case I'd suggest replacing the boolean 'semi-standalone' option with a new 'dependencies' option that takes one of three values: 'all', 'semi', or 'none'. Ta, has -- http://freespace.virgin.net/hamish.sanderson/ From bob at redivi.com Thu Dec 16 19:49:15 2004 From: bob at redivi.com (Bob Ippolito) Date: Thu Dec 16 19:49:56 2004 Subject: [Pythonmac-SIG] py2app standalone options In-Reply-To: References: Message-ID: <2F35FE2F-4F93-11D9-B499-000A9567635C@redivi.com> On Dec 16, 2004, at 11:47 AM, has wrote: > One for Bob really, but I'm trying to figure out how to build a > non-standalone app using py2app. This was easy (albeit clumsy) with > bundlebuilder - just set both 'standalone' and 'semi-standalone' > options to False. I see a 'semi-standalone' option in py2app, but that > still includes a big wadge of stuff I don't want/need, and I don't see > any obvious, simple way to tell it not to include ANY external > dependencies. > > Have I've missed something? (The current documentation is minimal, and > the main docstring in particular appears out of date.) Or is it an > oversight in the API/UI design, in which case I'd suggest replacing > the boolean 'semi-standalone' option with a new 'dependencies' option > that takes one of three values: 'all', 'semi', or 'none'. (py2app) --semi-standalone (-s) depend on an existing installation of Python 2.3 (FORCED: Using vendor Python) (bundlebuilder) --semi-standalone build a standalone application, which depends on an installed Python, yet includes all third-party modules. --semi-standalone means do not include a Python interpreter or anything from its standard library, and it means the same thing as it did in bundlebuilder. It still does the dependency scan for third party python code and dependent libraries/frameworks. If you want to depend on third party stuff in site-packages, too bad, you'll have to exclude them all individually and use --site-packages. The way to tell it to include nothing is to build an alias bundle (-A), which is for development only and doesn't create something suitable for redistribution. -bob From hengist.podd at virgin.net Thu Dec 16 20:14:57 2004 From: hengist.podd at virgin.net (has) Date: Thu Dec 16 20:15:05 2004 Subject: [Pythonmac-SIG] py2app standalone options In-Reply-To: <2F35FE2F-4F93-11D9-B499-000A9567635C@redivi.com> References: <2F35FE2F-4F93-11D9-B499-000A9567635C@redivi.com> Message-ID: Bob wrote: >[py2app] still does the dependency scan for third party python code >and dependent libraries/frameworks. If you want to depend on third >party stuff in site-packages, too bad, you'll have to exclude them >all individually and use --site-packages. Why? has -- http://freespace.virgin.net/hamish.sanderson/ From bob at redivi.com Thu Dec 16 20:35:15 2004 From: bob at redivi.com (Bob Ippolito) Date: Thu Dec 16 20:35:51 2004 Subject: [Pythonmac-SIG] py2app standalone options In-Reply-To: References: <2F35FE2F-4F93-11D9-B499-000A9567635C@redivi.com> Message-ID: <9C444D88-4F99-11D9-B499-000A9567635C@redivi.com> On Dec 16, 2004, at 2:14 PM, has wrote: > Bob wrote: > >> [py2app] still does the dependency scan for third party python code >> and dependent libraries/frameworks. If you want to depend on third >> party stuff in site-packages, too bad, you'll have to exclude them >> all individually and use --site-packages. > > Why? Because I don't care about your use case. It's rare and is very often not what people want. If you're distributing an application with some particular package, like appscript, then just explicitly exclude appscript and turn on --site-packages and it will effectively be "without dependencies". -bob From Chris.Barker at noaa.gov Thu Dec 16 20:35:14 2004 From: Chris.Barker at noaa.gov (Chris Barker) Date: Thu Dec 16 20:38:56 2004 Subject: [Pythonmac-SIG] py2app standalone options In-Reply-To: <2F35FE2F-4F93-11D9-B499-000A9567635C@redivi.com> References: <2F35FE2F-4F93-11D9-B499-000A9567635C@redivi.com> Message-ID: <41C1E372.6020107@noaa.gov> Bob Ippolito wrote: > The way to tell it to include nothing is to build an alias bundle (-A), > which is for development only and doesn't create something suitable for > redistribution. Can you tell us more about what an Alias bundle is? Is like the old MacPython applet? What I would like is a bundle that includes all the code that isn't installed in the Python tree, but none of the code that is installed in that tree. Is that what an Alias bundle is? -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov From hengist.podd at virgin.net Thu Dec 16 20:40:36 2004 From: hengist.podd at virgin.net (has) Date: Thu Dec 16 20:41:01 2004 Subject: [Pythonmac-SIG] py2app standalone options In-Reply-To: <9C444D88-4F99-11D9-B499-000A9567635C@redivi.com> References: <2F35FE2F-4F93-11D9-B499-000A9567635C@redivi.com> <9C444D88-4F99-11D9-B499-000A9567635C@redivi.com> Message-ID: Bob wrote: >>>[py2app] still does the dependency scan for third party python >>>code and dependent libraries/frameworks. If you want to depend on >>>third party stuff in site-packages, too bad, you'll have to >>>exclude them all individually and use --site-packages. >> >>Why? > >Because I don't care about your use case. It's rare and is very >often not what people want. How rare? has -- http://freespace.virgin.net/hamish.sanderson/ From bob at redivi.com Thu Dec 16 20:52:56 2004 From: bob at redivi.com (Bob Ippolito) Date: Thu Dec 16 20:53:34 2004 Subject: [Pythonmac-SIG] py2app standalone options In-Reply-To: <41C1E372.6020107@noaa.gov> References: <2F35FE2F-4F93-11D9-B499-000A9567635C@redivi.com> <41C1E372.6020107@noaa.gov> Message-ID: <14E8E66A-4F9C-11D9-B499-000A9567635C@redivi.com> On Dec 16, 2004, at 2:35 PM, Chris Barker wrote: > Bob Ippolito wrote: > >> The way to tell it to include nothing is to build an alias bundle >> (-A), which is for development only and doesn't create something >> suitable for redistribution. > > Can you tell us more about what an Alias bundle is? Is like the old > MacPython applet? > > What I would like is a bundle that includes all the code that isn't > installed in the Python tree, but none of the code that is installed > in that tree. Is that what an Alias bundle is? --semi-standalone includes all third party code (anything used by /Library/Python/2.3 and otherwise) and nothing else. This is the forced default if you are using a /System installation of Python. If you are using a third party Python, it is not the default. an alias bundle is for development, like bundlebuilder's --link option. It makes symlinks to any data files, and runs your code in-place. It's very very fast to build an alias bundle, and provides for a very fast edit/run cycle. The PyObjC documentation and tutorials have been updated to use py2app, you might want to also read this: http://svn.red-bean.com/pyobjc/trunk/pyobjc/Doc/tutorial/tutorial.html -bob From bob at redivi.com Thu Dec 16 20:55:15 2004 From: bob at redivi.com (Bob Ippolito) Date: Thu Dec 16 20:55:51 2004 Subject: [Pythonmac-SIG] py2app standalone options In-Reply-To: References: <2F35FE2F-4F93-11D9-B499-000A9567635C@redivi.com> <9C444D88-4F99-11D9-B499-000A9567635C@redivi.com> Message-ID: <67952862-4F9C-11D9-B499-000A9567635C@redivi.com> On Dec 16, 2004, at 2:40 PM, has wrote: > Bob wrote: > >>>> [py2app] still does the dependency scan for third party python code >>>> and dependent libraries/frameworks. If you want to depend on third >>>> party stuff in site-packages, too bad, you'll have to exclude them >>>> all individually and use --site-packages. >>> >>> Why? >> >> Because I don't care about your use case. It's rare and is very >> often not what people want. > > How rare? Rare enough that I can't justify writing the code and adding yet another option. If you don't need a redistributable application, then use an alias bundle. If you want a redistributable application, then include the dependencies. -bob From Chris.Barker at noaa.gov Thu Dec 16 21:07:15 2004 From: Chris.Barker at noaa.gov (Chris Barker) Date: Thu Dec 16 21:10:54 2004 Subject: [Pythonmac-SIG] py2app standalone options In-Reply-To: <67952862-4F9C-11D9-B499-000A9567635C@redivi.com> References: <2F35FE2F-4F93-11D9-B499-000A9567635C@redivi.com> <9C444D88-4F99-11D9-B499-000A9567635C@redivi.com> <67952862-4F9C-11D9-B499-000A9567635C@redivi.com> Message-ID: <41C1EAF3.4060605@noaa.gov> Bob Ippolito wrote: > Rare enough that I can't justify writing the code and adding yet another > option. That, of course, is your judgment. However, I'm not sure it's a rare as you think. I, for one, want to be able to distribute apps to folks whose environment I have control over, so I know that they will have all the packages installed that my apps need, so I want them to just get the app-specific code. I haven't had a chance to try it yet, but it sounds like py2app does have a way to exclude specified packages, so I could just make a point of excluding wxPython, Numeric, PIL, MyPersonalPackage, etc, and I'd get what I want. Is that the case? -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov From bob at redivi.com Thu Dec 16 21:20:18 2004 From: bob at redivi.com (Bob Ippolito) Date: Thu Dec 16 21:20:54 2004 Subject: [Pythonmac-SIG] py2app standalone options In-Reply-To: <41C1EAF3.4060605@noaa.gov> References: <2F35FE2F-4F93-11D9-B499-000A9567635C@redivi.com> <9C444D88-4F99-11D9-B499-000A9567635C@redivi.com> <67952862-4F9C-11D9-B499-000A9567635C@redivi.com> <41C1EAF3.4060605@noaa.gov> Message-ID: On Dec 16, 2004, at 3:07 PM, Chris Barker wrote: > Bob Ippolito wrote: >> Rare enough that I can't justify writing the code and adding yet >> another option. > > That, of course, is your judgment. However, I'm not sure it's a rare > as you think. I, for one, want to be able to distribute apps to folks > whose environment I have control over, so I know that they will have > all the packages installed that my apps need, so I want them to just > get the app-specific code. If you want to write and maintain that functionality, patches accepted. > I haven't had a chance to try it yet, but it sounds like py2app does > have a way to exclude specified packages, so I could just make a point > of excluding wxPython, Numeric, PIL, MyPersonalPackage, etc, and I'd > get what I want. Is that the case? Yes, the --excludes option does exactly that. -bob From hengist.podd at virgin.net Fri Dec 17 00:00:06 2004 From: hengist.podd at virgin.net (has) Date: Fri Dec 17 00:00:13 2004 Subject: [Pythonmac-SIG] py2app standalone options In-Reply-To: <67952862-4F9C-11D9-B499-000A9567635C@redivi.com> References: <2F35FE2F-4F93-11D9-B499-000A9567635C@redivi.com> <9C444D88-4F99-11D9-B499-000A9567635C@redivi.com> <67952862-4F9C-11D9-B499-000A9567635C@redivi.com> Message-ID: Bob wrote: >>>Because I don't care about your use case. It's rare and is very >>>often not what people want. >> >>How rare? > >Rare enough that I can't justify writing the code and adding yet >another option. > > If you don't need a redistributable application, then use an alias >bundle. If you want a redistributable application, then include the >dependencies. If you were writing py2app simply to please yourself I wouldn't bother raising the issue, but since you intend it to replace BundleBuilder in the standard distribution I can't really see "I don't care about your use case" being sufficient justification for such a design decision. You've just spent weeks, if not months, designing and constructing py2app - a not insignificant piece of software engineering. I'd be rather surprised if it'd take you more than a few minutes to insert an option that bypasses the modulegraph component at the point where it connects to the rest of py2app, assuming a properly-factored, maintainable design. As to what I want: I would like a really quick, easy way to churn out lightweight distributable applets that don't lug around stuff they don't need to. BundleBuilder has no problem doing this; heck, even a crap language like AppleScript can do it. Is it really py2app's place to dictate to users how they should or shouldn't build THEIR apps? Personally, if I want py2app to resolve and include my applications' dependencies, I shall be only too happy to ask it to do so. But if I don't, I'd appreciate it minding its own business respecting that choice. (And no, forcing me to manually resolve and manually exclude all my applications' dependencies for it doesn't count.) ... On a separate issue, I've noticed the semi-standalone option appears to be buggy in 0.1.6. When I set it to true, py2app correctly omits standard modules and extensions from Resources/Python, but is still including the core Python.framework. I'm running MacPython 2.3.3 under OS 10.2.8. If you want the build logs and/or finished application bundles, let me know and I'll email them over. has -- http://freespace.virgin.net/hamish.sanderson/ From bob at redivi.com Fri Dec 17 00:29:36 2004 From: bob at redivi.com (Bob Ippolito) Date: Fri Dec 17 00:30:13 2004 Subject: [Pythonmac-SIG] py2app standalone options In-Reply-To: References: <2F35FE2F-4F93-11D9-B499-000A9567635C@redivi.com> <9C444D88-4F99-11D9-B499-000A9567635C@redivi.com> <67952862-4F9C-11D9-B499-000A9567635C@redivi.com> Message-ID: <5983E128-4FBA-11D9-A3DC-000A9567635C@redivi.com> On Dec 16, 2004, at 6:00 PM, has wrote: > Bob wrote: > >>>> Because I don't care about your use case. It's rare and is very >>>> often not what people want. >>> >>> How rare? >> >> Rare enough that I can't justify writing the code and adding yet >> another option. >> >> If you don't need a redistributable application, then use an alias >> bundle. If you want a redistributable application, then include the >> dependencies. > > If you were writing py2app simply to please yourself I wouldn't bother > raising the issue, but since you intend it to replace BundleBuilder in > the standard distribution I can't really see "I don't care about your > use case" being sufficient justification for such a design decision. > You've just spent weeks, if not months, designing and constructing > py2app - a not insignificant piece of software engineering. I'd be > rather surprised if it'd take you more than a few minutes to insert an > option that bypasses the modulegraph component at the point where it > connects to the rest of py2app, assuming a properly-factored, > maintainable design. > > As to what I want: I would like a really quick, easy way to churn out > lightweight distributable applets that don't lug around stuff they > don't need to. BundleBuilder has no problem doing this; heck, even a > crap language like AppleScript can do it. Is it really py2app's place > to dictate to users how they should or shouldn't build THEIR apps? > Personally, if I want py2app to resolve and include my applications' > dependencies, I shall be only too happy to ask it to do so. But if I > don't, I'd appreciate it minding its own business respecting that > choice. (And no, forcing me to manually resolve and manually exclude > all my applications' dependencies for it doesn't count.) Adding this option causes more problems than it solves. I don't think it's a good idea and I don't want to support that usage, especially not at this time. py2exe does not implement this option either. I'm not going to implement this in py2app any time soon. Feel free to do it yourself, either by subclassing py2app (then using the cmdclass argument to setup(...)), or by writing a patch against py2app that makes this option available. > On a separate issue, I've noticed the semi-standalone option appears > to be buggy in 0.1.6. When I set it to true, py2app correctly omits > standard modules and extensions from Resources/Python, but is still > including the core Python.framework. I'm running MacPython 2.3.3 under > OS 10.2.8. If you want the build logs and/or finished application > bundles, let me know and I'll email them over. I'm pretty sure I know why this is, I'll fix it before next release. -bob From hengist.podd at virgin.net Fri Dec 17 02:15:37 2004 From: hengist.podd at virgin.net (has) Date: Fri Dec 17 02:15:47 2004 Subject: [Pythonmac-SIG] py2app standalone options In-Reply-To: <5983E128-4FBA-11D9-A3DC-000A9567635C@redivi.com> References: <2F35FE2F-4F93-11D9-B499-000A9567635C@redivi.com> <9C444D88-4F99-11D9-B499-000A9567635C@redivi.com> <67952862-4F9C-11D9-B499-000A9567635C@redivi.com> <5983E128-4FBA-11D9-A3DC-000A9567635C@redivi.com> Message-ID: Bob wrote: >Adding this option causes more problems than it solves. Such as? >Feel free to do it yourself, either by subclassing py2app (then >using the cmdclass argument to setup(...)), or by writing a patch >against py2app that makes this option available. Aye well, I'm not really up to digesting the larger py2app codebase right now (it's dense and uncommented, and I struggle enough with my own code which I already know and love), though maybe if you gave us a few ballpark pointers I might manage something. >>On a separate issue, I've noticed the semi-standalone option >>appears to be buggy in 0.1.6. When I set it to true, py2app >>correctly omits standard modules and extensions from >>Resources/Python, but is still including the core Python.framework. >>I'm running MacPython 2.3.3 under OS 10.2.8. If you want the build >>logs and/or finished application bundles, let me know and I'll >>email them over. > >I'm pretty sure I know why this is, I'll fix it before next release. Cool, ta. has -- http://freespace.virgin.net/hamish.sanderson/ From mww at opendarwin.org Fri Dec 17 17:08:37 2004 From: mww at opendarwin.org (Markus Weissmann) Date: Fri Dec 17 17:08:46 2004 Subject: [Pythonmac-SIG] Re: Python Framework vs 'traditional' was Re: version numbers and dependencies In-Reply-To: <8CAD8B27-5044-11D9-9543-000A9567635C@redivi.com> References: <41BFE73A.5020705@dslextreme.com> <0F4FF9C9-4FBA-11D9-9FEB-000A956A6E02@opendarwin.org> <59173FD8-4FBB-11D9-A3DC-000A9567635C@redivi.com> <20041217104940.GA1439@remote.gene-hacker.net> <0BE275BA-5037-11D9-9788-000D93AE2252@opendarwin.org> <1568931C-5040-11D9-9788-000D93AE2252@opendarwin.org> <8CAD8B27-5044-11D9-9543-000A9567635C@redivi.com> Message-ID: On Dec 17, 2004, at 16:58, Bob Ippolito wrote: > > On Dec 17, 2004, at 10:26 AM, Markus Weissmann wrote: > >> On Dec 17, 2004, at 16:04, Bob Ippolito wrote: >> >>> Yes, default on darwin/mac os x is what we both meant :) >> >> did someone already tried to compile python 2.4 with >> --enable-framework _and_ tried >> to destroot the install? >> It seems utterly broken - some stuff relies on already installed >> files which are - of course - >> not yet in the installdir but inside the destroot... >> >> ./python.exe ./Mac/scripts/BuildApplet.py \ >> --python >> /opt/local/Python.framework/Versions/2.4/Resources/Python.app/ >> Contents/MacOS/Python \ >> --output >> /opt/darwinports/dports/lang/python24/work/destroot/Applications/ >> MacPython-2.4/BuildApplet.app \ >> ./Mac/scripts/BuildApplet.py >> Traceback (most recent call last): > ---- >> IOError: [Errno 2] No such file or directory: >> '/opt/local/Python.framework/Versions/2.4/Resources/Python.app/ >> Contents/MacOS/Python' > > That's going to be a mess to fix, bundlebuilder is an ugly mess of > code that never really worked quite right in the first place -- which > is why py2app exists. Current versions of py2app would have a similar > problem, though, because for "lightweight" semi-standalone application > bundles it would expect to find the Python runtime in its current > location, not its future location. I'll see about adding an option > similar to "--python" that allows you to override its preference for a > Python runtime location before py2app 0.1.7 is released. > > For now, I would recommend not running "make frameworkinstallextras". > The "extras" it installs are mostly garbage anyway (an Applet building > tool that doesn't quite work very well, an ancient IDE without syntax > highlighting, etc.), most of them won't work unless WASTE was around > during compile time (which it probably isn't), and we're not losing > any functionality from the current default build style. > ok - I did a "make frameworkinstall" - is there a straight way to suppress installing the extras? -mww --- Markus W. Weissmann http://www.mweissmann.de/ http://www.opendarwin.org/~mww/ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20041217/d0f9ccc9/PGP.pgp From romb23 at yahoo.co.uk Fri Dec 17 21:38:02 2004 From: romb23 at yahoo.co.uk (Brad R) Date: Fri Dec 17 21:38:06 2004 Subject: [Pythonmac-SIG] Broken IDLE on Panther. Where are the user preferences? Message-ID: <20041217203802.40550.qmail@web42106.mail.yahoo.com> I installed IDLE as follows (From FAQ 4.5): "Download and install TclTkAqua Download and install the MacPythonPantherAddons if you are using the version of Python 2.3 included with OS X 10.3 Open PackageManager, it is located in /Applications/MacPython-2.3 Install _tkinter You may then use Tkinter based applications such as IDLE" It worked fine until I decided to change some key bindings through IDLE preferences. After that, IDLE wouldn't start. IDLE still works fine logged in as a different user and PythonIDE still works in my home folder so I assume some IDLE specific user preferences were corrupted in my home directory. Questions: 1. I want to blow away all traces of IDLE in my home directory to try to fix this. What files are added or changed in a user directory (ie /Users/rob)? I found IDLE.plist in ~/Library/Preferences but Trashing it didn't help. 2. Any other suggestions to get IDLE working again in my home directory? Thanks in advance. ___________________________________________________________ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com From Chris.Barker at noaa.gov Fri Dec 17 21:59:55 2004 From: Chris.Barker at noaa.gov (Chris Barker) Date: Fri Dec 17 22:03:38 2004 Subject: [Pythonmac-SIG] py2app standalone options In-Reply-To: References: <2F35FE2F-4F93-11D9-B499-000A9567635C@redivi.com> <9C444D88-4F99-11D9-B499-000A9567635C@redivi.com> <67952862-4F9C-11D9-B499-000A9567635C@redivi.com> <5983E128-4FBA-11D9-A3DC-000A9567635C@redivi.com> Message-ID: <41C348CB.9020601@noaa.gov> Hi all, I originally came down on Has' side of this debate, but now think Bob has made the right choices, so I thought I'd add a couple comments. First, I'm a little unclear on what exactly Has wants. Could you clarify? I know what I want, I think what Bob has done accomidates this very well. If you want an app that will run on the machine you developed it on, the Alias option is perfect. If you want to deploy an app to other users, but either know or expect them to have a bunch of stuff installed into their Python, you don't want it all included by Py2App. However, I realized that it is highly unlikely that your users will have the exact same installation as you do, so it's best to be explicte about what they need installed, and those things you specify to be excluded by Py2App. I, for instance, expect my users to have: wxPython PIL Numeric Installed, so I can exclude those, but I'd rather not inadvertantly create a dependence on an obscure package I forgot I had used. If you want to deliver some code with the idea that users are completely on their own about dependencies, then just deliver the code, and let them run Py2app themselves, if need be. So, the only use case I can think of for what Has is asking for is one where you want to deliver an app to users that are guaranteed to have EVERYTHING that the developer has installed. This does, indeed, sound like a rare use case to me. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov From bob at redivi.com Fri Dec 17 23:20:01 2004 From: bob at redivi.com (Bob Ippolito) Date: Fri Dec 17 23:20:41 2004 Subject: [Pythonmac-SIG] py2app standalone options In-Reply-To: <41C348CB.9020601@noaa.gov> References: <2F35FE2F-4F93-11D9-B499-000A9567635C@redivi.com> <9C444D88-4F99-11D9-B499-000A9567635C@redivi.com> <67952862-4F9C-11D9-B499-000A9567635C@redivi.com> <5983E128-4FBA-11D9-A3DC-000A9567635C@redivi.com> <41C348CB.9020601@noaa.gov> Message-ID: On Dec 17, 2004, at 3:59 PM, Chris Barker wrote: > I originally came down on Has' side of this debate, but now think Bob > has made the right choices, so I thought I'd add a couple comments. > > First, I'm a little unclear on what exactly Has wants. Could you > clarify? I think he just wants full control and is either not satisfied with the performance or modulegraph or doesn't trust it to do the right thing. Which is fine, but I don't really care. I'm more concerned about doing the right thing the majority of the time than accommodating strange requests. I have ideas about a refactoring at *some point* that would suit his use case, but it's still in the don't-really-need-it phase so it's not going to happen any time soon. Essentially, I may abstract the dependency analysis to plugins. Currently there are two mostly-but-not-really independent dependency analysis tools in py2app: macholib and modulegraph, which analyze Mach-O object files and Python bytecode respectively (the interdependency is introduced by py2app, not either of these packages, and that's because Python extensions are Mach-O object files). In "py2app 3000" the whole idea of dependency analysis will be abstract which would allow for cached dependency graphs or static dependency lists, analyzing code from other languages and architectures (Perl, Java, TCL, ELF, and other forms of brain damage I'm sure). But, again, this is a don't-really-need-it feature, so I may-not-actually-ever-implement-it. I imagine what is actually happening for him is that he is writing lots of little single-script applications that depend on some combination of his packages (appscript, aem, etc.), and for some reason, adding --site-packages --semi-standalone --excludes=appscript,aem,osaterminology,osax,LaunchServices (via commandline or options=dict(py2app=dict(...))) rubs him the wrong way. His problem with this method is probably only on a theoretical/philosophical level, since that invocation will effectively do exactly what he wants, but is not "optimal" because it does do a full dependency analysis of everything else it sees. Maybe his computer is really slow? I don't know. > I know what I want, I think what Bob has done accomidates this very > well. > > If you want an app that will run on the machine you developed it on, > the Alias option is perfect. I wouldn't say that it's "perfect", but it does usually do the right thing in practice :) > If you want to deploy an app to other users, but either know or expect > them to have a bunch of stuff installed into their Python, you don't > want it all included by Py2App. However, I realized that it is highly > unlikely that your users will have the exact same installation as you > do, so it's best to be explicte about what they need installed, and > those things you specify to be excluded by Py2App. I, for instance, > expect my users to have: > > wxPython > PIL > Numeric > > Installed, so I can exclude those, but I'd rather not inadvertantly > create a dependence on an obscure package I forgot I had used. > > If you want to deliver some code with the idea that users are > completely on their own about dependencies, then just deliver the > code, and let them run Py2app themselves, if need be. > > So, the only use case I can think of for what Has is asking for is one > where you want to deliver an app to users that are guaranteed to have > EVERYTHING that the developer has installed. This does, indeed, sound > like a rare use case to me. The largest reason I think Has' proposed option causes problems beyond what you've already mentioned is that is absolutely requires every single Python module and extension to be explicitly stated as an include. Currently you just point py2app at the main script and expect it to do the right thing (or at least something approaching that, depending on how crazy the code you're analyzing is). In the situation where dependency tracking is turned off, not only will you miss third party libraries and extensions that live on your sys.path, but you'll also miss modules and packages inside your application's source tree. py2app tries very hard, by default, to make the Python environment consistent regardless of what the end user has done to their system. This includes stomping on any PYTHONPATH and ignoring any site-packages that the user has. Due to this, the developer, on their development machine, can be reasonably certain that their application will run anywhere (for a reasonable expectation of anywhere) if it runs at all. So if modulegraph DID miss something, then the developer will know about it before he even tries running the application on another machine. Maybe I am doing a little too much forced-hand-holding and insulting the developer's intelligence a bit, but given the issues that I've seen with similar solutions (particularly py2exe and bundlebuilder) and the general lack of "appreciation" for the myriad of subtle ways you can bork a Python installation on the Mac, I think this is the right solution. If you don't want an application packager that does the right thing more often than not, feel free to use bundlebuilder. If you want a feature in py2app that I don't want to implement, you're going to have to implement it yourself, make an astoundingly good case for it and change my mind, or attempt to bribe me :) I perform a public service, but I'm not a public servant! -bob From bob at redivi.com Sat Dec 18 03:45:55 2004 From: bob at redivi.com (Bob Ippolito) Date: Sat Dec 18 03:46:35 2004 Subject: [Pythonmac-SIG] py2app standalone options In-Reply-To: <5983E128-4FBA-11D9-A3DC-000A9567635C@redivi.com> References: <2F35FE2F-4F93-11D9-B499-000A9567635C@redivi.com> <9C444D88-4F99-11D9-B499-000A9567635C@redivi.com> <67952862-4F9C-11D9-B499-000A9567635C@redivi.com> <5983E128-4FBA-11D9-A3DC-000A9567635C@redivi.com> Message-ID: On Dec 16, 2004, at 6:29 PM, Bob Ippolito wrote: > On Dec 16, 2004, at 6:00 PM, has wrote: > >> On a separate issue, I've noticed the semi-standalone option appears >> to be buggy in 0.1.6. When I set it to true, py2app correctly omits >> standard modules and extensions from Resources/Python, but is still >> including the core Python.framework. I'm running MacPython 2.3.3 >> under OS 10.2.8. If you want the build logs and/or finished >> application bundles, let me know and I'll email them over. > > I'm pretty sure I know why this is, I'll fix it before next release. Fixed in r266. macholib detected Python as a non-system dependency when you end up using extensions not included in the standard library, since they are linked directly to the Python dylib (in some cases, but always for 10.2). Now py2app explicitly excludes any dylib that it thinks is Python when filtering dylibs in semi-standalone mode. -bob From Jack.Jansen at cwi.nl Sun Dec 19 01:29:37 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Sun Dec 19 01:29:29 2004 Subject: [Pythonmac-SIG] Re: Python Framework vs 'traditional' was Re: version numbers and dependencies In-Reply-To: References: <41BFE73A.5020705@dslextreme.com> <0F4FF9C9-4FBA-11D9-9FEB-000A956A6E02@opendarwin.org> <59173FD8-4FBB-11D9-A3DC-000A9567635C@redivi.com> <20041217104940.GA1439@remote.gene-hacker.net> <0BE275BA-5037-11D9-9788-000D93AE2252@opendarwin.org> <1568931C-5040-11D9-9788-000D93AE2252@opendarwin.org> <8CAD8B27-5044-11D9-9543-000A9567635C@redivi.com> Message-ID: <108741A0-5155-11D9-8B11-000D934FF6B4@cwi.nl> >>> did someone already tried to compile python 2.4 with >>> --enable-framework _and_ tried >>> to destroot the install? >>> It seems utterly broken - some stuff relies on already installed >>> files which are - of course - >>> not yet in the installdir but inside the destroot... Hmm, I missed the original of this message, somehow (or was it on darwinports only)? This is a known problem, which is explained in Mac/OSX/Dist/README: > Currently (November 2003) there is still a bug in the build procedure > for $DESTROOT builds: building some of the applets will fail (in > ``Mac/OSX/Makefile``) if you don't have the same version of Python > installed > normally. So before doing the distribution you should build and install > a framework Python in the normal way. Unfortunately, the problem is rather difficult to fix. buildapplet (or py2app, or similar tools) will need to be told that we're in a destroot install situation, so that if it wants filenames it should use the non-destrooted version but if it actually needs the data that's in the files it should use the destrooted filename. I can live with the current workaround for MacPython installers, if it's a problem for darwinports file a bugreport and a solution may be available sooner:-) -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From jxsics at rit.edu Sun Dec 19 18:37:38 2004 From: jxsics at rit.edu (Jon Schull) Date: Mon Dec 20 09:46:14 2004 Subject: [Pythonmac-SIG] Re: Pythonmac-SIG Digest, Vol 20, Issue 23 In-Reply-To: <20041219110007.CE5531E400E@bag.python.org> References: <20041219110007.CE5531E400E@bag.python.org> Message-ID: The problem of multiple pythons on OSX is really really crippling. I use visual python (which requires X which requires one python) and I want to work in and run with the standard OS X look and feel. I spend literally hours every month or two trying (unsuccessfully) to get the various systems to co-exist and the result is not pretty. At the moment, idle doesn't work anywhere, at all. Here's the tip of my iceberg. Suggestions welcome. > 208-186-56-189:~ jis$ idle > -bash: /sw/lib/python2.3/idlelib/idle.py: Permission denied > 208-186-56-189:~ jis$ sudo idle > Password: > Traceback (most recent call last): > File "/sw/bin/idle", line 3, in ? > from idlelib.PyShell import main > File > "/sw/src/root-python23-2.3.4-2/sw/lib/python2.3/idlelib/PyShell.py", > line 11, in ? > File "/sw/lib/python2.3/threading.py", line 13, in ? > from traceback import print_exc as _print_exc > ImportError: cannot import name print_exc > The ideal would of course be a single python. But failing that would be a single installer that would put in place the two (or even more) pythons needed in a manner that allowed one to work and install new modules as needed, without risking obscure disasters. > This is a known problem, which is explained in Mac/OSX/Dist/README: >> Currently (November 2003) there is still a bug in the build procedure >> for $DESTROOT builds: building some of the applets will fail (in >> ``Mac/OSX/Makefile``) if you don't have the same version of Python >> installed >> normally. So before doing the distribution you should build and >> install >> a framework Python in the normal way. > > Unfortunately, the problem is rather difficult to fix. buildapplet (or > py2app, or similar tools) will need to be told that we're in a > destroot install situation, so that if it wants filenames it should > use the non-destrooted version but if it actually needs the data > that's in the files it should use the destrooted filename. > > I can live with the current workaround for MacPython installers, if > it's a problem for darwinports file a bugreport and a solution may be > available sooner:-) > -- > Jack Jansen, , http://www.cwi.nl/~jack > If I can't dance I don't want to be part of your revolution -- Emma > Goldman > > > > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Jon Schull, Ph.D. Associate Professor Information Technology Rochester Institute of Technology 102 Lomb Memorial Drive Rochester, New York 14623 schull@digitalgoods.com 585-738-6696 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 2574 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20041219/9cdd974d/attachment.bin From bob at redivi.com Mon Dec 20 10:04:07 2004 From: bob at redivi.com (Bob Ippolito) Date: Mon Dec 20 10:04:16 2004 Subject: [Pythonmac-SIG] Re: Pythonmac-SIG Digest, Vol 20, Issue 23 In-Reply-To: References: <20041219110007.CE5531E400E@bag.python.org> Message-ID: <1AD82F04-5266-11D9-A77F-000A9567635C@redivi.com> On Dec 19, 2004, at 12:37 PM, Jon Schull wrote: > The problem of multiple pythons on OSX is really really crippling. > I use visual python (which requires X which requires one python) and I > want to work in and run with the standard OS X look and feel. > > I spend literally hours every month or two trying (unsuccessfully) to > get the various systems to co-exist and the result is not pretty. At > the moment, idle doesn't work anywhere, at all. Here's the tip of my > iceberg. Suggestions welcome. >> 208-186-56-189:~ jis$ idle >> -bash: /sw/lib/python2.3/idlelib/idle.py: Permission denied >> 208-186-56-189:~ jis$ sudo idle >> Password: >> Traceback (most recent call last): >> File "/sw/bin/idle", line 3, in ? >> from idlelib.PyShell import main >> File >> "/sw/src/root-python23-2.3.4-2/sw/lib/python2.3/idlelib/PyShell.py", >> line 11, in ? >> File "/sw/lib/python2.3/threading.py", line 13, in ? >> from traceback import print_exc as _print_exc >> ImportError: cannot import name print_exc >> > > The ideal would of course be a single python. But failing that would > be a single installer that would put in place the two (or even more) > pythons needed in a manner that allowed one to work and install new > modules as needed, without risking obscure disasters. There is definitely something wrong with your Fink installation of Python, which probably has no relevance to having multiple Python installations. I stay miles away from Fink, because terrible things have happened every time I've tried it, so I don't know what the problem is specifically. It's especially troubling to see that "idle" and "sudo idle" has different behavior. I suggest reporting these issues to the relevant maintainers for the Fink packages. That permission denied error looks like something is missing a +x and/or the "idle" shell script is not correct For what it's worth, I haven't had any such problems with Darwinports and its Python... however, VPython isn't available from Darwinports at this time, so it's probably not of much use to you yet. -bob From jschull at digitalgoods.com Mon Dec 20 14:30:17 2004 From: jschull at digitalgoods.com (Jon Schull) Date: Mon Dec 20 15:58:19 2004 Subject: [Pythonmac-SIG] Re: Pythonmac-SIG Digest, Vol 20, Issue 24 In-Reply-To: <20041220110109.A83531E401C@bag.python.org> References: <20041220110109.A83531E401C@bag.python.org> Message-ID: <49CB75CC-528B-11D9-B42F-0003939F0DC0@digitalgoods.com> Thanks for the replies Jon said > The problem of multiple pythons on OSX is really really crippling. > I use visual python (which requires X which requires one python) and I > want to work in and run with the standard OS X look and feel. > > I spend literally hours every month or two trying (unsuccessfully) to > get the various systems to co-exist and the result is not pretty. At > the moment, idle doesn't work anywhere, at all. Here's the tip of my > iceberg. Suggestions welcome. >> 208-186-56-189:~ jis$ idle >> -bash: /sw/lib/python2.3/idlelib/idle.py: Permission denied >> 208-186-56-189:~ jis$ sudo idle >> Password: >> Traceback (most recent call last): >> File "/sw/bin/idle", line 3, in ? >> from idlelib.PyShell import main >> File >> "/sw/src/root-python23-2.3.4-2/sw/lib/python2.3/idlelib/PyShell.py", >> line 11, in ? >> File "/sw/lib/python2.3/threading.py", line 13, in ? >> from traceback import print_exc as _print_exc >> ImportError: cannot import name print_exc >> Bob replied > >> There is definitely something wrong with your Fink installation of >> Python, which probably has no relevance to having multiple Python >> installations. I stay miles away from Fink, because terrible things >> have happened every time I've tried it, so I don't know what the >> problem is specifically. It's especially troubling to see that >> "idle" and "sudo idle" has different behavior. I suggest reporting >> these issues to the relevant maintainers for the Fink packages. That >> permission denied error looks like something is missing a +x and/or >> the "idle" shell script is not correct >> >> For what it's worth, I haven't had any such problems with Darwinports >> and its Python... however, VPython isn't available from Darwinports >> at this time, so it's probably not of much use to you yet. >> >> -bob I'll look for the Fink maintainers. For what its worth I came across a seemingly related set of issues last night while trying to get apache to run python cgis. Our solution was to rewrite the #! lines as #! /sw/bin/env /sw/bin/python (the magic was in adding the first phrase). Related discusssion and alternative solutions is at http://projects.edgewall.com/trac/wiki/TracOnOsx Jon said > > The ideal would of course be a single python. But failing that would > be a single installer that would put in place the two (or even more) > pythons needed in a manner that allowed one to work and install new > modules as needed, without risking obscure disasters. > Jack said > This is a known problem, which is explained in Mac/OSX/Dist/README: >> Currently (November 2003) there is still a bug in the build procedure >> for $DESTROOT builds: building some of the applets will fail (in >> ``Mac/OSX/Makefile``) if you don't have the same version of Python >> installed >> normally. So before doing the distribution you should build and >> install >> a framework Python in the normal way. > > Unfortunately, the problem is rather difficult to fix. buildapplet (or > py2app, or similar tools) will need to be told that we're in a > destroot install situation, so that if it wants filenames it should > use the non-destrooted version but if it actually needs the data > that's in the files it should use the destrooted filename. > > I can live with the current workaround for MacPython installers, if > it's a problem for darwinports file a bugreport and a solution may be > available sooner:-) > -- > Jack Jansen, , http://www.cwi.nl/~jack > If I can't dance I don't want to be part of your revolution -- Emma > Goldman Jon sighs... Unfortunate indeed. You can live with it, and I don't even understand your explanation. ;-/ Its ironic that the python community values such elegance in the language yet tolerates such complexity in context. I presume that's because there's no alternative. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Jon Schull, Ph.D. Associate Professor Information Technology Rochester Institute of Technology 102 Lomb Memorial Drive Rochester, New York 14623 schull@digitalgoods.com 585-738-6696 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 4172 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20041220/81a2dd7f/attachment.bin From bob at redivi.com Mon Dec 20 16:21:20 2004 From: bob at redivi.com (Bob Ippolito) Date: Mon Dec 20 16:21:29 2004 Subject: [Pythonmac-SIG] Re: Pythonmac-SIG Digest, Vol 20, Issue 24 In-Reply-To: <49CB75CC-528B-11D9-B42F-0003939F0DC0@digitalgoods.com> References: <20041220110109.A83531E401C@bag.python.org> <49CB75CC-528B-11D9-B42F-0003939F0DC0@digitalgoods.com> Message-ID: On Dec 20, 2004, at 8:30 AM, Jon Schull wrote: > For what its worth I came across a seemingly related set of issues > last night while trying to get apache to run python cgis. Our > solution was to rewrite the #! lines as > #! /sw/bin/env /sw/bin/python (the magic was in adding the first > phrase). Related discusssion and alternative solutions is at > http://projects.edgewall.com/trac/wiki/TracOnOsx Apache starts as root with root's default environment. It's not going to have /sw/bin in its path, so /usr/bin/env python is not going to run Fink python. You might as well replace it with #!/sw/bin/python. Why the hell does Fink have its own env, anyway? > Jon said >> >> The ideal would of course be a single python. But failing that would >> be a single installer that would put in place the two (or even more) >> pythons needed in a manner that allowed one to work and install new >> modules as needed, without risking obscure disasters. Darwinports Python and the vendor Python play together perfectly nicely, with no obscure disasters anywhere that I've seen. If you are having conflicts between Fink and vendor Python, then it must be caused by Fink. Probably due to the init script in your .bashrc / .tcshrc that sets up your environment in such a way that everything you do can end up using or linking to Fink-built stuff. Darwinports doesn't have any such hacks, and never mangles your environment like that. > Jack said >> This is a known problem, which is explained in Mac/OSX/Dist/README: >>> Currently (November 2003) there is still a bug in the build procedure >>> for $DESTROOT builds: building some of the applets will fail (in >>> ``Mac/OSX/Makefile``) if you don't have the same version of Python >>> installed >>> normally. So before doing the distribution you should build and >>> install >>> a framework Python in the normal way. >> >> Unfortunately, the problem is rather difficult to fix. buildapplet >> (or py2app, or similar tools) will need to be told that we're in a >> destroot install situation, so that if it wants filenames it should >> use the non-destrooted version but if it actually needs the data >> that's in the files it should use the destrooted filename. >> >> I can live with the current workaround for MacPython installers, if >> it's a problem for darwinports file a bugreport and a solution may be >> available sooner:-) > > Jon sighs... > Unfortunate indeed. You can live with it, and I don't even understand > your explanation. ;-/ > > Its ironic that the python community values such elegance in the > language yet tolerates such complexity in context. I presume that's > because there's no alternative. As Jack said, if you do things in the supported way, it just works. DESTROOT is only used in relatively strange situations like when building packages with Darwinports (probably Fink too). Since Jack is the maintainer of Python, but not Fink or Darwinports Python, it's more or less YAGNI for him. Given extremely limited time and resources, why solve a problem you don't have? ... and the DESTROOT thing isn't really relevant to the problems you brought up, anyway. This particular limitation only matters if you are building a framework Python, and neither Fink nor Darwinports currently provide such a build. -bob From jschull at digitalgoods.com Mon Dec 20 17:28:53 2004 From: jschull at digitalgoods.com (Jon Schull) Date: Mon Dec 20 17:28:55 2004 Subject: [Pythonmac-SIG] Re: Pythonmac-SIG Digest, Vol 20, Issue 24 In-Reply-To: References: <20041220110109.A83531E401C@bag.python.org> <49CB75CC-528B-11D9-B42F-0003939F0DC0@digitalgoods.com> Message-ID: <3CF436E8-52A4-11D9-B42F-0003939F0DC0@digitalgoods.com> Thanks to your comments, I think I'm making some progress here ... On Dec 20, 2004, at 10:21 AM, Bob Ippolito wrote: > Apache starts as root with root's default environment. It's not going > to have /sw/bin in its path, so /usr/bin/env python is not going to > run Fink python. You might as well replace it with #!/sw/bin/python. that didn't work. We needed the compound line #!/sw/bin/env /sw/bin/python in the scripts > Why the hell does Fink have its own env, anyway? you're asking me? > > Darwinports Python and the vendor Python play together perfectly > nicely, with no obscure disasters anywhere that I've seen. If you are > having conflicts between Fink and vendor Python, then it must be > caused by Fink. Probably due to the init script in your .bashrc / > .tcshrc that sets up your environment in such a way that everything > you do can end up using or linking to Fink-built stuff. Darwinports > doesn't have any such hacks, and never mangles your environment like > that. in my home directory I have neither .bashrc nor .tcshrc I did have a .profile and a .pythonrc I renamed both, Quit terminal and restarted and got new symptoms > 208-186-56-189:/sw/bin jis$ idle > -bash: idle: command not found > 208-186-56-189:/sw/bin jis$ /sw/bin/idle > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort trap > 208-186-56-189:/sw/bin jis$ cat /sw/bin/idle2.3 > #!/sw/bin/python > > from idlelib.PyShell import main > main() so I tried it manually > 208-186-56-189:/sw/bin jis$ /sw/bin/python > Python 2.3.4 (#1, Nov 7 2004, 14:21:14) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> from idlelib.PyShell import main > >>> main() > Traceback (most recent call last): > File "", line 1, in ? > File > "/sw/src/root-python23-2.3.4-2/sw/lib/python2.3/idlelib/PyShell.py", > line 1274, in main > File "/sw/lib/python2.3/lib-tk/Tkinter.py", line 1564, in __init__ > self.tk = _tkinter.create(screenName, baseName, className) > _tkinter.TclError: this isn't a Tk applicationcouldn't connect to > display ":0.0" I ran startx in a separate terminal window... > >>> main() > >>> > this time it worked (and within idle, vpython worked) so there's something different about running idle from the command line versus from within python???? =-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Jon Schull, Ph.D. Associate Professor Information Technology Rochester Institute of Technology 102 Lomb Memorial Drive Rochester, New York 14623 schull@digitalgoods.com 585-738-6696 From ronaldoussoren at mac.com Mon Dec 20 17:42:23 2004 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Mon Dec 20 17:42:36 2004 Subject: [Pythonmac-SIG] Re: Pythonmac-SIG Digest, Vol 20, Issue 24 In-Reply-To: <3CF436E8-52A4-11D9-B42F-0003939F0DC0@digitalgoods.com> References: <20041220110109.A83531E401C@bag.python.org> <49CB75CC-528B-11D9-B42F-0003939F0DC0@digitalgoods.com> <3CF436E8-52A4-11D9-B42F-0003939F0DC0@digitalgoods.com> Message-ID: <1F770FBE-52A6-11D9-BC8B-000D93AD379E@mac.com> >> 208-186-56-189:/sw/bin jis$ cat /sw/bin/idle2.3 >> #!/sw/bin/python Which python is first on your path? IIRC there is a feature in darwin that wreaks havoc with the setup code in python that finds the correct prefix (and library). This ends up always picking the prefix for the first python on the path. Darwinports contains a patch for that. Using "#!/usr/bin/env /sw/bin/python" should also work. Ronald From jschull at digitalgoods.com Mon Dec 20 18:38:54 2004 From: jschull at digitalgoods.com (Jon Schull) Date: Mon Dec 20 18:38:59 2004 Subject: [Pythonmac-SIG] Re: Pythonmac-SIG Digest, Vol 20, Issue 24 In-Reply-To: <1F770FBE-52A6-11D9-BC8B-000D93AD379E@mac.com> References: <20041220110109.A83531E401C@bag.python.org> <49CB75CC-528B-11D9-B42F-0003939F0DC0@digitalgoods.com> <3CF436E8-52A4-11D9-B42F-0003939F0DC0@digitalgoods.com> <1F770FBE-52A6-11D9-BC8B-000D93AD379E@mac.com> Message-ID: <053079D9-52AE-11D9-B42F-0003939F0DC0@digitalgoods.com> many successes one failure (the macpython2.3 IDE no longer works) Jeff wrote: > Jon: You're supposed to source /sw/bin/init.sh to set up the fink > environment. If you don't do that, a lot of things won't work. > > http://fink.sourceforge.net/doc/users-guide/install.php? > phpLang=en#setup > that sounds like me. A lot of things don't work. ;-> So I ran /sw/bin/pathsetup.sh as per http://fink.sourceforge.net/doc/users-guide/install.php? phpLang=en#setup This gave me an encouraging message, and now (assuming I startx) idle works. On Dec 20, 2004, at 11:42 AM, Ronald Oussoren wrote: > Which python is first on your path? IIRC there is a feature in darwin > that wreaks havoc with the setup code in python that finds the correct > prefix (and library). This ends up always picking the prefix for the > first python on the path. Darwinports contains a patch for that. Using > "#!/usr/bin/env /sw/bin/python" should also work. So at this point, fink python is first on my path > 208-186-56-189:~/freemind jis$ which python > /sw/bin/python > 208-186-56-189:~/freemind jis$ which idle > /sw/bin/idle > from the command line I can now run /sw/bin/python, /usr/bin/python, and /usr/local/bin/python successfully "idle" and "python" work too and support vpython. Let's take inventory > 208-186-56-189:~ jis$ cat showSysPath.py > import sys > print sys.path > 208-186-56-189:~ jis$ python showSysPath.py > ['/Users/jis', '/sw/lib/python23.zip', '/sw/lib/python2.3', > '/sw/lib/python2.3/plat-darwin', '/sw/lib/python2.3/plat-mac', > '/sw/lib/python2.3/plat-mac/lib-scriptpackages', > '/sw/lib/python2.3/lib-tk', '/sw/lib/python2.3/lib-dynload', > '/sw/lib/python2.3/site-packages', > '/sw/lib/python2.3/site-packages/Numeric', > '/sw/lib/python2.3/site-packages/PyObjC', > '/sw/lib/python2.3/site-packages/gtk-2.0'] > 208-186-56-189:~ jis$ /usr/bin/python showSysPath.py > ['/Users/jis', > '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python23.zip', > '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3', > '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/plat-darwin', > '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/plat-mac', > '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/plat-mac/lib-scriptpackages', > '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/lib-tk', > '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/lib-dynload', > '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/site-packages', > '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/site-packages/PyObjC'] > 208-186-56-189:~ jis$ /usr/local/bin/python showSysPath.py > ['/Users/jis', '/usr/local/lib/python23.zip', > '/usr/local/lib/python2.3', '/usr/local/lib/python2.3/plat-darwin', > '/usr/local/lib/python2.3/plat-mac', > '/usr/local/lib/python2.3/plat-mac/lib-scriptpackages', > '/usr/local/lib/python2.3/lib-tk', > '/usr/local/lib/python2.3/lib-dynload', > '/usr/local/lib/python2.3/site-packages'] Now if I double click on "/Applications/MacPython-2.3/PythonIDE.app" the startup screen appears briefly and disappears. The console gets > ===== Mon Dec 20 2004 ===== 12:31:36 US/Eastern ===== > Traceback (most recent call last): > File > "/Applications/MacPython-2.3/PythonIDE.app/Contents/Resources/ > PythonIDE.py", line 59, in ? > _PythonIDEMain.PythonIDE() > File > "/Applications/MacPython-2.3/PythonIDE.app/Contents/Resources/ > PythonIDEMain.py", line 41, in __init__ > Wapplication.Application.__init__(self, 'Pide') > File > "/System/Library/Frameworks/Python.framework/Versions/2.3/Mac/Tools/ > IDE/Wapplication.py", line 28, in __init__ > FrameWork.Application.__init__(self) > File > "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/plat-mac/FrameWork.py", line 115, in __init__ > self.makemenubar() > File > "/System/Library/Frameworks/Python.framework/Versions/2.3/Mac/Tools/ > IDE/Wapplication.py", line 275, in makemenubar > self.makeusermenus() > File > "/Applications/MacPython-2.3/PythonIDE.app/Contents/Resources/ > PythonIDEMain.py", line 159, in makeusermenus > self.makescriptsmenu() > File > "/Applications/MacPython-2.3/PythonIDE.app/Contents/Resources/ > PythonIDEMain.py", line 261, in makescriptsmenu > self.scriptswalk(fsr.as_pathname(), self.scriptsmenu) > File > "/System/Library/Frameworks/Python.framework/Versions/2.3/Mac/Tools/ > IDE/Wapplication.py", line 309, in scriptswalk > self.scriptswalk(path, submenu, done) > File > "/System/Library/Frameworks/Python.framework/Versions/2.3/Mac/Tools/ > IDE/Wapplication.py", line 309, in scriptswalk > self.scriptswalk(path, submenu, done) > File > "/System/Library/Frameworks/Python.framework/Versions/2.3/Mac/Tools/ > IDE/Wapplication.py", line 308, in scriptswalk > submenu = FrameWork.SubMenu(menu, name) > File > "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/plat-mac/FrameWork.py", line 708, in SubMenu > return menu.addsubmenu(label, title) > File > "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/plat-mac/FrameWork.py", line 595, in addsubmenu > sub = Menu(self.bar, title, -1) > File > "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/plat-mac/FrameWork.py", line 545, in __init__ > self.id, self.menu = self.bar.addmenu(title, after, id) > File > "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/plat-mac/FrameWork.py", line 479, in addmenu > id = self.getnextid() > File > "/System/Library/Frameworks/Python.framework/Versions/2.3/Mac/Tools/ > IDE/Wapplication.py", line 433, in getnextid > id = self.possibleIDs[0] > IndexError: list index out of range > Curiously, if I doubleclick on the Idle in the same directory ("/Applications/MacPython-2.3/IDLE.app") I get an Xish looking idle. > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "copyright", "credits" or "license()" for more information. > > **************************************************************** > Personal firewall software may warn about the connection IDLE > makes to its subprocess using this computer's internal loopback > interface. This connection is not visible on any external > interface and no data is sent to or received from the Internet. > **************************************************************** > > IDLE 1.0 > >>> import sys > >>> print sys.path > ['/', '/Applications/MacPython-2.3/IDLE.app/Contents/Resources', > '/Applications/MacPython-2.3/IDLE.app/Contents/Resources', > '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python23.zip', > '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3', > '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/plat-darwin', > '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/plat-mac', > '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/plat-mac/lib-scriptpackages', > '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/lib-tk', > '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/lib-dynload', > '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/site-packages', > '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/site-packages/PyObjC'] > >>> So, if I have this right, I have 3 pythons, and some further variations. 8-o Should I try reinstalling the macpython addons? (I really appreciate everyone's help on this !) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Jon Schull, Ph.D. Associate Professor Information Technology Rochester Institute of Technology 102 Lomb Memorial Drive Rochester, New York 14623 schull@digitalgoods.com 585-738-6696 From wicked-witch at gmx.net Mon Dec 20 20:06:32 2004 From: wicked-witch at gmx.net (wicked-witch@gmx.net) Date: Mon Dec 20 20:06:34 2004 Subject: [Pythonmac-SIG] Read Strings from Resources Message-ID: <5080.1103569592@www22.gmx.net> I working on a project, where I want to read a STR# resource and write it into an xml file. With Carbon.Res I can easily access the file an read the string Resources for each ID. But with the Res.Get1Resource('STR#', id).data I get all the strings in the list in one string only. Is there a method in python like GetIndSting or something like it? thx for any help -- Psssst! Mit GMX Handyrechnung senken: http://www.gmx.net/de/go/mail 100 FreeSMS/Monat (GMX TopMail), 50 (GMX ProMail), 10 (GMX FreeMail) From brian_l at mac.com Tue Dec 21 13:22:17 2004 From: brian_l at mac.com (Brian Lenihan) Date: Tue Dec 21 13:22:34 2004 Subject: [Pythonmac-SIG] Re: Pythonmac-SIG Digest, Vol 20, Issue 24 Message-ID: > >> 208-186-56-189:/sw/bin jis$ cat /sw/bin/idle2.3 > >> #!/sw/bin/python > > Which python is first on your path? IIRC there is a feature in darwin > that wreaks havoc with the setup code in python that finds the correct > prefix (and library). This ends up always picking the prefix for the > first python on the path. Darwinports contains a patch for that. Using > "#!/usr/bin/env /sw/bin/python" should also work. The "feature" is that OS X does not include the full path to the executable in argv[0]. Using #!/usr/bin/env /path/to/python helps. Especially in the really annoying case where command line scripts work, but scripts launched from applications don't. Which reminds me, both pyobjc's and py2app's bdist_mpkg also could be tweaked so preflight shell scripts won't fail to run on some systems: --- pyobjc_mpkg.py (revision 1287) +++ pyobjc_mpkg.py (working copy) @@ -13,7 +13,7 @@ from bdist_mpkg import tools JUNK = set(['.DS_Store', '.gdb_history', 'build', 'dist', 'NonFunctional']) -JUNK_EXTS = set(['.pbxuser', '.pyc', '.pyo']) +JUNK_EXTS = set(['.pbxuser', '.pyc', '.pyo', '.swp']) def skipjunk(fn, junk=JUNK, junk_exts=JUNK_EXTS): if not skipscm(fn): return False @@ -23,7 +23,8 @@ return False return True -PREFLIGHT_RM = """#!/usr/bin/env python +PREFLIGHT_RM = """\ +#!/usr/bin/env %(sys_executable_path)s import shutil, os for fn in %(files)r: if os.path.isdir(fn): @@ -31,6 +32,7 @@ elif os.path.exists(fn): os.unlink(fn) """ + def run_setup(*args, **kwargs): import distutils.core d = { @@ -45,10 +47,10 @@ for k,v in d.iteritems(): setattr(distutils.core, k, v) - def write_preflight_rm(path, files): fobj = file(path, 'w') - fobj.write(PREFLIGHT_RM % dict(files=map(os.path.normpath, files))) + fobj.write(PREFLIGHT_RM % dict(sys_executable_path=sys.executable, + files=map(os.path.normpath, files))) fobj.close() os.chmod(path, 0775) -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2359 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20041221/0f433e0d/smime.bin From bob at redivi.com Tue Dec 21 14:47:41 2004 From: bob at redivi.com (Bob Ippolito) Date: Tue Dec 21 14:47:48 2004 Subject: [Pythonmac-SIG] Re: Pythonmac-SIG Digest, Vol 20, Issue 24 In-Reply-To: References: Message-ID: On Dec 21, 2004, at 7:22 AM, Brian Lenihan wrote: >> >> 208-186-56-189:/sw/bin jis$ cat /sw/bin/idle2.3 >> >> #!/sw/bin/python >> >> Which python is first on your path? IIRC there is a feature in darwin >> that wreaks havoc with the setup code in python that finds the correct >> prefix (and library). This ends up always picking the prefix for the >> first python on the path. Darwinports contains a patch for that. Using >> "#!/usr/bin/env /sw/bin/python" should also work. > > The "feature" is that OS X does not include the full path to the > executable in argv[0]. Using #!/usr/bin/env /path/to/python helps. > Especially in the really annoying case where command line scripts > work, but scripts launched from applications don't. > > Which reminds me, both pyobjc's and py2app's bdist_mpkg also could be > tweaked so > preflight shell scripts won't fail to run on some systems: Actually, using #!/usr/bin/env %(sys.executable_path) *will* cause it to fail to run in more cases than it will not. I'll take your patch for adding a junk extension, but not this one. -bob From charles.hartman at conncoll.edu Tue Dec 21 16:23:02 2004 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Tue Dec 21 16:23:11 2004 Subject: [Pythonmac-SIG] Where to put data Message-ID: <3479352C-5364-11D9-9C37-000D933C27EA@conncoll.edu> (I also posted this to wxusers because it's sort of cross-platform -- sorry if you're seeing it again.) With an earlier app I wanted an external data file and everybody told me to make it internal to the program (the app's Resources, I guess) instead. I couldn't, then. Now with a new app I want to do just that, but I'm not sure *how* to do it! It's a file of data -- a Python dictionary object, after it's loaded into memory -- which will grow and change as the app is used; when the app terminates the data ought to be saved with it for next time. In this case I don't want users fiddling with it apart from the app. What is the right way to do this? (What's the easy way?) Is there a simple method that will work for both Mac and Windows (and Linux)? Charles Hartman http://cherry.conncoll.edu/cohar http://villex.blogspot.com From Chris.Barker at noaa.gov Tue Dec 21 18:05:38 2004 From: Chris.Barker at noaa.gov (Chris Barker) Date: Tue Dec 21 18:09:33 2004 Subject: [Pythonmac-SIG] Where to put data In-Reply-To: <3479352C-5364-11D9-9C37-000D933C27EA@conncoll.edu> References: <3479352C-5364-11D9-9C37-000D933C27EA@conncoll.edu> Message-ID: <41C857E2.6030300@noaa.gov> Charles Hartman wrote: > With an earlier app I wanted an external data file and everybody told me > to make it internal to the program (the app's Resources, I guess) > instead. I couldn't, then. Now with a new app I want to do just that, > but I'm not sure *how* to do it! > > It's a file of data -- a Python dictionary object, after it's loaded > into memory -- which will grow and change as the app is used; when the > app terminates the data ought to be saved with it for next time. In > this case I don't want users fiddling with it apart from the app. Just a few thoughts. All these systems are multi-user systems, though Linux is the only one that really enforces that behavior in common use. OS-X is second, and Windows is alarmingly sloppy. What this means is that, in general, an application will be installed to a system location, and can be run by multiple users. In this case, a distinction needs to be made between user data and configuration, and system data and configuration. Most Unix software has both, and the usual behavior is to load the system data, then load the users data, perhaps overriding the system data in various ways. The system data is stored in a system location, and can only be changed by the super user. The location of the system data on Linux is usually in /etc/ or somewhere in either /usr or /usr/local (depending on how it's installed) often in /usr/share or /usr/local/share. Take a look at the Linux File system Hierarchy Standard for a description of what to put in share vs lib, vs whatever. In general, what seems like an overly complicated system is designed to accommodate things like networked file systems and heterogeneous networks. If you don't need all that, you can also just put your data into /usr/local/MyApp. User data is generally stored in $HOME/.MyApp On OS-X, there is /Library/MyApp and $HOME/Library/MyApp for system and user data. You also might want to put system data in the Application Bundle, but that won't work for user data, as the user can't change an Application bundle that's installed in the system (at least I hope they can't!) I think if you use the wxConfig system, you'll get the appropriate behavior for user data on all systems, at least for config files. At the app level, everywhere inside your app, you can have a set of application-level variables that store something like: UserDataDir SystemDataDir etc. At startup, you'll need to set these, and that may well require platform specific code. One way to do this on Linux (that I've used) is to have a default hard coded (say /usr/local/MyApp/DataDir). I also have the app look for an environment variable, if it's set, then I use that for the DataDir, if not, I use the default. That way, you can deliver a start-up script that sets the appropriate variable, and then starts your app. All your users (or your installer program) have to do is customize the start-up script if they want to install in a non-standard location. Well, I got a little long winded, but I hope there was something helpful here. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov From rowen at cesmail.net Tue Dec 21 21:17:37 2004 From: rowen at cesmail.net (Russell E. Owen) Date: Tue Dec 21 21:17:45 2004 Subject: [Pythonmac-SIG] Re: Where to put data References: <3479352C-5364-11D9-9C37-000D933C27EA@conncoll.edu> Message-ID: In article <3479352C-5364-11D9-9C37-000D933C27EA@conncoll.edu>, Charles Hartman wrote: >...a file of data...which will grow and change as the app is used; when the > app terminates the data ought to be saved with it for next time. In > this case I don't want users fiddling with it apart from the app. > > What is the right way to do this? (What's the easy way?) Is there a > simple method that will work for both Mac and Windows (and Linux)? I suggest you download the RO package and look at RO.OS.getPrefsDir: Return the user's preferences directory, if found, else None. For MacOS X this is often: ~/Library/Preferences (with ~ expanded) For Mac Classic this is often: System Folder:Preferences For unix this is the user's home directory. For Windows this is often: Windows\Application Support and RO.OS.getAppSuppDirs: Return one or more application support paths (starting with user and going to more widely shared), or [] if none found. For MacOS X this may be: [~/Library/Application Support, /Library/Application Support] For Mac Classic this is probably [] but I'm not sure. for unix and Windows this is [getPrefsDir()] That may help you locate the file, but does not answer how to keep users from fiddling around with it. It'll be a bit buried on Mac and Unix, but all-too-visible on unix unless you pre-pend a "." to the name. -- Russell From bob at redivi.com Tue Dec 21 21:32:34 2004 From: bob at redivi.com (Bob Ippolito) Date: Tue Dec 21 21:32:51 2004 Subject: [Pythonmac-SIG] Where to put data In-Reply-To: <3479352C-5364-11D9-9C37-000D933C27EA@conncoll.edu> References: <3479352C-5364-11D9-9C37-000D933C27EA@conncoll.edu> Message-ID: <722C24F8-538F-11D9-9505-000A9567635C@redivi.com> On Dec 21, 2004, at 10:23 AM, Charles Hartman wrote: > (I also posted this to wxusers because it's sort of cross-platform -- > sorry if you're seeing it again.) > > With an earlier app I wanted an external data file and everybody told > me to make it internal to the program (the app's Resources, I guess) > instead. I couldn't, then. Now with a new app I want to do just that, > but I'm not sure *how* to do it! > > It's a file of data -- a Python dictionary object, after it's loaded > into memory -- which will grow and change as the app is used; when the > app terminates the data ought to be saved with it for next time. In > this case I don't want users fiddling with it apart from the app. > > What is the right way to do this? (What's the easy way?) Is there a > simple method that will work for both Mac and Windows (and Linux)? The right way to do it is NOT to have this file inside your application. You should *never* assume that you can write to your own application bundle. You *should* have a way to create this file from scratch (which may be a template file inside Resources, which is never written to). As others have said there are different places you should put this file dependent on operating system.. On Mac OS X it should probably go in one of the "Application Support" directories. It's common convention to only place plist formatted files in the Preferences directory, so unless you're serializing this dictionary as a plist, I suggest going with Application Support instead of Preferences. On other *nix, it would typically go into a ~/.yourapplication directory. And for Windows, somewhere in their home directory (at least on NT-based Windows). Optionally, you could put it in the registry instead, which may be a good idea, depending on how big it is expected to get. As far as writing to your own application goes, here's a short list of why that's bad: - Will not work from CD-ROM, compressed disk image, etc. - Probably will not work multi-user - Probably a bad idea if the application is on a network drive - User may not have permissions to write to the application - If you break it, you really broke it. - It can look virus-like and be picked up as such (particularly on Win32 if you're writing to the .exe file). You should be able to trust the user not to fiddle with it apart from the app. Especially if it's a pickle file. It will be pretty buried, anyway. -bob From michaelm at opendarwin.org Tue Dec 21 17:02:28 2004 From: michaelm at opendarwin.org (Michael Maibaum) Date: Tue Dec 21 23:02:46 2004 Subject: [Pythonmac-SIG] Re: Python Framework vs 'traditional' was Re: version numbers and dependencies In-Reply-To: References: <41BFE73A.5020705@dslextreme.com> <0F4FF9C9-4FBA-11D9-9FEB-000A956A6E02@opendarwin.org> <59173FD8-4FBB-11D9-A3DC-000A9567635C@redivi.com> <20041217104940.GA1439@remote.gene-hacker.net> <0BE275BA-5037-11D9-9788-000D93AE2252@opendarwin.org> <1568931C-5040-11D9-9788-000D93AE2252@opendarwin.org> <8CAD8B27-5044-11D9-9543-000A9567635C@redivi.com> Message-ID: On 17 Dec 2004, at 16:08, Markus Weissmann wrote: > On Dec 17, 2004, at 16:58, Bob Ippolito wrote: > >> >> On Dec 17, 2004, at 10:26 AM, Markus Weissmann wrote: >> >>> On Dec 17, 2004, at 16:04, Bob Ippolito wrote: >>> >>>> Yes, default on darwin/mac os x is what we both meant :) >>> >>> did someone already tried to compile python 2.4 with >>> --enable-framework _and_ tried >>> to destroot the install? >>> It seems utterly broken - some stuff relies on already installed >>> files which are - of course - >>> not yet in the installdir but inside the destroot... >>> >>> ./python.exe ./Mac/scripts/BuildApplet.py \ >>> --python >>> /opt/local/Python.framework/Versions/2.4/Resources/Python.app/ >>> Contents/MacOS/Python \ >>> --output >>> /opt/darwinports/dports/lang/python24/work/destroot/Applications/ >>> MacPython-2.4/BuildApplet.app \ >>> ./Mac/scripts/BuildApplet.py >>> Traceback (most recent call last): >> ---- >>> IOError: [Errno 2] No such file or directory: >>> '/opt/local/Python.framework/Versions/2.4/Resources/Python.app/ >>> Contents/MacOS/Python' >> >> That's going to be a mess to fix, bundlebuilder is an ugly mess of >> code that never really worked quite right in the first place -- which >> is why py2app exists. Current versions of py2app would have a >> similar problem, though, because for "lightweight" semi-standalone >> application bundles it would expect to find the Python runtime in its >> current location, not its future location. I'll see about adding an >> option similar to "--python" that allows you to override its >> preference for a Python runtime location before py2app 0.1.7 is >> released. >> >> For now, I would recommend not running "make frameworkinstallextras". >> The "extras" it installs are mostly garbage anyway (an Applet >> building tool that doesn't quite work very well, an ancient IDE >> without syntax highlighting, etc.), most of them won't work unless >> WASTE was around during compile time (which it probably isn't), and >> we're not losing any functionality from the current default build >> style. >> > > ok - I did a "make frameworkinstall" - is there a straight way to > suppress installing the extras? > Ok, here is a version that appears to work, I've basically just patched the OSX specific Makefile to only do the install_Python installation target, + some moving around of files that ignore prefix. -------------- next part -------------- A non-text attachment was scrubbed... Name: Portfile Type: application/octet-stream Size: 1489 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20041221/bb45cf2a/Portfile-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: patch-osx-Makefile.diff Type: application/octet-stream Size: 456 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20041221/bb45cf2a/patch-osx-Makefile-0001.obj From Jack.Jansen at cwi.nl Tue Dec 21 23:14:19 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Tue Dec 21 23:14:35 2004 Subject: [Pythonmac-SIG] Read Strings from Resources In-Reply-To: <5080.1103569592@www22.gmx.net> References: <5080.1103569592@www22.gmx.net> Message-ID: On 20-dec-04, at 20:06, wicked-witch@gmx.net wrote: > I working on a project, where I want to read a STR# resource and write > it > into an xml file. > With Carbon.Res I can easily access the file an read the string > Resources > for each ID. But with the Res.Get1Resource('STR#', id).data I get all > the > strings in the list in one string only. Is there a method in python > like > GetIndSting or something like it? To my surprise there isn't! And nobody ever complained! The problem is that the Carbon modules are generated automatically, and GetIndString is declared in TextUtils.h, not in Resource.h, so it isn't picked up. I've filed a bug report (#1089399), so it'll be fixed, but that's a long term thing (not before 2.5). In the short term you'll have to parse the STR# resource yourself. I'm not 100% sure, but I think they're just a null-byte separated list. If they're something else (a list of Pascal strings?) I'll just hope someone will chime in. -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From erik at letterror.com Tue Dec 21 23:22:58 2004 From: erik at letterror.com (Erik van Blokland) Date: Tue Dec 21 23:23:01 2004 Subject: [Pythonmac-SIG] Installing Twisted-1.3.0 Message-ID: Hi, this question might be more appropriate for a twisted forum. But before I throw myself to the wild animals, perhaps someone on this list has a clue for me. I'm attempting to install Twisted-1.3.0 on a G4 powerbook. I have installed the same version of twisted on a different G4 with OSX Server, and on another machine - plain OSX, all works fine. Now I want to include a 12" powerbook in the happy family, but it won't compile. As far as I can tell the pythons are all the same version, plain Apple 2.3. OSX 10.3.5. Python version: Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Now then, installing Twisted-1.3.0 gives me this error. ~This is the shorter version, without all the copying. It's done that. [eBook:/code/Twisted-1.3.0] erik% sudo python setup.py build running build running build_py running build_ext Checking if C extensions can be compiled, don't be alarmed if a few compile errors are printed. gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I/System/Library/Frameworks/Python.framework/Versions/2.3/include/ python2.3 -c conftest.c -o conftest.o gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I/System/Library/Frameworks/Python.framework/Versions/2.3/include/ python2.3 -c conftest.c -o conftest.o building 'twisted.spread.cBanana' extension gcc -Wl,-F. -Wl,-F. -bundle -framework Python build/temp.darwin-7.7.0-Power_Macintosh-2.3/twisted/spread/cBanana.o -o build/lib.darwin-7.7.0-Power_Macintosh-2.3/twisted/spread/cBanana.so ld: can't locate file for: -lbundle1.o error: command 'gcc' failed with exit status 1 after that twisted imports in python, but not much else -- twisted.web fails. Just for luck I tried the upgrade to 10.3.7 didn't make any difference. Any clues are welcome. Otherwise, merry christmas :) Cheers, Erik From Jack.Jansen at cwi.nl Tue Dec 21 23:23:05 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Tue Dec 21 23:23:15 2004 Subject: [Pythonmac-SIG] Re: Pythonmac-SIG Digest, Vol 20, Issue 24 In-Reply-To: <053079D9-52AE-11D9-B42F-0003939F0DC0@digitalgoods.com> References: <20041220110109.A83531E401C@bag.python.org> <49CB75CC-528B-11D9-B42F-0003939F0DC0@digitalgoods.com> <3CF436E8-52A4-11D9-B42F-0003939F0DC0@digitalgoods.com> <1F770FBE-52A6-11D9-BC8B-000D93AD379E@mac.com> <053079D9-52AE-11D9-B42F-0003939F0DC0@digitalgoods.com> Message-ID: The PythonIDE not starting problem is completely unrelated to your other problems. You've encountered a bug in the IDE (for which I'll add a FAQ entry shortly). If you've set your IDE scripts directory to something containing more than 200-something files the menu building code runs out of menu entries. The fix is to first remove your IDE preferences (~/Library/Preferences/Python/PythonIDE preferences), and then not set your scripts directory to something that has too many files (such as your home directory). On 20-dec-04, at 18:38, Jon Schull wrote: > Now if I double click on "/Applications/MacPython-2.3/PythonIDE.app" > the startup screen appears briefly and disappears. The console gets >> ===== Mon Dec 20 2004 ===== 12:31:36 US/Eastern ===== >> Traceback (most recent call last): >> File >> "/Applications/MacPython-2.3/PythonIDE.app/Contents/Resources/ >> PythonIDE.py", line 59, in ? >> _PythonIDEMain.PythonIDE() >> File >> "/Applications/MacPython-2.3/PythonIDE.app/Contents/Resources/ >> PythonIDEMain.py", line 41, in __init__ >> Wapplication.Application.__init__(self, 'Pide') >> File >> "/System/Library/Frameworks/Python.framework/Versions/2.3/Mac/Tools/ >> IDE/Wapplication.py", line 28, in __init__ >> FrameWork.Application.__init__(self) >> File >> "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ >> python2.3/plat-mac/FrameWork.py", line 115, in __init__ >> self.makemenubar() >> File >> "/System/Library/Frameworks/Python.framework/Versions/2.3/Mac/Tools/ >> IDE/Wapplication.py", line 275, in makemenubar >> self.makeusermenus() >> File >> "/Applications/MacPython-2.3/PythonIDE.app/Contents/Resources/ >> PythonIDEMain.py", line 159, in makeusermenus >> self.makescriptsmenu() >> File >> "/Applications/MacPython-2.3/PythonIDE.app/Contents/Resources/ >> PythonIDEMain.py", line 261, in makescriptsmenu >> self.scriptswalk(fsr.as_pathname(), self.scriptsmenu) >> File >> "/System/Library/Frameworks/Python.framework/Versions/2.3/Mac/Tools/ >> IDE/Wapplication.py", line 309, in scriptswalk >> self.scriptswalk(path, submenu, done) >> File >> "/System/Library/Frameworks/Python.framework/Versions/2.3/Mac/Tools/ >> IDE/Wapplication.py", line 309, in scriptswalk >> self.scriptswalk(path, submenu, done) >> File >> "/System/Library/Frameworks/Python.framework/Versions/2.3/Mac/Tools/ >> IDE/Wapplication.py", line 308, in scriptswalk >> submenu = FrameWork.SubMenu(menu, name) >> File >> "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ >> python2.3/plat-mac/FrameWork.py", line 708, in SubMenu >> return menu.addsubmenu(label, title) >> File >> "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ >> python2.3/plat-mac/FrameWork.py", line 595, in addsubmenu >> sub = Menu(self.bar, title, -1) >> File >> "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ >> python2.3/plat-mac/FrameWork.py", line 545, in __init__ >> self.id, self.menu = self.bar.addmenu(title, after, id) >> File >> "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ >> python2.3/plat-mac/FrameWork.py", line 479, in addmenu >> id = self.getnextid() >> File >> "/System/Library/Frameworks/Python.framework/Versions/2.3/Mac/Tools/ >> IDE/Wapplication.py", line 433, in getnextid >> id = self.possibleIDs[0] >> IndexError: list index out of range -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From bob at redivi.com Tue Dec 21 23:38:18 2004 From: bob at redivi.com (Bob Ippolito) Date: Tue Dec 21 23:38:31 2004 Subject: [Pythonmac-SIG] Installing Twisted-1.3.0 In-Reply-To: References: Message-ID: <02B138C6-53A1-11D9-9505-000A9567635C@redivi.com> On Dec 21, 2004, at 5:22 PM, Erik van Blokland wrote: > this question might be more appropriate for a twisted forum. But > before I throw myself to the wild animals, perhaps someone on this > list has a clue for me. > > I'm attempting to install Twisted-1.3.0 on a G4 powerbook. I have > installed the same version of twisted on a different G4 with OSX > Server, and on another machine - plain OSX, all works fine. Now I want > to include a 12" powerbook in the happy family, but it won't compile. > As far as I can tell the pythons are all the same version, plain Apple > 2.3. OSX 10.3.5. > > Python version: > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > > Now then, installing Twisted-1.3.0 gives me this error. ~This is the > shorter version, without all the copying. It's done that. > > [eBook:/code/Twisted-1.3.0] erik% sudo python setup.py build - > building 'twisted.spread.cBanana' extension > gcc -Wl,-F. -Wl,-F. -bundle -framework Python > build/temp.darwin-7.7.0-Power_Macintosh-2.3/twisted/spread/cBanana.o > -o > build/lib.darwin-7.7.0-Power_Macintosh-2.3/twisted/spread/cBanana.so > ld: can't locate file for: -lbundle1.o > error: command 'gcc' failed with exit status 1 That is quite a strange error, but cBanana is not required nor even enabled by default these days. This is harmless. > after that twisted imports in python, but not much else -- twisted.web > fails. Just for luck I tried the upgrade to 10.3.7 didn't make any > difference. What's much more important to see is *how* twisted.web fails. The cBanana stuff is totally harmless, though it sounds like Xcode might not be installed correctly if you're getting strange compile errors like that? Did you remember to python setup.py install? build won't install anything. FWIW, Twisted should run without ANY C extensions or ANY compilation. You can just point sys.path to /code/Twisted-1.3.0 and it will have a working twisted package. Also, the cfreactor in 1.3.0 is broken for PyObjC 1.1 and later, so maybe you should be trying Twisted 2.0-SVN instead.. -bob From hengist.podd at virgin.net Tue Dec 21 23:42:58 2004 From: hengist.podd at virgin.net (has) Date: Tue Dec 21 23:43:07 2004 Subject: [Pythonmac-SIG] py2app standalone options Message-ID: Chris Barker wrote: >I originally came down on Has' side of this debate, but now think Bob >has made the right choices, so I thought I'd add a couple comments. > >First, I'm a little unclear on what exactly Has wants. Could you clarify? Freedom, basically. It's easier to assemble a workflow by mixing and matching small, single-purpose components than to strip down a great big monolithic lump to get the pieces you want/need. If you're going to protect the end user from doing stupid things, that's great, but it should be done by the next layer up. Users who work at the top layer are protected; users who want/need to route around the 'dummy mode' restrictions can go in at the layer beneath. After all, it's the user's foot, and if they want to shoot holes in it in full knowledge of what they're doing then far be it for anyone or anything else to stand in their way. For example, appscript currently takes this approach. The lower-level aem package provides a comprehensive wrapper around the AEM; appscript builds on this to provide a nice, safe, friendly-looking user interface for application scripting. Most folks'll just use appscript for all their application scripting, but geeks who need access to the full AEM, e.g. to send asynchronous events, can use aem. Prior to 0.6.0 appscript was a monolithic system, which meant you were SOOL if you wanted to do async events, for example - an issue Bob also happened to raise at the time. To give a practical example, let's say I want to write a GUI interface to py2app. My main dialog has some text fields and checkboxes for basic setup info, plus a table view listing all dependencies, allowing users to check/uncheck the items they want/don't want included. The obvious way to implement this would be to call modulegraph to generate the table content, then take the list of checked items and feed it to py2app's package-building function via an 'includeitems' argument. I really don't want or need py2app to run modulegraph a second time just because it's been welded into the basemost layer. If nothing else, a more loosely-coupled architecture takes pressure off the developer to anticipate and support every single possible use to which a user might want/need to put their system and/or its components now or in the future. Hope that makes sense, has -- http://freespace.virgin.net/hamish.sanderson/ From bob at redivi.com Wed Dec 22 00:07:06 2004 From: bob at redivi.com (Bob Ippolito) Date: Wed Dec 22 00:07:17 2004 Subject: [Pythonmac-SIG] py2app standalone options In-Reply-To: References: Message-ID: <08EC64E9-53A5-11D9-9505-000A9567635C@redivi.com> On Dec 21, 2004, at 5:42 PM, has wrote: > Chris Barker wrote: > >> I originally came down on Has' side of this debate, but now think Bob >> has made the right choices, so I thought I'd add a couple comments. >> >> First, I'm a little unclear on what exactly Has wants. Could you >> clarify? > > Freedom, basically. It's easier to assemble a workflow by mixing and > matching small, single-purpose components than to strip down a great > big monolithic lump to get the pieces you want/need. If you're going > to protect the end user from doing stupid things, that's great, but it > should be done by the next layer up. Users who work at the top layer > are protected; users who want/need to route around the 'dummy mode' > restrictions can go in at the layer beneath. After all, it's the > user's foot, and if they want to shoot holes in it in full knowledge > of what they're doing then far be it for anyone or anything else to > stand in their way. > > For example, appscript currently takes this approach. The lower-level > aem package provides a comprehensive wrapper around the AEM; appscript > builds on this to provide a nice, safe, friendly-looking user > interface for application scripting. Most folks'll just use appscript > for all their application scripting, but geeks who need access to the > full AEM, e.g. to send asynchronous events, can use aem. Prior to > 0.6.0 appscript was a monolithic system, which meant you were SOOL if > you wanted to do async events, for example - an issue Bob also > happened to raise at the time. The lower levels at this point, similar to appscript / aem are py2app.create_appbundle / modulegraph.find_modules / macholib.MachOGraph. You can do all the foot shooting you want with them! > To give a practical example, let's say I want to write a GUI interface > to py2app. My main dialog has some text fields and checkboxes for > basic setup info, plus a table view listing all dependencies, allowing > users to check/uncheck the items they want/don't want included. The > obvious way to implement this would be to call modulegraph to generate > the table content, then take the list of checked items and feed it to > py2app's package-building function via an 'includeitems' argument. I > really don't want or need py2app to run modulegraph a second time just > because it's been welded into the basemost layer. That's sort of a backwards way to get at it.. given a proper refactoring of py2app, the "dependency finding" and "application building" would simply be split into two separate build phases (which means two command classes and a mess of additional code), so you'd run the dependency resolution phase, manipulate the py2app instance, and then run the build application phase. This is not currently the case, because py2app._run does both. For 0.1.7 I'll at least split this up into more pieces, so it has more useful hooks for subclasses. > If nothing else, a more loosely-coupled architecture takes pressure > off the developer to anticipate and support every single possible use > to which a user might want/need to put their system and/or its > components now or in the future. Distutils is the antithesis of loosely-coupled architecture. py2app is slowly being split apart into orthogonal components, but this flexibility would add a lot of complexity that I don't want to deal with at this point. -bob From Jack.Jansen at cwi.nl Wed Dec 22 00:13:05 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Wed Dec 22 00:13:15 2004 Subject: [Pythonmac-SIG] Installing Twisted-1.3.0 In-Reply-To: <02B138C6-53A1-11D9-9505-000A9567635C@redivi.com> References: <02B138C6-53A1-11D9-9505-000A9567635C@redivi.com> Message-ID: On 21-dec-04, at 23:38, Bob Ippolito wrote: >> building 'twisted.spread.cBanana' extension >> gcc -Wl,-F. -Wl,-F. -bundle -framework Python >> build/temp.darwin-7.7.0-Power_Macintosh-2.3/twisted/spread/cBanana.o >> -o >> build/lib.darwin-7.7.0-Power_Macintosh-2.3/twisted/spread/cBanana.so >> ld: can't locate file for: -lbundle1.o >> error: command 'gcc' failed with exit status 1 > > That is quite a strange error, but cBanana is not required nor even > enabled by default these days. This is harmless. Well, as you say, it could point to a problem with the Xcode/gcc installation. It appears as if the "-Wl,-F. -Wl,-F. -bundle" options don't get passed correctly to the linker. "-Wl,-F." means: please pass "-F." to the linker. But it appears as if it is somehow combined in a funny way with the following "-bundle" option. If gcc is funny this could well affect other command lines as well. Check that gcc is indeed Apple's gcc, and not something else. -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From dave.opstad at monotypeimaging.com Wed Dec 22 00:22:11 2004 From: dave.opstad at monotypeimaging.com (Opstad, Dave) Date: Wed Dec 22 00:22:10 2004 Subject: [Pythonmac-SIG] Read Strings from Resources Message-ID: > I've filed a bug report (#1089399), so it'll be fixed, but that's a > long term thing (not before 2.5). In the short term you'll have to > parse the STR# resource yourself. I'm not 100% sure, but I think > they're just a null-byte separated list. If they're something else (a > list of Pascal strings?) I'll just hope someone will chime in. According to MacTypes.r (in the last Universal Headers revision), the Rez format for a 'STR#' resource is as follows: -------------------- type 'STR#' { integer = $$Countof(StringArray); array StringArray { pstring; /* String */ }; }; -------------------- So it looks like a 2-byte count followed by an array of Pascal strings. Dave Opstad From charles.hartman at conncoll.edu Wed Dec 22 00:57:32 2004 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Wed Dec 22 00:57:37 2004 Subject: [Pythonmac-SIG] Where to put data In-Reply-To: <722C24F8-538F-11D9-9505-000A9567635C@redivi.com> References: <3479352C-5364-11D9-9C37-000D933C27EA@conncoll.edu> <722C24F8-538F-11D9-9505-000A9567635C@redivi.com> Message-ID: <144C70B8-53AC-11D9-8A1E-000D933C27EA@conncoll.edu> OK, all this makes sense. But I'm startled to see how incredibly gnarly it is to have any kind of data -- if you want to preserve changes in the data, say by having a dictionary grow from one program run to the next -- at least on more than one platform. Is this so uncommon a pattern for applications? Oh well. Charles Hartman "Creative paranoia means developing at least as thorough a We-system as a They-system." Pynchon, Gravity's Rainbow, p. 638. On Dec 21, 2004, at 3:32 PM, Bob Ippolito wrote: > On Dec 21, 2004, at 10:23 AM, Charles Hartman wrote: > >> (I also posted this to wxusers because it's sort of cross-platform -- >> sorry if you're seeing it again.) >> >> With an earlier app I wanted an external data file and everybody told >> me to make it internal to the program (the app's Resources, I guess) >> instead. I couldn't, then. Now with a new app I want to do just that, >> but I'm not sure *how* to do it! >> >> It's a file of data -- a Python dictionary object, after it's loaded >> into memory -- which will grow and change as the app is used; when >> the app terminates the data ought to be saved with it for next time. >> In this case I don't want users fiddling with it apart from the app. >> >> What is the right way to do this? (What's the easy way?) Is there a >> simple method that will work for both Mac and Windows (and Linux)? > > The right way to do it is NOT to have this file inside your > application. You should *never* assume that you can write to your own > application bundle. You *should* have a way to create this file from > scratch (which may be a template file inside Resources, which is never > written to). > > As others have said there are different places you should put this > file dependent on operating system.. > > On Mac OS X it should probably go in one of the "Application Support" > directories. It's common convention to only place plist formatted > files in the Preferences directory, so unless you're serializing this > dictionary as a plist, I suggest going with Application Support > instead of Preferences. > > On other *nix, it would typically go into a ~/.yourapplication > directory. > > And for Windows, somewhere in their home directory (at least on > NT-based Windows). Optionally, you could put it in the registry > instead, which may be a good idea, depending on how big it is expected > to get. > > As far as writing to your own application goes, here's a short list of > why that's bad: > - Will not work from CD-ROM, compressed disk image, etc. > - Probably will not work multi-user > - Probably a bad idea if the application is on a network drive > - User may not have permissions to write to the application > - If you break it, you really broke it. > - It can look virus-like and be picked up as such (particularly on > Win32 if you're writing to the .exe file). > > You should be able to trust the user not to fiddle with it apart from > the app. Especially if it's a pickle file. It will be pretty buried, > anyway. > > -bob > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 3041 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20041221/a588e89a/attachment.bin From 0x62_0x6c_0x62 at pobox.com Wed Dec 22 01:23:45 2004 From: 0x62_0x6c_0x62 at pobox.com (Bryan Blackburn) Date: Wed Dec 22 01:25:01 2004 Subject: [Pythonmac-SIG] Installing Twisted-1.3.0 In-Reply-To: References: <02B138C6-53A1-11D9-9505-000A9567635C@redivi.com> Message-ID: On Dec 21, 2004, at 4:13 PM, Jack Jansen wrote: > > On 21-dec-04, at 23:38, Bob Ippolito wrote: >>> building 'twisted.spread.cBanana' extension >>> gcc -Wl,-F. -Wl,-F. -bundle -framework Python >>> build/temp.darwin-7.7.0-Power_Macintosh-2.3/twisted/spread/cBanana.o >>> -o >>> build/lib.darwin-7.7.0-Power_Macintosh-2.3/twisted/spread/cBanana.so >>> ld: can't locate file for: -lbundle1.o >>> error: command 'gcc' failed with exit status 1 >> >> That is quite a strange error, but cBanana is not required nor even >> enabled by default these days. This is harmless. > > Well, as you say, it could point to a problem with the Xcode/gcc > installation. It appears as if the "-Wl,-F. -Wl,-F. -bundle" options > don't get passed correctly to the linker. "-Wl,-F." means: please pass > "-F." to the linker. But it appears as if it is somehow combined in a > funny way with the following "-bundle" option. If gcc is funny this > could well affect other command lines as well. > > Check that gcc is indeed Apple's gcc, and not something else. bundle1.o should be installed in /usr/lib, by the DevSDK package; if that package is installed, it should probably be reinstalled (or, to be safe, all Dev packages probably should be). Otherwise, DevSDK is needed... Bryan > -- > Jack Jansen, , http://www.cwi.nl/~jack > If I can't dance I don't want to be part of your revolution -- Emma > Goldman > From bob at redivi.com Wed Dec 22 01:45:23 2004 From: bob at redivi.com (Bob Ippolito) Date: Wed Dec 22 01:45:30 2004 Subject: [Pythonmac-SIG] Where to put data In-Reply-To: <144C70B8-53AC-11D9-8A1E-000D933C27EA@conncoll.edu> References: <3479352C-5364-11D9-9C37-000D933C27EA@conncoll.edu> <722C24F8-538F-11D9-9505-000A9567635C@redivi.com> <144C70B8-53AC-11D9-8A1E-000D933C27EA@conncoll.edu> Message-ID: On Dec 21, 2004, at 6:57 PM, Charles Hartman wrote: > On Dec 21, 2004, at 3:32 PM, Bob Ippolito wrote: > >> On Dec 21, 2004, at 10:23 AM, Charles Hartman wrote: >> >>> (I also posted this to wxusers because it's sort of cross-platform >>> -- sorry if you're seeing it again.) >>> >>> With an earlier app I wanted an external data file and everybody >>> told me to make it internal to the program (the app's Resources, I >>> guess) instead. I couldn't, then. Now with a new app I want to do >>> just that, but I'm not sure *how* to do it! >>> >>> It's a file of data -- a Python dictionary object, after it's loaded >>> into memory -- which will grow and change as the app is used; when >>> the app terminates the data ought to be saved with it for next >>> time. In this case I don't want users fiddling with it apart from >>> the app. >>> >>> What is the right way to do this? (What's the easy way?) Is there a >>> simple method that will work for both Mac and Windows (and Linux)? >> >> The right way to do it is NOT to have this file inside your >> application. You should *never* assume that you can write to your >> own application bundle. You *should* have a way to create this file >> from scratch (which may be a template file inside Resources, which is >> never written to). >> >> As others have said there are different places you should put this >> file dependent on operating system.. >> >> On Mac OS X it should probably go in one of the "Application Support" >> directories. It's common convention to only place plist formatted >> files in the Preferences directory, so unless you're serializing this >> dictionary as a plist, I suggest going with Application Support >> instead of Preferences. >> >> On other *nix, it would typically go into a ~/.yourapplication >> directory. >> >> And for Windows, somewhere in their home directory (at least on >> NT-based Windows). Optionally, you could put it in the registry >> instead, which may be a good idea, depending on how big it is >> expected to get. >> >> As far as writing to your own application goes, here's a short list >> of why that's bad: >> - Will not work from CD-ROM, compressed disk image, etc. >> - Probably will not work multi-user >> - Probably a bad idea if the application is on a network drive >> - User may not have permissions to write to the application >> - If you break it, you really broke it. >> - It can look virus-like and be picked up as such (particularly on >> Win32 if you're writing to the .exe file). >> >> You should be able to trust the user not to fiddle with it apart from >> the app. Especially if it's a pickle file. It will be pretty >> buried, anyway. >> > OK, all this makes sense. But I'm startled to see how incredibly > gnarly it is to have any kind of data -- if you want to preserve > changes in the data, say by having a dictionary grow from one program > run to the next -- at least on more than one platform. Is this so > uncommon a pattern for applications? Oh well. You make it sound much harder than it is. Yes, for the three major platforms, there are three different canonical ways. win32: registry is easy, especially using something like this: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/174627 OS X: NSUserDefaults is painless via PyObjC: http://developer.apple.com/documentation/Cocoa/Reference/Foundation/ ObjC_classic/Classes/NSUserDefaults.html posix: otherwise, roll your own: appdir = os.path.expanduser("~/.myapplication"); if not os.path.exists(appdir): os.makedirs(appdir); .... You could more or less use the dot directory method for all three platforms if you were a cross-platform purist, it should work, at least for NT-based windows. There's probably an abstraction for this somewhere. -bob From jkrushen at gmail.com Wed Dec 22 03:36:39 2004 From: jkrushen at gmail.com (Jordan Krushen) Date: Wed Dec 22 03:36:48 2004 Subject: [Pythonmac-SIG] py2app standalone options In-Reply-To: References: <9C444D88-4F99-11D9-B499-000A9567635C@redivi.com> <67952862-4F9C-11D9-B499-000A9567635C@redivi.com> <5983E128-4FBA-11D9-A3DC-000A9567635C@redivi.com> <41C348CB.9020601@noaa.gov> Message-ID: On Fri, 17 Dec 2004 17:20:01 -0500, Bob Ippolito wrote: > py2app tries very hard, by default, to make the Python environment > consistent regardless of what the end user has done to their system. > This includes stomping on any PYTHONPATH and ignoring any site-packages > that the user has. Due to this, the developer, on their development > machine, can be reasonably certain that their application will run > anywhere (for a reasonable expectation of anywhere) if it runs at all. > So if modulegraph DID miss something, then the developer will know > about it before he even tries running the application on another > machine. > > Maybe I am doing a little too much forced-hand-holding and insulting > the developer's intelligence a bit, but given the issues that I've seen > with similar solutions (particularly py2exe and bundlebuilder) and the > general lack of "appreciation" for the myriad of subtle ways you can > bork a Python installation on the Mac, I think this is the right > solution. Being a long-time BSD user and after using OS X for a couple years, I can vouch for the fact that installing another version of Python, after even a couple weeks of lurking on any of these lists, is a scary notion when you start to care about deployment. It feels like a large proportion of posts here are about that very problem. > If you don't want an application packager that does the right thing > more often than not, feel free to use bundlebuilder. If you want a > feature in py2app that I don't want to implement, you're going to have > to implement it yourself, make an astoundingly good case for it and > change my mind, or attempt to bribe me :) I perform a public service, > but I'm not a public servant! After I eventually discovered how py2app does plugins, due primarily to your help, I can state that I'm quite pleased! I now have a suitably distinct boundary (at least in my mind) between ObjC views and controllers and Python models, which suits this particular workflow nicely. Just wanted to let you guys know that your work is both appreciated and impressive. J. From ewestra at gmail.com Wed Dec 22 04:29:41 2004 From: ewestra at gmail.com (Erik Westra) Date: Wed Dec 22 04:30:33 2004 Subject: [Pythonmac-SIG] py2app Enforces Directory Structure? Message-ID: <3c5e36f404122119295bdc9c7a@mail.gmail.com> Greetings, Pythonmac folks! I was wondering if someone could help me with a problem I'm having with py2app. I'm in the process of converting a large wxPython application written for MS Windows to run on the Mac. The application itself now works, and I'm at the stage of trying to bundle it up using py2app for distribution. Unfortunately, it seems that the application's directory structure is causing problems for py2app, and after two days of mucking about I still can't get it working. The application has the following overall directory structure: app/ build/ setup.py build-exe.bat ... framework/ Framework.py main.py data/ ... There are other top-level directories as well, but these are the important ones. As you can see the "main.py" file is in the "framework" sub-directory, and the application accesses its data files using relative paths like "../data/file.dat". All temporary files, scripts, etc, which are used to build standalone versions of the system are placed into the "build" sub-directory. This works well under MS Windows, both for the standalone system and when its running in source-code form, and also works fine on the Mac when running the source directory -- but I haven't been able to get py2app to build this application at all. It seems that py2app requires that the main.py file and the setup.py file are both stired in the top-most directory for the application, with other files/modules/packages in sub-directories beneath that topmost directory. Is this really the case? If so, it seems like a rather major limitation -- surely there must be lots of applications that put all their build-related files into a separate sub-directory, quite separate from the application's main source files. Because I need to be able to share one common set of source code across multiple platforms, I don't have much choice in terms of altering this directory structure -- somehow, I need to get py2app to build a standalone Mac application which includes the "Framework.py" and "main.py" modules, runs main.py on startup, and stores setup.py and all temporary files inside the "build" directory. I don't need to include anything else in the application, as the system will store the contents of the "data" and other directories outside of the application bundle itself. Here's my attempt at creating a "setup.py" file: from distutils.core import setup import py2app setup( app = ["main.py"], options={'py2app' : {'bdist_base' : "../build/build", 'dist_dir' : "../build/dist", 'includes' : "Framework"}} ) This setup script is stored in the "build" sub-directory, and I access it by typing: cd framework python ../build/setup.py py2app This works in terms of creating a standalone wxPython app that includes the "main.py" file, but the "Framework.py" file isn't included, and the app fails at the "import Framework" statement within "main.py". The only other idea I can think of would be to create aliases to the "main.py" and "Framework.py" files, put the aliases into the "build" directory, and treat the entire system as if it all resided in a single directory. But there must be a better solution than that! What I really need, I guess, is a way of specifying the source directory in which the modules in the "includes" list will be found. There doesn't seem to be any such option, though, and including a relative pathname in the "includes" list just generates an error when I try to build the app. Any suggestions? Thanks, - Erik. From bob at redivi.com Wed Dec 22 05:18:29 2004 From: bob at redivi.com (Bob Ippolito) Date: Wed Dec 22 05:18:36 2004 Subject: [Pythonmac-SIG] py2app Enforces Directory Structure? In-Reply-To: <3c5e36f404122119295bdc9c7a@mail.gmail.com> References: <3c5e36f404122119295bdc9c7a@mail.gmail.com> Message-ID: <88C6D811-53D0-11D9-B5D4-000A9567635C@redivi.com> On Dec 21, 2004, at 10:29 PM, Erik Westra wrote: > I'm in the process of converting a large wxPython application written > for MS Windows to run on the Mac. The application itself now works, > and I'm at the stage of trying to bundle it up using py2app for > distribution. Unfortunately, it seems that the application's > directory structure is causing problems for py2app, and after two days > of mucking about I still can't get it working. You should've asked sooner. Software that doesn't have [much] documentation probably means the developer[s] are still working on things and there may be a rough edge or two :) > The application has the following overall directory structure: > > app/ > > build/ > setup.py > build-exe.bat > ... > > framework/ > Framework.py > main.py > > data/ > ... > > There are other top-level directories as well, but these are the > important ones. As you can see the "main.py" file is in the > "framework" sub-directory, and the application accesses its data files > using relative paths like "../data/file.dat". All temporary files, > scripts, etc, which are used to build standalone versions of the > system are placed into the "build" sub-directory. "build" sure is a dangerous name to use, considering that it's typically the name of a scratch directory in Python terms. > This works well under MS Windows, both for the standalone system and > when its running in source-code form, and also works fine on the Mac > when running the source directory -- but I haven't been able to get > py2app to build this application at all. You're going to need to change those paths to "data/file.dat". The data will be inside of your application bundle in the Resources folder, which will be the current directory on startup. > It seems that py2app requires that the main.py file and the setup.py > file are both stired in the top-most directory for the application, > with other files/modules/packages in sub-directories beneath that > topmost directory. Is this really the case? If so, it seems like a > rather major limitation -- surely there must be lots of applications > that put all their build-related files into a separate sub-directory, > quite separate from the application's main source files. setup.py assumes that it can find all of the dependencies via normal import mechanisms. If you want it to work in your situation, you will have to add your "frameworks" directory to sys.path before setup(...) - see below. This sys.path modification will no longer be necessary as of py2app 0.1.7 (fixed in svn r268). > Because I need to be able to share one common set of source code > across multiple platforms, I don't have much choice in terms of > altering this directory structure -- somehow, I need to get py2app to > build a standalone Mac application which includes the "Framework.py" > and "main.py" modules, runs main.py on startup, and stores setup.py > and all temporary files inside the "build" directory. I don't need to > include anything else in the application, as the system will store the > contents of the "data" and other directories outside of the > application bundle itself. Don't do that. That's bad. Include the data and any other dependencies inside the application. Having them external and using an installer is not the Mac way to do things and I'm not going to help you do it. There was a similar discussion a while ago (weeks?) and I'm not going to have it again, so search the archives and argue with the past if you feel strongly in the other direction :) > Here's my attempt at creating a "setup.py" file: > > from distutils.core import setup > import py2app > > setup( > app = ["main.py"], > options={'py2app' : > {'bdist_base' : "../build/build", > 'dist_dir' : "../build/dist", > 'includes' : "Framework"}} > ) > > This setup script is stored in the "build" sub-directory, and I access > it by typing: > > cd framework > python ../build/setup.py py2app > > This works in terms of creating a standalone wxPython app that > includes the "main.py" file, but the "Framework.py" file isn't > included, and the app fails at the "import Framework" statement within > "main.py". That's because py2app 0.1.6 didn't automatically know to look to siblings of the scripts for additional modules. It does now. > The only other idea I can think of would be to create aliases to the > "main.py" and "Framework.py" files, put the aliases into the "build" > directory, and treat the entire system as if it all resided in a > single directory. But there must be a better solution than that! Of course there is :) > What I really need, I guess, is a way of specifying the source > directory in which the modules in the "includes" list will be found. > There doesn't seem to be any such option, though, and including a > relative pathname in the "includes" list just generates an error when > I try to build the app. The includes and excludes lists are Python module identifiers, not path names. Using a relative path name, anything that has a slash in it, or anything that starts with a dot or has more than one dot in succession, is of course an error because those are invalid Python module identifiers. ---- from distutils.core import setup import py2app import sys # no longer necessary in 0.1.7 sys.path.insert(0, '../framework') setup( app = ["../framework/main.py"], data_files = ['../data'], ) % cd build % python setup.py py2app If you check out py2app trunk (as of revision 268), then the sys.path.insert(0, '../framework') is no longer necessary, and there is an example that demonstrates the given use case (minus the bad form of having external data files). -bob From ewestra at gmail.com Wed Dec 22 05:39:50 2004 From: ewestra at gmail.com (Erik Westra) Date: Wed Dec 22 05:43:28 2004 Subject: [Pythonmac-SIG] py2app Enforces Directory Structure? In-Reply-To: <88C6D811-53D0-11D9-B5D4-000A9567635C@redivi.com> References: <3c5e36f404122119295bdc9c7a@mail.gmail.com> <88C6D811-53D0-11D9-B5D4-000A9567635C@redivi.com> Message-ID: <3c5e36f4041221203939d7111e@mail.gmail.com> Hi Bob, Wow -- that was fast! > "build" sure is a dangerous name to use, considering that it's > typically the name of a scratch directory in Python terms. Thanks...I wasn't aware of that. > setup.py assumes that it can find all of the dependencies via normal > import mechanisms. If you want it to work in your situation, you will > have to add your "frameworks" directory to sys.path before setup(...) - > see below. This sys.path modification will no longer be necessary as > of py2app 0.1.7 (fixed in svn r268). Brilliant! I was hoping there might be some way of getting this working... > > I don't need to > > include anything else in the application, as the system will store the > > contents of the "data" and other directories outside of the > > application bundle itself. > > Don't do that. That's bad. Include the data and any other > dependencies inside the application. Having them external and using an > installer is not the Mac way to do things and I'm not going to help you > do it. There was a similar discussion a while ago (weeks?) and I'm not > going to have it again, so search the archives and argue with the past > if you feel strongly in the other direction :) I agree that this isn't something worth arguing about (and I wouldn't expect you to help me do it, either!), but I just have one comment on this issue: in the system I'm porting to the Mac, the "data" might consist of 300+ megabytes of information held in an embedded SQLite database, along with hundreds of configuration files and dynamically-loaded Python modules (downloaded automatically from a web site as they are required). Our system is pretty darned complicated, and while I agree that it's not the Mac way of doing things, the architecture works well and our users really don't care much about the internal organisation. This isn't an application designed for mass distribution, so issues like this really aren't all that important to us. Anyway, topic closed. I certainly don't want to get into an argument about this... > from distutils.core import setup > import py2app > import sys > # no longer necessary in 0.1.7 > sys.path.insert(0, '../framework') > setup( > app = ["../framework/main.py"], > data_files = ['../data'], > ) > > % cd build > % python setup.py py2app > > If you check out py2app trunk > (as of revision 268), then > the sys.path.insert(0, '../framework') is no longer necessary, and > there is an example > setup.py> that demonstrates the given use case (minus the bad form of > having external data files). Thanks for the great (and speedy) help! - Erik. From sw at wordtech-software.com Wed Dec 22 05:54:59 2004 From: sw at wordtech-software.com (Kevin Walzer) Date: Wed Dec 22 05:55:04 2004 Subject: [Pythonmac-SIG] Tkinter and Python 2.2 Message-ID: <41C8FE23.40005@wordtech-software.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andrew, I'm cross-posting this to the MacPython list because a lot of your questions are relevant there. The Mac/Tkinter bindings are maintained by the MacPython developers, not the TkAqua maintainers, although they require the TkAqua libraries. Can any of the core MacPython developers take a look at this thread and give us the Pythonic viewpoint on these questions? (hooking TkAqua and Tkinter into an old version of Python for the Mac with undocumented, proprietary modifications: what issues should he consider?) - ----- I use Poser 5 for OS X which originally came out for PC in 2002 or so, bundled with a modified Python that has hooks to Poser's undocumented API (for getting and setting variables inside the Poser environment). The Python functionality was part of a previous interim version from the days of OS 9 (Poser Pro Pack was developed in the fall of 2000). Unfortunately when they finally released the OS X version last year, it came bundled with the same version of Python instead of hooking to OS X's instance. PoserPython's exact source version is unknown right now but presumably around 2.0 since it looks like the programmers have been afraid to update it since its inclusion in late 2000. Many Python scripts for Poser are starting to rely on TkInter... argh. Assume I can get the engineers at Curious Labs to tell me what version of Python PoserPython is based off. Also assume the modifications aren't too grisly. If I have the source code for TkAqua, can it be modified and recompiled as a separate binary for PoserPython? [I'm guessing this is preferable to trying to get one instance of TkAqua to work for both instances of Python] Does it make any difference if I don't have any other instances of TkAqua on my system? Message: 1 Date: Tue, 21 Dec 2004 09:24:14 -0800 From: Jeff Hobbs Organization: ActiveState Corporation To: "Daniel A. Steffen" CC: Andrew Roazen , tcl-mac@lists.sourceforge.net Subject: Re: [MACTCL] Tk porting/backporting question Daniel A. Steffen wrote: |> I don't think there are many people here with experience of Tkinter |> internals of the level required to answer your question, it might be |> better to ask on a python list... Errr ... you'd be surprised with what some of us have experience with. ;) |> On 18/12/2004, at 6:49, Andrew Roazen wrote: |> | |>>> what's the most feasible path to a substitute for Tkinter to work with |>>> this modified Python 2.2? |>>> |>>> If it's the best solution, what are the issues backporting TkAqua to |>>> Python 2.2? Is the binary portable enough as-is to be dropped into the |>>> Poser Python library as a replacement? The basic answer to your question is that it depends on whether the Tkinter python code has any 2.3-isms in it. While possible, I don't think that it's likely. That means it should be pretty easy to drop into 2.2. From the TkAqua side, it should all just work. Martin v Loewis (loewis at sf dot net) would be a good person to verify if the recent Tkinter has any 2.3-isms. As for binary drop-in replacement ... other dynamic languages don't have the advantages of stubs and such, so you get down to the C level of binary portability. It all depends on what C structures and functions might have changed. In general though, I would not consider that part drop in - you should recompile the C component of Tkinter for 2.2. - -- Jeff Hobbs, The Tcl Guy http://www.ActiveState.com/, a division of Sophos --__--__-- Message: 2 Date: Tue, 21 Dec 2004 09:47:56 -0800 From: Jeff Hobbs Organization: ActiveState Corporation To: Andrew Roazen CC: "Daniel A. Steffen" , tcl-mac@lists.sourceforge.net Subject: Re: [MACTCL] Tk porting/backporting question Andrew Roazen wrote: |> At 07:55 PM 12/21/2004 +1100, Daniel A. Steffen wrote: | |>>>>> If it's the best solution, what are the issues backporting TkAqua to |>>>>> Python 2.2? Is the binary portable enough as-is to be dropped into |>>>>> the Poser Python library as a replacement? | |> |> Okay, let me put the question another way before I take it to the |> appropriate Python list. Is TkAqua an application, a library, or |> something else? ~ From the point of view of Python/Tkinter, TkAqua is a library. Tkinter has a small C shim that links against the Tcl/Tk libraries. When you import Tkinter, it loads Tcl/Tk and wham-o ... instant UIs. - -- Jeff Hobbs, The Tcl Guy http://www.ActiveState.com/, a division of Sophos --__--__-- Message: 3 Date: Tue, 21 Dec 2004 11:20:39 -0700 From: Andrew Roazen Subject: Re: [MACTCL] Tk porting/backporting question To: Jeff Hobbs , "Daniel A. Steffen" Cc: tcl-mac@lists.sourceforge.net - --Boundary_(ID_uRanME8mWzgDC7vxf4omSw) Content-type: text/plain; charset=us-ascii; format=flowed At 09:24 AM 12/21/2004 -0800, Jeff Hobbs wrote: |>>>On 18/12/2004, at 6:49, Andrew Roazen wrote: |> |>>>>>what's the most feasible path to a substitute for Tkinter to work with |>>>>>this modified Python 2.2? |>>>>> |>>>>>If it's the best solution, what are the issues backporting TkAqua to |>>>>>Python 2.2? Is the binary portable enough as-is to be dropped into the |>>>>>Poser Python library as a replacement? | |> |>The basic answer to your question is that it depends on whether the |>Tkinter python code has any 2.3-isms in it. By "Tkinter python code" you mean PoserPython scripts, or code within the Tkinter-Python glue? Assuming you meant the former, if PoserPython is a slightly modified 2.2, I doubt the scripts have 2.3-isms. |>While possible, I don't think that it's likely. That means it should be |>pretty easy to drop into 2.2. Clue this poor newbie in a little more as to what this means in terms of actually placing (and replacing) files in Poser's Python library (which appears to be structured fairly normally). |> From the TkAqua side, it should all just work. Martin v Loewis (loewis |> at sf dot net) would be a good person to verify if the recent Tkinter has |> any 2.3-isms. Confused here... I thought TkAqua was a replacement for Tkinter. |>As for binary drop-in replacement ... other dynamic languages don't have |>the advantages of stubs and such, so you get down to the C level of binary |>portability. It all depends on what C structures and functions might have |>changed. In general though, I would not consider that part drop in - you |>should recompile the C component of Tkinter for 2.2. Clue me again -- Tkinter appears to be a self-contained library (in Windows, at least). Is TkAqua not a replacement for Tkinter but another layer on top of it/library? - ---------- | Andrew Roazen, Web Development Specialist | Cline Library, Northern Arizona University |  928.523.6764 vCard The opinions expressed are those of the guy who sits at this desk, not his employers. - --__--__-- Message: 4 Cc: Jeff Hobbs , ~ "Daniel A. Steffen" , ~ tcl-mac@lists.sourceforge.net From: Jim Ingham Subject: Re: [MACTCL] Tk porting/backporting question Date: Tue, 21 Dec 2004 11:19:18 -0800 To: Andrew Roazen TkInter is a shared library that links to the Tcl & Tk shared libraries. It is loaded into the Python interpreter, and provides a shim that python can use to create and manipulate the Windows, buttons, etc that the Tcl/Tk shared libraries provide. TkAqua is the name for the distribution of Tcl & Tk on Mac OS X that uses the Aqua Toolkit. It includes the Tcl & Tk shared libraries (as well as the Wish Shell.app and some other bits). So you have to build a version of the TkInter shared library that uses the Tcl & Tk shared libraries that come with TkAqua. Jim On Dec 21, 2004, at 10:20 AM, Andrew Roazen wrote: |> At 09:24 AM 12/21/2004 -0800, Jeff Hobbs wrote: |> On 18/12/2004, at 6:49, Andrew Roazen wrote: |> what's the most feasible path to a substitute for Tkinter to work with |> this modified Python 2.2? |> |> If it's the best solution, what are the issues backporting TkAqua to |> Python 2.2? Is the binary portable enough as-is to be dropped into the |> Poser Python library as a replacement? |> |> The basic answer to your question is that it depends on whether the |> Tkinter python code has any 2.3-isms in it. |> |> By "Tkinter python code" you mean PoserPython scripts, or code within |> the Tkinter-Python glue? Assuming you meant the former, if PoserPython |> is a slightly modified 2.2, I doubt the scripts have 2.3-isms. |> |> While possible, I don't think that it's likely. That means it should |> be pretty easy to drop into 2.2. |> |> Clue this poor newbie in a little more as to what this means in terms |> of actually placing (and replacing) files in Poser's Python library |> (which appears to be structured fairly normally). |> |> From the TkAqua side, it should all just work. Martin v Loewis |> (loewis at sf dot net) would be a good person to verify if the recent |> Tkinter has any 2.3-isms. |> |> Confused here... I thought TkAqua was a replacement for Tkinter. |> |> As for binary drop-in replacement ... other dynamic languages don't |> have the advantages of stubs and such, so you get down to the C level |> of binary portability. It all depends on what C structures and |> functions might have changed. In general though, I would not consider |> that part drop in - you should recompile the C component of Tkinter |> for 2.2. |> |> Clue me again -- Tkinter appears to be a self-contained library (in |> Windows, at least). Is TkAqua not a replacement for Tkinter but |> another layer on top of it/library? |> Andrew Roazen, Web Development Specialist | Cline Library, Northern |> Arizona University | $B,6(B 928.523.6764 vCard |> |> The opinions expressed are those of the guy who sits at this desk, not |> his employers. - --__--__-- Message: 5 From: "Jeff Hobbs" To: "'Andrew Roazen'" , ~ "'Daniel A. Steffen'" Cc: Subject: RE: [MACTCL] Tk porting/backporting question Date: Tue, 21 Dec 2004 11:26:39 -0800 Organization: ActiveState Andrew Roazen wrote: |>>> The basic answer to your question is that it depends on |>>> whether the Tkinter python code has any 2.3-isms in it. | |> |> By "Tkinter python code" you mean PoserPython scripts, or |> code within the Tkinter-Python glue? Assuming you meant I meant the Tkinter-Python glue. The C part is rather thin, but there is a lot of python code on top as they have their own megawidget system and such (pmw). Parts of this may have 2.3-isms, as that included enhancements to the object system, which may well be nice to use in a megwidget system. The $PYTHON\Lib\lib-tk has a few 100KB of py code (that's the Windows installed path ... unix is a bit different). |>>> While possible, I don't think that it's likely. That means |>>> it should be pretty easy to drop into 2.2. |> Clue this poor newbie in a little more as to what this means |> in terms of actually placing (and replacing) files in Poser's |> Python library (which appears to be structured fairly normally). Just drop in the relevant bits and pray it works. If you do "find /path/to/python -name '*inter*'", that should reveal the important Tkinter directories. |> Confused here... I thought TkAqua was a replacement for Tkinter. No, TkAqua is just Tk for the native Aqua toolkit (as opposed to Tk for OS X/X, which was the original). Tkinter is just the python binding to Tcl/Tk to create Tk UIs. |> Clue me again -- Tkinter appears to be a self-contained library |> (in Windows, at least). Is TkAqua not a replacement for Tkinter |> but another layer on top of it/library? Er, that's not correct. What they are doing is just copying in the relevant Tcl/Tk code to make it work for them. Jeff - -- Cheers, Kevin Walzer, PhD WordTech Software--Open Source Applications and Packages for OS X http://www.wordtech-software.com http://www.smallbizmac.com http://www.kevin-walzer.com mailto:sw@wordtech-software.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFByP4iJmdQs+6YVcoRAjmaAJ0cy8HKvj7GypdOpqiBfacrRXIeBACdHDKe ALlCWdfKpx+i4JJkggD4eds= =Ctot -----END PGP SIGNATURE----- From bob at redivi.com Wed Dec 22 06:20:33 2004 From: bob at redivi.com (Bob Ippolito) Date: Wed Dec 22 06:20:42 2004 Subject: [Pythonmac-SIG] py2app Enforces Directory Structure? In-Reply-To: <3c5e36f4041221203939d7111e@mail.gmail.com> References: <3c5e36f404122119295bdc9c7a@mail.gmail.com> <88C6D811-53D0-11D9-B5D4-000A9567635C@redivi.com> <3c5e36f4041221203939d7111e@mail.gmail.com> Message-ID: <3453C996-53D9-11D9-B5D4-000A9567635C@redivi.com> On Dec 21, 2004, at 11:39 PM, Erik Westra wrote: >>> I don't need to >>> include anything else in the application, as the system will store >>> the >>> contents of the "data" and other directories outside of the >>> application bundle itself. >> >> Don't do that. That's bad. Include the data and any other >> dependencies inside the application. Having them external and using >> an >> installer is not the Mac way to do things and I'm not going to help >> you >> do it. There was a similar discussion a while ago (weeks?) and I'm >> not >> going to have it again, so search the archives and argue with the past >> if you feel strongly in the other direction :) > > I agree that this isn't something worth arguing about (and I wouldn't > expect you to help me do it, either!), but I just have one comment on > this issue: in the system I'm porting to the Mac, the "data" might > consist of 300+ megabytes of information held in an embedded SQLite > database, along with hundreds of configuration files and > dynamically-loaded Python modules (downloaded automatically from a web > site as they are required). Our system is pretty darned complicated, > and while I agree that it's not the Mac way of doing things, the > architecture works well and our users really don't care much about the > internal organisation. This isn't an application designed for mass > distribution, so issues like this really aren't all that important to > us. > > Anyway, topic closed. I certainly don't want to get into an argument > about this... I just wanted to mention that there are designated places to put files like that, and "relative to wherever the application might be" is Not That Place. See the "Where To Put Application Files" section of `The Mac OS X File System`__. .. __: http://developer.apple.com/documentation/MacOSX/Conceptual/ BPFileSystem/index.html -bob From Jack.Jansen at cwi.nl Wed Dec 22 10:51:46 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Wed Dec 22 10:51:32 2004 Subject: [Pythonmac-SIG] Read Strings from Resources In-Reply-To: References: Message-ID: <17C4781C-53FF-11D9-8B86-000A958D1666@cwi.nl> On 22 Dec 2004, at 00:22, Opstad, Dave wrote: >> I've filed a bug report (#1089399), so it'll be fixed, but that's a >> long term thing (not before 2.5). In the short term you'll have to >> parse the STR# resource yourself. I'm not 100% sure, but I think >> they're just a null-byte separated list. If they're something else (a >> list of Pascal strings?) I'll just hope someone will chime in. > > According to MacTypes.r (in the last Universal Headers revision), the > Rez format for a 'STR#' resource is as follows: > > -------------------- > type 'STR#' { > integer = $$Countof(StringArray); > array StringArray { > pstring; /* String */ > }; > }; > -------------------- > > So it looks like a 2-byte count followed by an array of Pascal strings. Ah yes. And now that I see this I seem to remember that the pstrings are padded to a 2-byte boundary. -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From Jack.Jansen at cwi.nl Wed Dec 22 11:06:55 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Wed Dec 22 11:06:45 2004 Subject: [Pythonmac-SIG] Tkinter and Python 2.2 In-Reply-To: <41C8FE23.40005@wordtech-software.com> References: <41C8FE23.40005@wordtech-software.com> Message-ID: <35C56CEC-5401-11D9-8B86-000A958D1666@cwi.nl> > If I have the source code for TkAqua, can it be modified and > recompiled as > a separate binary for PoserPython? [I'm guessing this is preferable to > trying to get one instance of TkAqua to work for both instances of > Python] > Does it make any difference if I don't have any other instances of > TkAqua > on my system? I don't think there's any need to recompile TkAqua, or anything drastic like that. If you have TkAqua installed on your system the only thing you really need to do is build the _tkinter extension module against that TkAqua. Now, depending on how old the Python is that PoserPython is based on this may be a bit of work, but doable. If PoserPython's version is one that already supported linking against AquaTk you just rip the relevant portion out of the toplevel setup.py for that Python version. If the Tk support code in setup.py has all sorts of references to "-framework Tk" then that should work. If it appears that setup.py for the relevant Python version does not support AuqaTk then there's a bit more work to do. You can try to get setup.py from a recent (2.3 or later) Python distribution and working from there. Trying to isolate only the _tkinter-relevant code in Python's main setup.py can be a bit daunting. It may be worthwhile to look at the setup.py for Fredrik Lund's PIL (the Python imaging l,ibrary) package. It has also isolated and duplicated/modified the _tkinter build code and incorporated it into their own setup.py (because PIL will optionally build a custom _tkinter that has support for PIL images). -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From ronaldoussoren at mac.com Wed Dec 22 12:49:22 2004 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Wed Dec 22 12:49:47 2004 Subject: [Pythonmac-SIG] py2app standalone options In-Reply-To: References: Message-ID: <8128F38C-686F-45F7-90C4-CB181B992AD1@mac.com> On 21-dec-2004, at 23:42, has wrote: > Chris Barker wrote: > > >> I originally came down on Has' side of this debate, but now think Bob >> has made the right choices, so I thought I'd add a couple comments. >> >> First, I'm a little unclear on what exactly Has wants. Could you >> clarify? >> > > Freedom, basically. It's easier to assemble a workflow by mixing and > matching small, single-purpose components than to strip down a great > big monolithic lump to get the pieces you want/need. If you're going > to protect the end user from doing stupid things, that's great, but it > should be done by the next layer up. Users who work at the top layer > are protected; users who want/need to route around the 'dummy mode' > restrictions can go in at the layer beneath. After all, it's the > user's foot, and if they want to shoot holes in it in full knowledge > of what they're doing then far be it for anyone or anything else to > stand in their way. You obviously don't want it badly enough. Adding an option that will make the application not include stuff from site-packages is not much work, the patch is less that 100 lines (context-diff) and it took me less than half an hour to write it. The basic architecture of the code looks just fine, and py2app does what it suppposed to do. The packaging needs some work (where's the documentation?), but this is a 0.x release after all. > > > For example, appscript currently takes this approach. The lower-level > aem package provides a comprehensive wrapper around the AEM; appscript > builds on this to provide a nice, safe, friendly-looking user > interface for application scripting. Most folks'll just use appscript > for all their application scripting, but geeks who need access to the > full AEM, e.g. to send asynchronous events, can use aem. Prior to > 0.6.0 appscript was a monolithic system, which meant you were SOOL if > you wanted to do async events, for example - an issue Bob also > happened to raise at the time. > > To give a practical example, let's say I want to write a GUI interface > to py2app. My main dialog has some text fields and checkboxes for > basic setup info, plus a table view listing all dependencies, allowing > users to check/uncheck the items they want/don't want included. The > obvious way to implement this would be to call modulegraph to generate > the table content, then take the list of checked items and feed it to > py2app's package-building function via an 'includeitems' argument. I > really don't want or need py2app to run modulegraph a second time just > because it's been welded into the basemost layer. That's an application with different requirements than py2app, and that should be easy enough to build using the building blocks of py2app. BTW. the GUI I'd like to see is a GUI that allows me to grafically construct setup.py files. Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20041222/8901d0a3/smime.bin From bob at redivi.com Wed Dec 22 14:29:54 2004 From: bob at redivi.com (Bob Ippolito) Date: Wed Dec 22 14:30:00 2004 Subject: [Pythonmac-SIG] py2app standalone options In-Reply-To: <8128F38C-686F-45F7-90C4-CB181B992AD1@mac.com> References: <8128F38C-686F-45F7-90C4-CB181B992AD1@mac.com> Message-ID: <90C94A71-541D-11D9-8396-000A95BA5446@redivi.com> On Dec 22, 2004, at 6:49, Ronald Oussoren wrote: > On 21-dec-2004, at 23:42, has wrote: > >> Chris Barker wrote: >> >>> I originally came down on Has' side of this debate, but now think Bob >>> has made the right choices, so I thought I'd add a couple comments. >>> >>> First, I'm a little unclear on what exactly Has wants. Could you >>> clarify? >>> >> >> Freedom, basically. It's easier to assemble a workflow by mixing and >> matching small, single-purpose components than to strip down a great >> big monolithic lump to get the pieces you want/need. If you're going >> to protect the end user from doing stupid things, that's great, but >> it should be done by the next layer up. Users who work at the top >> layer are protected; users who want/need to route around the 'dummy >> mode' restrictions can go in at the layer beneath. After all, it's >> the user's foot, and if they want to shoot holes in it in full >> knowledge of what they're doing then far be it for anyone or anything >> else to stand in their way. > > > You obviously don't want it badly enough. Adding an option that will > make the application not include stuff from site-packages is not much > work, the patch is less that 100 lines (context-diff) and it took me > less than half an hour to write it. > You did write it incorrectly, though. You didn't make it imply --site-packages (non-working executables by default!), and you didn't check to see if it was compatible with Python 2.4. site.sitedirs, or anything equivalent, does not exist in Python >= 2.4. The former is easy to fix, but the latter is not. Additionally, the filter stack is stronger than "includes" so you certainly wouldn't be able to actually use it to do the use case that Has' fabricated. Needless to say, this functionality won't be popping up in 0.1.7 :) -bob From sw at wordtech-software.com Wed Dec 22 15:46:29 2004 From: sw at wordtech-software.com (Kevin Walzer) Date: Wed Dec 22 15:46:34 2004 Subject: [Pythonmac-SIG] Re: [Pyqt-mac-list] Re: Eric 3 In-Reply-To: <0AC089F5-541A-11D9-A527-000D93537766@uakron.edu> References: <0AC089F5-541A-11D9-A527-000D93537766@uakron.edu> Message-ID: <41C988C5.5040003@wordtech-software.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jay, Your path looks correctly set up to me. If you have the Pythonmac extensions installed, that's important, as my Eric3 app bundle actually makes use of the Python interpreter embedded in the PythonIDE. (That will be corrected in the next release of the entire package.) Therefore, it's not clear to me why Eric3 isn't seeing the Qt module, assuming that you're running the Eric3 version from /Applications. I'm wondering if the problem is, in fact, because you replaced the Apple - -installed version of Python with your own framework build. My package assumes the standard Apple installation, and I believe the PyQt source assumes this also. I'm not an expert on the internals of framework builds of Python, but my understanding is that ripping out Apple's build of Python can break things in unexpected ways. I'm copying my reply to the PythonMac and PyKDE lists: perhaps Jack Jansen (MacPython maintainer) or Phil Thompson (PyQt author) can shed more light on that aspect of your problem. I'll also see if I can find out more on my end. Regards, Kevin Jay Mutter wrote: | DEAR KEVIN; | | Yes i did set QTDIR and referring back to Brian's previous post i do | think that it is some sort of path problem but i am not sure what. | | Anyway i only run Python 2.3.4 ( i terminated Apple's version long ago | to avoid problems) | | from running env i got | | | PATH=/Developer/qt/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/ | usr/local/lib:/usr/local/pgsql:/usr/local/pgsql/lib:/usr/local/pgsql/ | include:/usr/local/pgsql/bin:/System/Library/Frameworks/ | Python.framework/Versions/2.3/bin:/library/frameworks/python.framework/ | versions/2.3/lib/python2.3/site-packages | | DYLD_LIBRARY_PATH=/Developer/qt/lib: | PYTHONPATH=/system/Library/Frameworks/Python.framework/Versions/2.3/ | lib/python2.3/site-packages/ | | | from running $PATH i got | -bash: | /Developer/qt/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/ | local/lib:/usr/local/pgsql:/usr/local/pgsql/lib:/usr/local/pgsql/ | include:/usr/local/pgsql/bin:/System/Library/Frameworks/ | Python.framework/Versions/2.3/bin:/library/frameworks/python.framework/ | versions/2.3/lib/python2.3/site-packages: No such file or directory | | My .bash_profile is | | # .bash_profile | PYTHONPATH=/system/Library/Frameworks/Python.framework/Versions/2.3/ | lib/python2$ | export PYTHONPATH | QTDIR=/Developer/qt | PATH=$QTDIR/bin:$PATH | DYLD_LIBRARY_PATH=$QTDIR/lib:$DYLD_LIBRARY_PATH | export QTDIR PATH DYLD_LIBRARY_PATH | | And as always | | Many thanks for the help and Happy Holidays | | Jay Mutter | | | | ------------------------------------------------------- | SF email is sponsored by - The IT Product Guide | Read honest & candid reviews on hundreds of IT Products from real users. | Discover which products truly live up to the hype. Start reading now. | http://productguide.itmanagersjournal.com/ | _______________________________________________ | Pyqt-mac-list mailing list | Pyqt-mac-list@lists.sourceforge.net | https://lists.sourceforge.net/lists/listinfo/pyqt-mac-list | | -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFByYjEJmdQs+6YVcoRAj2NAJ46bbDGfdcvMLAKzO+zBFmlOnD7xwCfdM7F L3KhLMqU1wAb1IkgzH7PCZk= =FOCe -----END PGP SIGNATURE----- From bob at redivi.com Wed Dec 22 16:40:00 2004 From: bob at redivi.com (Bob Ippolito) Date: Wed Dec 22 16:40:15 2004 Subject: [Pythonmac-SIG] Re: [Pyqt-mac-list] Re: Eric 3 In-Reply-To: <41C988C5.5040003@wordtech-software.com> References: <0AC089F5-541A-11D9-A527-000D93537766@uakron.edu> <41C988C5.5040003@wordtech-software.com> Message-ID: On Dec 22, 2004, at 9:46, Kevin Walzer wrote: > Your path looks correctly set up to me. If you have the Pythonmac > extensions installed, that's important, as my Eric3 app bundle actually > makes use of the Python interpreter embedded in the PythonIDE. (That > will be corrected in the next release of the entire package.) > Therefore, > it's not clear to me why Eric3 isn't seeing the Qt module, assuming > that > you're running the Eric3 version from /Applications. > > I'm wondering if the problem is, in fact, because you replaced the > Apple > - -installed version of Python with your own framework build. My > package > assumes the standard Apple installation, and I believe the PyQt source > assumes this also. I'm not an expert on the internals of framework > builds of Python, but my understanding is that ripping out Apple's > build > of Python can break things in unexpected ways. > > I'm copying my reply to the PythonMac and PyKDE lists: perhaps Jack > Jansen (MacPython maintainer) or Phil Thompson (PyQt author) can shed > more light on that aspect of your problem. > > I'll also see if I can find out more on my end. > > Jay Mutter wrote: > | > | Yes i did set QTDIR and referring back to Brian's previous post i do > | think that it is some sort of path problem but i am not sure what. > | > | Anyway i only run Python 2.3.4 ( i terminated Apple's version long > ago > | to avoid problems) And yet, you caused them. This is probably the root if your problem. Messing with files in /System or /usr (except for /usr/local) is a recipe for disaster. There's always a better way to "replace" something, usually as simple as just putting /usr/local/bin (or other) early on in your PATH. My suggestion: Reinstall OS X, and don't screw it up this time. > | from running env i got > | > | > | PATH=/Developer/qt/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/ > | usr/local/lib:/usr/local/pgsql:/usr/local/pgsql/lib:/usr/local/pgsql/ > | include:/usr/local/pgsql/bin:/System/Library/Frameworks/ > | > Python.framework/Versions/2.3/bin:/library/frameworks/ > python.framework/ > | versions/2.3/lib/python2.3/site-packages What the heck is site-packages doing in sys.path? > | DYLD_LIBRARY_PATH=/Developer/qt/lib: > | PYTHONPATH=/system/Library/Frameworks/Python.framework/Versions/2.3/ > | lib/python2.3/site-packages/ You should basically never set PYTHONPATH > | from running $PATH i got > | -bash: > | /Developer/qt/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/ > | local/lib:/usr/local/pgsql:/usr/local/pgsql/lib:/usr/local/pgsql/ > | include:/usr/local/pgsql/bin:/System/Library/Frameworks/ > | > Python.framework/Versions/2.3/bin:/library/frameworks/ > python.framework/ > | versions/2.3/lib/python2.3/site-packages: No such file or directory running $PATH? What the heck? If you mean typing just $PATH at a bash prompt, of course it's going to say no such file or directory, it's not supposed to do anything useful. > | My .bash_profile is > | > | # .bash_profile > | PYTHONPATH=/system/Library/Frameworks/Python.framework/Versions/2.3/ > | lib/python2$ > | export PYTHONPATH These lines shouldn't ever be necessary > | QTDIR=/Developer/qt > | PATH=$QTDIR/bin:$PATH > | DYLD_LIBRARY_PATH=$QTDIR/lib:$DYLD_LIBRARY_PATH > | export QTDIR PATH DYLD_LIBRARY_PATH This looks right enough. Typically DYLD_LIBRARY_PATH is a terrible, awful, evil thing to do, but that's how Qt works. -bob From Dave.Opstad at monotypeimaging.com Wed Dec 22 16:55:45 2004 From: Dave.Opstad at monotypeimaging.com (Opstad, Dave) Date: Wed Dec 22 16:55:53 2004 Subject: [Pythonmac-SIG] Read Strings from Resources In-Reply-To: <17C4781C-53FF-11D9-8B86-000A958D1666@cwi.nl> Message-ID: On 12/22/04 1:51 AM, "Jack Jansen" wrote: > On 22 Dec 2004, at 00:22, Opstad, Dave wrote: > >> According to MacTypes.r (in the last Universal Headers revision), the >> Rez format for a 'STR#' resource is as follows: >> >> -------------------- >> type 'STR#' { >> integer = $$Countof(StringArray); >> array StringArray { >> pstring; /* String */ >> }; >> }; >> -------------------- >> >> So it looks like a 2-byte count followed by an array of Pascal strings. > > Ah yes. And now that I see this I seem to remember that the pstrings > are padded to a 2-byte boundary. Hmmm, I'd be a bit surprised if there was such alignment padding. Pascal string lengths are one byte, so after the single integer listed above everything else should just be byte-aligned. Dave From ronaldoussoren at mac.com Wed Dec 22 19:26:10 2004 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Wed Dec 22 19:26:21 2004 Subject: [Pythonmac-SIG] py2app standalone options In-Reply-To: <90C94A71-541D-11D9-8396-000A95BA5446@redivi.com> References: <8128F38C-686F-45F7-90C4-CB181B992AD1@mac.com> <90C94A71-541D-11D9-8396-000A95BA5446@redivi.com> Message-ID: On 22-dec-04, at 14:29, Bob Ippolito wrote: >>> anyone or anything else to stand in their way. >> >> >> You obviously don't want it badly enough. Adding an option that will >> make the application not include stuff from site-packages is not much >> work, the patch is less that 100 lines (context-diff) and it took me >> less than half an hour to write it. >> > > You did write it incorrectly, though. Sure (that's why my patch was not included in my message to the list), but if someone really wants to have such an option he can implement it within a reasonable timeframe. I'm quite happy with the current functionality of py2app, --exclude is the right way to exclude some packages from the application bundle. > > Needless to say, this functionality won't be popping up in 0.1.7 :) Fine by me. It was fun to have a look at the implementation of py2app. Ronald From wicked-witch at gmx.net Wed Dec 22 20:25:45 2004 From: wicked-witch at gmx.net (wicked witch) Date: Wed Dec 22 20:25:52 2004 Subject: [Pythonmac-SIG] Read Strings from Resources In-Reply-To: References: Message-ID: <41C9CA39.3060701@gmx.net> Opstad, Dave schrieb: > On 12/22/04 1:51 AM, "Jack Jansen" wrote: > > >>On 22 Dec 2004, at 00:22, Opstad, Dave wrote: >> >> >>>According to MacTypes.r (in the last Universal Headers revision), the >>>Rez format for a 'STR#' resource is as follows: >>> >>>-------------------- >>>type 'STR#' { >>> integer = $$Countof(StringArray); >>> array StringArray { >>> pstring; /* String */ >>> }; >>>}; >>>-------------------- >>> >>>So it looks like a 2-byte count followed by an array of Pascal strings. >> >>Ah yes. And now that I see this I seem to remember that the pstrings >>are padded to a 2-byte boundary. > > > Hmmm, I'd be a bit surprised if there was such alignment padding. Pascal > string lengths are one byte, so after the single integer listed above > everything else should just be byte-aligned. > yeah you are right. Still it would be much easier with the GetIndString method. Thx for your help. I implemented it in c++ this time(was just a litle tool). thx Zee From just at letterror.com Wed Dec 22 20:39:27 2004 From: just at letterror.com (Just van Rossum) Date: Wed Dec 22 20:39:32 2004 Subject: [Pythonmac-SIG] Read Strings from Resources In-Reply-To: <41C9CA39.3060701@gmx.net> Message-ID: wicked witch wrote: > >>>So it looks like a 2-byte count followed by an array of Pascal > >>>strings. > >> > >>Ah yes. And now that I see this I seem to remember that the pstrings > >>are padded to a 2-byte boundary. > > > > Hmmm, I'd be a bit surprised if there was such alignment padding. > > Pascal string lengths are one byte, so after the single integer > > listed above everything else should just be byte-aligned. > > > yeah you are right. Still it would be much easier with the > GetIndString method. Thx for your help. I implemented it in c++ this > time(was just a litle tool). Here's a quick Python version: >>> import struct >>> def unpackStr(data): ... result = [] ... n, = struct.unpack(">H", data[:2]) ... data = data[2:] ... for i in range(n): ... l = ord(data[0]) ... result.append(data[1:1+l]) ... data = data[1+l:] ... return result ... >>> data = "\000\005\004abcd\000\002xy\01012345678\001z" >>> unpackStr(data) ['abcd', '', 'xy', '12345678', 'z'] >>> Just From whamoo at rknet.it Thu Dec 23 01:09:18 2004 From: whamoo at rknet.it (whamoo) Date: Thu Dec 23 01:08:21 2004 Subject: [Pythonmac-SIG] Question about Pil and icns... Message-ID: Hi to all, I've read that new beta of the Pil now add support for icns file format, nice, but in the code of the plugin i read that there is only the read support, so, i cannot convert icns in other format and vice-versa? And if i load icns, work on it, then i cannot save..... Can someone tell me something about it? Someone have tried? Thanks a lot ps: Special thanks to Bob Ippolito for the great works Whamoo www.rknet.it Powered by: - MacOsX - Gnu / Linux Debian Sarge - Amiga Os 3.9 - Milk From bob at redivi.com Thu Dec 23 01:29:05 2004 From: bob at redivi.com (Bob Ippolito) Date: Thu Dec 23 01:29:12 2004 Subject: [Pythonmac-SIG] Question about Pil and icns... In-Reply-To: References: Message-ID: On Dec 22, 2004, at 7:09 PM, whamoo wrote: > I've read that new beta of the Pil now add support for icns file > format, nice, but in the code of the plugin i read that there is only > the read support, so, i cannot convert icns in other format and > vice-versa? And if i load icns, work on it, then i cannot save..... > Can someone tell me something about it? Someone have tried? That is correct, this is read-only support. You may not save icns files with the code in PIL. You could of course do it the native way, using Mac APIs, or just by dragging images into Icon Composer. My use case was that I had application resources in the canonical Mac OS X formats, and I wanted to re-use them in a Windows port of the software... so I wrote an icns decoder for these files (I used the 128x128 version of the icon in the UI), and all the string localization support from Foundation. I did of course need regular windows .ico files for the applications, but typically they only go up to 48x48, so I still wanted to re-use my .icns file rather than maintain a separate png of 128x128 for the UI. Needless to say, I did not need write support for ico, since all of my source icons were in icns format. What I would've liked is Windows XP .ico writing support, but I couldn't find that (or sufficient docs to implement it) *anywhere* and I ended up using a commercial package on Win32 to do it in batch. -bob From ewestra at gmail.com Thu Dec 23 01:31:06 2004 From: ewestra at gmail.com (Erik Westra) Date: Thu Dec 23 01:31:09 2004 Subject: [Pythonmac-SIG] py2app Enforces Directory Structure? In-Reply-To: <3453C996-53D9-11D9-B5D4-000A9567635C@redivi.com> References: <3c5e36f404122119295bdc9c7a@mail.gmail.com> <88C6D811-53D0-11D9-B5D4-000A9567635C@redivi.com> <3c5e36f4041221203939d7111e@mail.gmail.com> <3453C996-53D9-11D9-B5D4-000A9567635C@redivi.com> Message-ID: <3c5e36f40412221631142825a0@mail.gmail.com> Hi Bob, > I just wanted to mention that there are designated places to put files > like that, and "relative to wherever the application might be" is Not > That Place. See the "Where To Put Application Files" section of `The > Mac OS X File System`__. Thanks for pointing me in the right direction. I've had a detailed read, and thought about this and discussed it with my boss somewhat. While this is too radical a step to take right now, I have changed our system so that the placement of the data files can be changed in the future simply by changing one function within a utility module (previously, all references to data files used os.path.join("..", "dir", "filename"), hardwiring the directory placement, which was awful). At present, I've set this function up to work the "bad" way you described in one of your earlier E-Mails on this topic -- by accessing the data relative to the application bundle itself. But if I can convince the others in our company that it's a good idea, I can easily change this in future by changing that one data-access function, so that, for example, all the app's data is stored in a sub-directory within ~/Library/Application Support. Anyway, enough on this. I just wanted to thank you for the fantastic work you've done on py2app. I'm amazed -- I've packaged our company's various applications to work under Linux and Windows, using both the MacMillan Installer and py2exe, and py2app is by far the most trouble-free solution I've ever found (once you helped me out with getting sibling modules importing correctly). The system I bundled up last night makes heavy use of wxPython, docutils, PIL, pySQLite, and ReportLab -- and it all works perfectly right out of the box. The generated application is slightly bigger than the Windows version (the compressed disk image is 11 megs, compared with 8 megs for the equivalent installer under Windows), but that's acceptable. I can't believe that py2app simply handled all the dependencies and complexities of these various tools right out of the box. Keep up the great work! And thanks again... - Erik. From whamoo at rknet.it Thu Dec 23 01:45:11 2004 From: whamoo at rknet.it (whamoo) Date: Thu Dec 23 01:44:15 2004 Subject: [Pythonmac-SIG] Question about Pil and icns... In-Reply-To: References: Message-ID: On 23/dic/04, at 01:29, Bob Ippolito wrote: > > On Dec 22, 2004, at 7:09 PM, whamoo wrote: > >> I've read that new beta of the Pil now add support for icns file >> format, nice, but in the code of the plugin i read that there is only >> the read support, so, i cannot convert icns in other format and >> vice-versa? And if i load icns, work on it, then i cannot save..... >> Can someone tell me something about it? Someone have tried? > > That is correct, this is read-only support. You may not save icns > files with the code in PIL. But starting by reading a icns, i can save a png or jpg? > You could of course do it the native way, using Mac APIs, or just by > dragging images into Icon Composer. There is a fast way to produce icns starting from a 128x128 image (format Png, jpg doesn't matter)? What Mac Api i must use? I've search documentation, but found about nothing (maybe I'm not able to search), i want write a python program to convert images in icns in a background fast way, i can't drop 1000 image con icon composer =) Thanks for the fast repply Whamoo www.rknet.it Powered by: - MacOsX - Gnu / Linux Debian Sarge - Amiga Os 3.9 - Milk From bob at redivi.com Thu Dec 23 01:49:45 2004 From: bob at redivi.com (Bob Ippolito) Date: Thu Dec 23 01:49:50 2004 Subject: [Pythonmac-SIG] Question about Pil and icns... In-Reply-To: References: Message-ID: <89F08D49-547C-11D9-B5D4-000A9567635C@redivi.com> On Dec 22, 2004, at 7:45 PM, whamoo wrote: > > On 23/dic/04, at 01:29, Bob Ippolito wrote: > >> >> On Dec 22, 2004, at 7:09 PM, whamoo wrote: >> >>> I've read that new beta of the Pil now add support for icns file >>> format, nice, but in the code of the plugin i read that there is >>> only the read support, so, i cannot convert icns in other format and >>> vice-versa? And if i load icns, work on it, then i cannot save..... >>> Can someone tell me something about it? Someone have tried? >> >> That is correct, this is read-only support. You may not save icns >> files with the code in PIL. > > But starting by reading a icns, i can save a png or jpg? Yes, of course. Image.open('myapp.icns').save('myapp.png') will probably Just Work. >> You could of course do it the native way, using Mac APIs, or just by >> dragging images into Icon Composer. > > There is a fast way to produce icns starting from a 128x128 image > (format Png, jpg doesn't matter)? > What Mac Api i must use? I've search documentation, but found about > nothing (maybe I'm not able to search), i want write a python program > to convert images in icns in a background fast way, i can't drop 1000 > image con icon composer =) The easiest way would probably be to use IconFamily from PyObjC . Carbon is always a pain in the ass, but the Icon Services functions may be wrapped (not sure?). NSImage will load pngs and jpegs quickly and easily. -bob From bob at redivi.com Thu Dec 23 01:54:26 2004 From: bob at redivi.com (Bob Ippolito) Date: Thu Dec 23 01:54:32 2004 Subject: [Pythonmac-SIG] py2app Enforces Directory Structure? In-Reply-To: <3c5e36f40412221631142825a0@mail.gmail.com> References: <3c5e36f404122119295bdc9c7a@mail.gmail.com> <88C6D811-53D0-11D9-B5D4-000A9567635C@redivi.com> <3c5e36f4041221203939d7111e@mail.gmail.com> <3453C996-53D9-11D9-B5D4-000A9567635C@redivi.com> <3c5e36f40412221631142825a0@mail.gmail.com> Message-ID: <31CBC34D-547D-11D9-B5D4-000A9567635C@redivi.com> On Dec 22, 2004, at 7:31 PM, Erik Westra wrote: > Anyway, enough on this. I just wanted to thank you for the fantastic > work you've done on py2app. I'm amazed -- I've packaged our company's > various applications to work under Linux and Windows, using both the > MacMillan Installer and py2exe, and py2app is by far the most > trouble-free solution I've ever found (once you helped me out with > getting sibling modules importing correctly). The system I bundled up > last night makes heavy use of wxPython, docutils, PIL, pySQLite, and > ReportLab -- and it all works perfectly right out of the box. The > generated application is slightly bigger than the Windows version (the > compressed disk image is 11 megs, compared with 8 megs for the > equivalent installer under Windows), but that's acceptable. I can't > believe that py2app simply handled all the dependencies and > complexities of these various tools right out of the box. py2app has special considerations so that it (makes one hell of an attempt to) get wxPython, docutils, and PIL packaged correctly out of the box. There are a few other packages on its "hit list", but most stuff tends to Just Work without too much special casing. The downside is that in some cases, it will include more than you want (especially for PyQt), but at least your application will work. After using py2exe and reading the wiki, mailing lists, etc. I decided I would try very hard to make py2app do the right thing with the minimal amount of training (for both the user and the setup.py) and I think I've more or less done that. Most of the work I've done with regard to all this magic behavior is cross-platform and is mostly in the "altgraph" and "modulegraph" packages in the py2app distribution.. so if someone were so inclined, they could soup up py2exe, cx_Freeze, etc. leveraging this work. I might do this myself at some point, but not soon. Maybe I'll try and PEP it into Python 2.5. -bob From kid at kendermedia.com Thu Dec 23 15:19:39 2004 From: kid at kendermedia.com (Kevin Dangoor) Date: Thu Dec 23 15:19:42 2004 Subject: [Pythonmac-SIG] configure failing with Python 2.4 Message-ID: <41CAD3FB.30305@kendermedia.com> I'm thinking that I must be doing something simple wrong... hopefully that's the case. I downloaded the Python 2.4 source and tried to run a basic ./configure to see what I get. What I got was this error: checking for C++ compiler default output file name... configure: error: C++ compiler cannot create executables which appears to be caused by configure:1772: c++ conftest.cc >&5 ld: can't locate file for: -lcrt1.o While I'm sure I can track that down, I figured that I must be doing something silly. Can anyone tell me what I'm missing? Thanks, Kevin From kid at kendermedia.com Thu Dec 23 16:23:02 2004 From: kid at kendermedia.com (Kevin Dangoor) Date: Thu Dec 23 16:23:06 2004 Subject: [Pythonmac-SIG] configure failing with Python 2.4 In-Reply-To: <41CAD3FB.30305@kendermedia.com> References: <41CAD3FB.30305@kendermedia.com> Message-ID: <41CAE2D6.2090503@kendermedia.com> Err, while this might be enough info for someone to go on, I just realized that there's not much there... I'm running Mac OS 10.3.6. I have XCode/Developer Tools installed, though that didn't seem to make any difference. I even tried moving my .bashrc and .profile files out of the way to be sure that those weren't causing any grief. Kevin Kevin Dangoor wrote: > I'm thinking that I must be doing something simple wrong... hopefully > that's the case. > > I downloaded the Python 2.4 source and tried to run a basic > ./configure to see what I get. What I got was this error: > > checking for C++ compiler default output file name... configure: > error: C++ compiler cannot create executables > > which appears to be caused by > > configure:1772: c++ conftest.cc >&5 > ld: can't locate file for: -lcrt1.o > > While I'm sure I can track that down, I figured that I must be doing > something silly. Can anyone tell me what I'm missing? > > Thanks, > Kevin > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > > > From bob at redivi.com Thu Dec 23 17:11:53 2004 From: bob at redivi.com (Bob Ippolito) Date: Thu Dec 23 17:12:17 2004 Subject: [Pythonmac-SIG] configure failing with Python 2.4 In-Reply-To: <41CAE2D6.2090503@kendermedia.com> References: <41CAD3FB.30305@kendermedia.com> <41CAE2D6.2090503@kendermedia.com> Message-ID: <5C64C36A-54FD-11D9-B983-000A9567635C@redivi.com> Reinstall Xcode and/or make sure you aren't using Fink or something which may have installed an alternate compiler (make sure "which cc" and "which gcc" point to /usr/bin). On Dec 23, 2004, at 10:23 AM, Kevin Dangoor wrote: > Err, while this might be enough info for someone to go on, I just > realized that there's not much there... > > I'm running Mac OS 10.3.6. I have XCode/Developer Tools installed, > though that didn't seem to make any difference. I even tried moving my > .bashrc and .profile files out of the way to be sure that those > weren't causing any grief. > > Kevin > > Kevin Dangoor wrote: > >> I'm thinking that I must be doing something simple wrong... hopefully >> that's the case. >> >> I downloaded the Python 2.4 source and tried to run a basic >> ./configure to see what I get. What I got was this error: >> >> checking for C++ compiler default output file name... configure: >> error: C++ compiler cannot create executables >> >> which appears to be caused by >> >> configure:1772: c++ conftest.cc >&5 >> ld: can't locate file for: -lcrt1.o >> >> While I'm sure I can track that down, I figured that I must be doing >> something silly. Can anyone tell me what I'm missing? >> >> Thanks, >> Kevin >> _______________________________________________ >> Pythonmac-SIG maillist - Pythonmac-SIG@python.org >> http://mail.python.org/mailman/listinfo/pythonmac-sig >> >> >> > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From kid at kendermedia.com Thu Dec 23 17:30:09 2004 From: kid at kendermedia.com (Kevin Dangoor) Date: Thu Dec 23 17:31:30 2004 Subject: [Pythonmac-SIG] configure failing with Python 2.4 In-Reply-To: <5C64C36A-54FD-11D9-B983-000A9567635C@redivi.com> References: <41CAD3FB.30305@kendermedia.com> <41CAE2D6.2090503@kendermedia.com> <5C64C36A-54FD-11D9-B983-000A9567635C@redivi.com> Message-ID: <41CAF291.70109@kendermedia.com> I actually just installed Xcode this morning. I do have Fink installed, but removed it from my path when I moved my bashrc and profile aside. I also had confirmed that gcc is in /usr/bin. > gcc -v Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs Thread model: posix gcc version 3.3 20030304 (Apple Computer, Inc. build 1495) That's what struck me as odd here... there's nothing very out of the ordinary that I'm aware of. As I thought about it some more, I may just use my existing python 2.3 until there's an official MacPython 2.4 release. Kevin Bob Ippolito wrote: > Reinstall Xcode and/or make sure you aren't using Fink or something > which may have installed an alternate compiler (make sure "which cc" > and "which gcc" point to /usr/bin). > > On Dec 23, 2004, at 10:23 AM, Kevin Dangoor wrote: > >> Err, while this might be enough info for someone to go on, I just >> realized that there's not much there... >> >> I'm running Mac OS 10.3.6. I have XCode/Developer Tools installed, >> though that didn't seem to make any difference. I even tried moving >> my .bashrc and .profile files out of the way to be sure that those >> weren't causing any grief. >> >> Kevin >> >> Kevin Dangoor wrote: >> >>> I'm thinking that I must be doing something simple wrong... >>> hopefully that's the case. >>> >>> I downloaded the Python 2.4 source and tried to run a basic >>> ./configure to see what I get. What I got was this error: >>> >>> checking for C++ compiler default output file name... configure: >>> error: C++ compiler cannot create executables >>> >>> which appears to be caused by >>> >>> configure:1772: c++ conftest.cc >&5 >>> ld: can't locate file for: -lcrt1.o >>> >>> While I'm sure I can track that down, I figured that I must be doing >>> something silly. Can anyone tell me what I'm missing? >>> >>> Thanks, >>> Kevin >>> _______________________________________________ >>> Pythonmac-SIG maillist - Pythonmac-SIG@python.org >>> http://mail.python.org/mailman/listinfo/pythonmac-sig >>> >>> >>> >> >> _______________________________________________ >> Pythonmac-SIG maillist - Pythonmac-SIG@python.org >> http://mail.python.org/mailman/listinfo/pythonmac-sig > > > > > From bugbee at seanet.com Thu Dec 23 18:36:35 2004 From: bugbee at seanet.com (Larry Bugbee) Date: Thu Dec 23 18:36:41 2004 Subject: [Pythonmac-SIG] Read Strings from Resources In-Reply-To: <20041223110009.053601E4011@bag.python.org> References: <20041223110009.053601E4011@bag.python.org> Message-ID: <3183719D-5509-11D9-9D85-000393DB272E@seanet.com> For the useless? trivia department... >>> So it looks like a 2-byte count followed by an array of Pascal >>> strings. >> >> Ah yes. And now that I see this I seem to remember that the pstrings >> are padded to a 2-byte boundary. > > Hmmm, I'd be a bit surprised if there was such alignment padding. > Pascal string lengths are one byte, so after the single integer > listed above everything else should just be byte-aligned. Most Pascals including UCSD Pascal had a single byte string length limiting strings to a maximum of 255. A real pain. The "old" 8 and 16-bit processors saved cycles fetching things from memory if aligned to "word" boundaries. In those days a word was typically 16 bits. Then came 32 and now 64. Tomorrow infinity? Actually some of the earliest machines like the IBM 1620 had variable word lengths. FWIW.... Larry From hengist.podd at virgin.net Thu Dec 23 19:42:51 2004 From: hengist.podd at virgin.net (has) Date: Thu Dec 23 19:43:00 2004 Subject: [Pythonmac-SIG] py2app standalone options In-Reply-To: <8128F38C-686F-45F7-90C4-CB181B992AD1@mac.com> References: <8128F38C-686F-45F7-90C4-CB181B992AD1@mac.com> Message-ID: Ronald Oussoren wrote: >>First, I'm a little unclear on what exactly Has wants. Could you clarify? >> >>Freedom, basically. I > > >You obviously don't want it badly enough. Adding an option that will >make the application not include stuff from site-packages is not >much work, the patch is less that 100 lines (context-diff) and it >took me less than half an hour to write it. > Oh, absolutely true. But then, given the choice of puddling around in py2app's guts for days on end - remember, I'm nothing like as technically capable as folks like Bob and yourself - or getting on with my own projects, I have to give the latter priority (since who else is gonna do it for me?). For now, I can just continue futzing with/occasionally swearing at BundleBuilder; it's not ideal, but it does the job and lets me get on with more pressing work (like punting AppleScript's scrawny old butt to the kerb;). >>To give a practical example, let's say I want to write a GUI >>interface to py2app. > >That's an application with different requirements than py2app, Not sure how: both are intended to build applications, and allow users to configure exactly how they're built. The only thing that differs is the workflow's order. >and that should be easy enough to build using the building blocks of py2app. That would be my hope. Of course, one shouldn't have to disassemble py2app with a hammer in order to get at the bits you need; that's my concern. >BTW. the GUI I'd like to see is a GUI that allows me to grafically >construct setup.py files. I think the biggest problem with setup.py files is that they're unnecessarily complicated. The best way to simplify the setup process would be to simplify setup.py itself: push all the descriptive stuff - name, version, author, description, etc, etc. - into its own plaintext file so the only thing setup.py then has to deal with is any custom build code. Make the system simple enough that it doesn't require a wizard in the first place; a drag-n-drop GUI shell is then merely a pleasant (and newbie-friendly) convenience, rather than an awkward band-aid for deeper inadequacies. OK, enough blathering the now... back to getting the next version of appscript fit to ship - don't still want to be doing it in 2006. ;) Later, has (May not know much about programming, but I know what I like.;) -- http://freespace.virgin.net/hamish.sanderson/ From bob at redivi.com Thu Dec 23 21:39:45 2004 From: bob at redivi.com (Bob Ippolito) Date: Thu Dec 23 21:39:56 2004 Subject: [Pythonmac-SIG] py2app standalone options In-Reply-To: References: <8128F38C-686F-45F7-90C4-CB181B992AD1@mac.com> Message-ID: On Dec 23, 2004, at 1:42 PM, has wrote: > Ronald Oussoren wrote: > >>> To give a practical example, let's say I want to write a GUI >>> interface to py2app. >> >> That's an application with different requirements than py2app, > > Not sure how: both are intended to build applications, and allow users > to configure exactly how they're built. The only thing that differs is > the workflow's order. One of py2app's goals is to integrate seamlessly with distutils and to behave similarly to py2exe when it makes sense. That goal is counter to making it suitable for inclusion into a GUI workflow, unless that GUI's job is simply to piece together a setup.py script (which is completely orthogonal to what py2app does). Distutils isn't very good at pausing in the middle of a command, and py2app executes as a single distutils command, therefore what you specifically mentioned is not reasonable. In svn trunk, I've broken up py2app._run into lots of other methods, so in theory if you cared you could now somewhat reasonably implement such functionality in a subclass, but that's as far as I'm going with it. Right now, at 0.1.x, users that don't already have a pretty good idea of how this stuff works aren't of my concern. The goal for 0.2.0, which I think has already been achieved (sans documentation), was to make it better than the alternatives for any platform. Right now, for any given application, less magic is required in a py2app setup.py than anywhere else. It is NOT my goal to replace distutils or create a front-end to distutils at this point. py2applet is as far as I go in that regard, and it merely constructs the runtime equivalent of the 'obvious' setup.py for the given input files and uses no hooks not already available by distutils. py2applet's main script basically *is* a generic setup.py, in some grotesque way. > Look at all this another way: in an ideal world, developers and their > applications wouldn't need to deal with any of this dependency crap > _at all_. Each app would merely list its requirements and the system > would magically conjour up suitable components upon request. That > every single app has to lug around its own set of potentially > obsolete/buggy/system-incompatible dependencies is no doubt partly due > to this not being an ideal world, so compromises must sometimes be > made. But then, it might also be partly due to a "well that's the way > things have always been done" philosophy that's come from the > traditional > static-inflexible-early-bound-language-plus-compile-time-linking side > of computer evolution; constraints Python isn't bound by. Dunno about > you, but personally I'd want to hedge my bets before tying users down > to any particular strategy. In order for that to happen, either every user will have to have every version of every library already installed, or they would have to have the newest version of every library already installed (assuming that libraries would never be able to break backwards compatibility). The other way, of course, is to have all versions of all applications and libraries available on the internet for automatic download, and then you have a software distribution system. You can already have that if you want it, but none of them are perfect and none of them are suitable for the common user on Mac OS X. Shipping a known version of all dependencies with your product guarantees that it will run the same way that it was built. That's a good thing. So what if it's "obsolete" or "buggy"? If it's obsolete, so if the application using it. If it's buggy, well, the person who developed the application should test and ship a new version that contains the newer library. At least you don't have to support the user (or another application's dependencies) doing god knows what and breaking your application (which of course, still happens, but really only by people who should know better so it's not as much of a problem). It doesn't matter when your language binds to symbols, all that matters is that when code changes, things can and probably will break. "system-incompatible" isn't really a problem. Yes, it's easy to develop software that is not backwards compatible to an older version of OS X, but so what? Chances are you're taking advantage of functionality that is not and will never be available for a previous version. Why should an application developer even have to bother listing its "requirements"? Maybe you like to do such busywork, but I sure don't. The old modulefinder does a good job at determining this automatically, and modulegraph plus the special cases inked into py2app does a much better one. I have also been having some discussions on and off with PJE and Holger Kregel about how to do this in the more general case, so that the packages that need special casing (PIL, py, pypy, PEAK, docutils, etc.) have a way of presenting that information in a cross-platform cross-packager manner... but a typical application doesn't need such trickery, wxGlade is really the only one I've seen so far. > Here's another whacky idea: why not get rid of the one-way > source-code->build->finished-application workflow, and treat [certain > types of] applications as simply another editable format? This is what > AppleScript does, for example: write a script and save it as an > applet, run it, drop the applet onto Script Editor, edit it some more, > run it, etc. If it errors, a dialog pops up with an error description > and an 'Edit Script' button that, when clicked, opens the script in SE > for you with the faulty line already highlighted. Emulate Smalltalk a > bit more, C a bit less. The more open, flexible and neutral tools like > py2app are, the easier this kind of lunacy is to indulge. After all an > idea is only stupid until you've tried it and find you really quite > like it. :) That only works because everyone already has AppleScript and its IDE installed everywhere. We don't really even have an IDE worth using, and it's *probably* already possible to do this with emacs pdb integration, though I am not an emacs user (yet) so I can't say that with any authority. >> BTW. the GUI I'd like to see is a GUI that allows me to grafically >> construct setup.py files. > > I think the biggest problem with setup.py files is that they're > unnecessarily complicated. The best way to simplify the setup process > would be to simplify setup.py itself: push all the descriptive stuff - > name, version, author, description, etc, etc. - into its own plaintext > file so the only thing setup.py then has to deal with is any custom > build code. Make the system simple enough that it doesn't require a > wizard in the first place; a drag-n-drop GUI shell is then merely a > pleasant (and newbie-friendly) convenience, rather than an awkward > band-aid for deeper inadequacies. You can do that, with a setup.cfg file . Honestly I can't see how you can really complain about setup.py being "complicated": from distutils.core import setup import py2app setup(app=['myscript.py']) What the heck is the problem with that? Understandably, it does get ugly when you need to specify py2app-specific options with options=dict(py2app=dict( ... )), but that *can* be nicely expressed in a setup.cfg [py2app] section, if you were so inclined. Additionally, as I said, I am not looking to replace distutils or write a front-end to distutils at this point, so the options syntax is a necessary evil. You can also do that with py2applet. It doesn't get much simpler than dragging your script plus resource files, optional icon and Info.plist onto py2applet and having an application bundle pop out in the same directory as the script. If the application can be packaged with a trivial setup.py (and most can), it just works. -bob From delza at livingcode.org Thu Dec 23 23:25:43 2004 From: delza at livingcode.org (Dethe Elza) Date: Thu Dec 23 23:26:36 2004 Subject: [Pythonmac-SIG] py2app standalone options In-Reply-To: References: <8128F38C-686F-45F7-90C4-CB181B992AD1@mac.com> Message-ID: <95763F56-5531-11D9-8131-0003939B59E8@livingcode.org> With regards to refactoring setup.py files, here is what I've been using for several different apps. It has evolved as I've found new requirements. The only things I have to change from app to app (at this point) are the bits in ALL_CAPS at the beginning. I've been meaning to factor all of this into something like a function + .cfg, but haven't gotten there yet, so I just copy this into a new project and edit the few lines that change. HTH --Dethe ''' Run with: % python setup.py py2app ''' from distutils.core import setup import py2app NAME = 'Oblique Strategies' SCRIPT = 'oblique.py' VERSION = '0.3' ICON = NAME ID = 'oblique_strategies' COPYRIGHT = 'Copyright 2004 Dethe Elza' DATA_FILES = ['English.lproj', 'data', 'MainMenu.gsmarkup', 'MainWindow.gsmarkup', 'Credits.html'] plist = dict( CFBundleIconFile = ICON, CFBundleName = NAME, CFBundleShortVersionString = ' '.join([NAME, VERSION]), CFBundleGetInfoString = NAME, CFBundleExecutable = NAME, CFBundleIdentifier = 'org.livingcode.examples.%s' % ID, NSHumanReadableCopyright = COPYRIGHT ) app_data = dict(script=SCRIPT, plist=plist) py2app_opt = dict(frameworks=['Renaissance.framework'],) options = dict(py2app=py2app_opt,) setup( data_files = DATA_FILES, app = [app_data], options = options, ) -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2488 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20041223/680feff0/smime.bin From bob at redivi.com Fri Dec 24 00:04:27 2004 From: bob at redivi.com (Bob Ippolito) Date: Fri Dec 24 00:04:58 2004 Subject: [Pythonmac-SIG] py2app standalone options In-Reply-To: <95763F56-5531-11D9-8131-0003939B59E8@livingcode.org> References: <8128F38C-686F-45F7-90C4-CB181B992AD1@mac.com> <95763F56-5531-11D9-8131-0003939B59E8@livingcode.org> Message-ID: On Dec 23, 2004, at 5:25 PM, Dethe Elza wrote: > With regards to refactoring setup.py files, here is what I've been > using for several different apps. It has evolved as I've found new > requirements. > > The only things I have to change from app to app (at this point) are > the bits in ALL_CAPS at the beginning. I've been meaning to factor > all of this into something like a function + .cfg, but haven't gotten > there yet, so I just copy this into a new project and edit the few > lines that change. > > HTH > > --Dethe > > > ''' > Run with: > % python setup.py py2app > ''' > from distutils.core import setup > import py2app > > NAME = 'Oblique Strategies' > SCRIPT = 'oblique.py' > VERSION = '0.3' > ICON = NAME > ID = 'oblique_strategies' > COPYRIGHT = 'Copyright 2004 Dethe Elza' > DATA_FILES = ['English.lproj', 'data', 'MainMenu.gsmarkup', > 'MainWindow.gsmarkup', 'Credits.html'] > > plist = dict( > CFBundleIconFile = ICON, > CFBundleName = NAME, > CFBundleShortVersionString = ' '.join([NAME, VERSION]), > CFBundleGetInfoString = NAME, > CFBundleExecutable = NAME, > CFBundleIdentifier = 'org.livingcode.examples.%s' % ID, > NSHumanReadableCopyright = COPYRIGHT > ) > > > app_data = dict(script=SCRIPT, plist=plist) > py2app_opt = dict(frameworks=['Renaissance.framework'],) > options = dict(py2app=py2app_opt,) > > setup( > data_files = DATA_FILES, > app = [app_data], > options = options, > ) This looks pretty good to me. I would put MainMenu.gsmarkup, MainWindow.gsmarkup, and Credits.html in English.lproj. -[NSBundle pathForResource:ofType:] and friends will look in localized directories.. so it saves you some typing and symlinks (in the case of an alias bundle). It's not really useful to set CFBundleExecutable. It doesn't matter what the executable's name is. It will default to the name of the script you give it. CFBundleName defaults to CFBundleExecutable, so if your script is named the same as your application you don't need to set this. CFBundleIcon will default to the CFBundleExecutable, so if you name your icon the same as your script and throw it in English.lproj, you don't need to set this. (reference py2app.apptemplate.plist_template and/or py2app.bundletemplate.plist_template to see this behavior for yourself) The copyright, bundle identifier, info strings, version, etc. are not defaulted to anything particularly useful.. so it is a good idea to set those in an application for general distribution. Since py2app doesn't really support multiple targets in a single setup(...) in a particularly useful way (and won't for some time, would require a hefty refactoring), you can make app = [SCRIPT] and add plist=plist to py2app_opt. -- For the plist template, in the future, it may be worthwhile to have some flag that can take a plist file and do PEP-292 on its string values . That way you can have a template plist file on-disk. I'm not sure precisely how this should work, but I'll probably look to Xcode for a friendly-ish way to do things. At some point, I may walk the module dependency graph to find direct dependencies in the objc module and do a little bytecode scanning to see if I can find "loadBundle" or "loadBundleFunctions" and automatically specify those as included frameworks. Alternatively, I might just make it necessary to put some kind of editor turd in the file like you have to do for text encoding (because that would work for ctypes dependencies too). That will likely happen at the same time PyObjC grows a smarter wrapper-generator that won't need to create extension modules as often (probably a PyObjC 1.3 feature). -bob From Jack.Jansen at cwi.nl Fri Dec 24 00:12:57 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Fri Dec 24 00:12:56 2004 Subject: [Pythonmac-SIG] Let's discuss MacPython distributions for january Message-ID: <2E7AFD45-5538-11D9-81BB-000D934FF6B4@cwi.nl> With the next version of Ambulant out the door and a whole week off (well, only from work, not from the kid or the wife:-) I'd like to get some work done on Python again. And with Python 2.3.5 and probably 2.4.1 imminent that seems to be good timing. Part of this email is highly technical, but part is (somewhat) end-user oriented, so feel free to comment only on the parts that interest you. In january I'd like to get two MacPythons out: - MacPython 2.4.1 (full installer for Panther, time permitting for Jaguar too) - MacPython 2.3 additions, version 3 The main feature of these is that they should coexist peacefully. With each other, and with user-built (or fink-installed, or whatever) Python 2.3.5 or 2.4.1. And MacPython 2.4.1 should coexist peacefully with an unmodified Apple Python 2.3 (possibly after making slight modifications to that 2.3 installation). More on this below. The second feature is that they'll finally have the newer version of Package Manager (or, actually, the underlying pimp module), which allows the maintainer (me:-) to have a single database for all 10.3.X releases of MacOSX. And, of course, there's bug fixes for things like the PythonIDE scripts folder bug and such. First question: what am I missing? Anything that should really go into either (or both) of these? Any serious bugs that you want fixed? Second question: I think the solution to peaceful coexistence is that all Pythons adopt the solution sketched in Bob's mail . That discussion is rather technical, but what it boils down to is that all Pythons (on 10.3) build their extensions with "-undefined dynamic_lookup", thereby forestalling that extensions inadvertently pull in a second, different, Python framework. Fixing this for 2.4.1 and 2.3.5 themselves is rather easy (and sketched in the mail mentioned above). Fixing this in the Apple-installed 2.3 is a bit more difficult, though. We can either modify it in-place (with admin permission) or do a complicated patch that Ronald came up with last year. While in general you should not muck with Apple-installed things I think that for this once I have a preference for the simple in-place modification over the slightly convoluted patch. Opinions, anyone? Then there's the question of how to get the patch in place, and here I need a bit of help. For people building Python 2.4.1 from source I can add a test (in "make frameworkinstall") for an unpatched Apple 2.3 and print a warning that people need to apply the patch. The MacPython 2.4.1 and 2.3-additions-version-3 installers could simply apply the patch. But I'm not sure what to do about Pythons installed by Fink and darwinports and other such packages. There's also the question of the form of the patch. What needs to be done (in case of the in-place modification) is a one-line change to /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/ config/Makefile. The patch could either be a shell script (containing a simple "ed" command to patch the file, or maybe a Python script so it can do some checking) or a .pkg file. The former is easiest for people building from source, the latter would also be a partial solution for fink users (partial, because it would allow them to apply the patch, but there's still no way to warn them that it is needed). Or should we do both? -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From mwh at python.net Fri Dec 24 00:28:23 2004 From: mwh at python.net (Michael Hudson) Date: Fri Dec 24 00:28:26 2004 Subject: [Pythonmac-SIG] Let's discuss MacPython distributions for january In-Reply-To: <2E7AFD45-5538-11D9-81BB-000D934FF6B4@cwi.nl> (Jack Jansen's message of "Fri, 24 Dec 2004 00:12:57 +0100") References: <2E7AFD45-5538-11D9-81BB-000D934FF6B4@cwi.nl> Message-ID: <2md5x0k31k.fsf@starship.python.net> Jack Jansen writes: > Second question: I think the solution to peaceful coexistence is that > all Pythons adopt the solution sketched in Bob's mail > 012292.html>. That discussion is rather technical, but what it boils > down to is that all Pythons (on 10.3) build their extensions with > "-undefined dynamic_lookup", thereby forestalling that extensions > inadvertently pull in a second, different, Python framework. Side question: do we know yet if the Python shipped with tiger will get this right? I think this is checkable by people not under NDA, but if not at least those people who have seen Tiger previews can think about it :) Cheers, mwh -- Sufficiently advanced political correctness is indistinguishable from irony. -- Erik Naggum From bob at redivi.com Fri Dec 24 00:47:40 2004 From: bob at redivi.com (Bob Ippolito) Date: Fri Dec 24 00:47:46 2004 Subject: [Pythonmac-SIG] Let's discuss MacPython distributions for january In-Reply-To: <2md5x0k31k.fsf@starship.python.net> References: <2E7AFD45-5538-11D9-81BB-000D934FF6B4@cwi.nl> <2md5x0k31k.fsf@starship.python.net> Message-ID: <083F3C35-553D-11D9-B983-000A9567635C@redivi.com> On Dec 23, 2004, at 6:28 PM, Michael Hudson wrote: > Jack Jansen writes: > >> Second question: I think the solution to peaceful coexistence is that >> all Pythons adopt the solution sketched in Bob's mail >> > 012292.html>. That discussion is rather technical, but what it boils >> down to is that all Pythons (on 10.3) build their extensions with >> "-undefined dynamic_lookup", thereby forestalling that extensions >> inadvertently pull in a second, different, Python framework. > > Side question: do we know yet if the Python shipped with tiger will > get this right? I think this is checkable by people not under NDA, > but if not at least those people who have seen Tiger previews can > think about it :) They got it right in the Python 2.3.3 that was posted along with the Darwin 8.0b1 (?) sources, I'm pretty sure I pointed this out several times. There is no reason to believe they will screw it up between then (WWDC) and now :) -bob From bob at redivi.com Fri Dec 24 01:01:22 2004 From: bob at redivi.com (Bob Ippolito) Date: Fri Dec 24 01:01:48 2004 Subject: [Pythonmac-SIG] Let's discuss MacPython distributions for january In-Reply-To: <2E7AFD45-5538-11D9-81BB-000D934FF6B4@cwi.nl> References: <2E7AFD45-5538-11D9-81BB-000D934FF6B4@cwi.nl> Message-ID: On Dec 23, 2004, at 6:12 PM, Jack Jansen wrote: > With the next version of Ambulant out the door and a whole week off > (well, only from work, not from the kid or the wife:-) I'd like to get > some work done on Python again. And with Python 2.3.5 and probably > 2.4.1 imminent that seems to be good timing. > > Part of this email is highly technical, but part is (somewhat) > end-user oriented, so feel free to comment only on the parts that > interest you. > > In january I'd like to get two MacPythons out: > - MacPython 2.4.1 (full installer for Panther, time permitting for > Jaguar too) > - MacPython 2.3 additions, version 3 There is the small issue of Zope X3 not being compatible with MacPython 2.3.0 .. so perhaps a 2.3.5 distro should also be considered, or considered instead of the additions? > The main feature of these is that they should coexist peacefully. With > each other, and with user-built (or fink-installed, or whatever) > Python 2.3.5 or 2.4.1. And MacPython 2.4.1 should coexist peacefully > with an unmodified Apple Python 2.3 (possibly after making slight > modifications to that 2.3 installation). More on this below. > > The second feature is that they'll finally have the newer version of > Package Manager (or, actually, the underlying pimp module), which > allows the maintainer (me:-) to have a single database for all 10.3.X > releases of MacOSX. Hopefully the GUI bugs are fixed too? unless.. > And, of course, there's bug fixes for things like the PythonIDE > scripts folder bug and such. > > First question: what am I missing? Anything that should really go into > either (or both) of these? Any serious bugs that you want fixed? What about distributing a version of Ronald's written-in-PyObjC PackageManager instead, and having MacPython 2.4.1 and MacPython 2.3.5 coming batteries included with PyObjC 1.2 plus py2app 1.7 (replacing BuildApplet with py2applet)? PyObjC is pretty damn stable software. I used 1.1 originally but now svn trunk from a few weeks ago (to address some potential issues with future versions of the objc runtime) in a shipping in-the-apple-store Mac application. I also don't think that between the schedules of Ronald, Bill, and myself, that we'll be releasing 1.3 shortly after 1.2. If this is done, it should of course be done in the site-packages dir, so that it can be reasonably upgraded at some point if py2app (definitely) or PyObjC (maybe) is updated between January and the next MacPython release. > Second question: I think the solution to peaceful coexistence is that > all Pythons adopt the solution sketched in Bob's mail > 012292.html>. That discussion is rather technical, but what it boils > down to is that all Pythons (on 10.3) build their extensions with > "-undefined dynamic_lookup", thereby forestalling that extensions > inadvertently pull in a second, different, Python framework. Added bonus is that the extensions will be cross-compatible with any of the Python runtime of the same API version (system, user-built, fink, dp, etc.). > Fixing this for 2.4.1 and 2.3.5 themselves is rather easy (and > sketched in the mail mentioned above). Fixing this in the > Apple-installed 2.3 is a bit more difficult, though. We can either > modify it in-place (with admin permission) or do a complicated patch > that Ronald came up with last year. While in general you should not > muck with Apple-installed things I think that for this once I have a > preference for the simple in-place modification over the slightly > convoluted patch. Opinions, anyone? > > Then there's the question of how to get the patch in place, and here I > need a bit of help. For people building Python 2.4.1 from source I can > add a test (in "make frameworkinstall") for an unpatched Apple 2.3 and > print a warning that people need to apply the patch. The MacPython > 2.4.1 and 2.3-additions-version-3 installers could simply apply the > patch. But I'm not sure what to do about Pythons installed by Fink and > darwinports and other such packages. > > There's also the question of the form of the patch. What needs to be > done (in case of the in-place modification) is a one-line change to > /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/config/Makefile. The patch could either be a shell script > (containing a simple "ed" command to patch the file, or maybe a Python > script so it can do some checking) or a .pkg file. The former is > easiest for people building from source, the latter would also be a > partial solution for fink users (partial, because it would allow them > to apply the patch, but there's still no way to warn them that it is > needed). Or should we do both? +1 for the administrator privileged in-place patch to 10.3.x's 2.3.0 (can/should be just an installer .pkg), the runtime hack is gross and this is a very controlled environment so I say let's just fix it in the right place. +1 for getting 2.4.1 and maybe 2.3.5 to build a usable destroot framework for Darwinports. +0 for any patches to 2.3.x explicitly for Fink or Darwinports. Darwinports uses -flat_namespace for 2.3.x, so that would have to be fixed too, which I'm sure has repercussions for people who already have Python 2.3.x installed and some modules built and also probably for other Portfiles. I don't know/care about Fink. This can be fixed on their own schedules by their own people once the patch is in 2.3.5 (if they decide to adopt a framework build). -bob From charles.hartman at conncoll.edu Fri Dec 24 01:01:50 2004 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Fri Dec 24 01:01:56 2004 Subject: [Pythonmac-SIG] Let's discuss MacPython distributions for january In-Reply-To: <2E7AFD45-5538-11D9-81BB-000D934FF6B4@cwi.nl> References: <2E7AFD45-5538-11D9-81BB-000D934FF6B4@cwi.nl> Message-ID: <02F45964-553F-11D9-B90F-000D933C27EA@conncoll.edu> 1. As a more or less perpetual newbie at this, much as I welcome the chance to upgrade, I cast my vote for a *reversible* change in the Apple-installed version. If I screw everything up, I'd like to be able to go back. Or, alternatively, make it impossible even for me to screw up. (Ha ha.) 2. Bravo! Bravo! Charles Hartman Professor of English, Poet in Residence http://cherry.conncoll.edu/cohar http://villex.blogspot.com On Dec 23, 2004, at 6:12 PM, Jack Jansen wrote: > Fixing this for 2.4.1 and 2.3.5 themselves is rather easy (and > sketched in the mail mentioned above). Fixing this in the > Apple-installed 2.3 is a bit more difficult, though. We can either > modify it in-place (with admin permission) or do a complicated patch > that Ronald came up with last year. While in general you should not > muck with Apple-installed things I think that for this once I have a > preference for the simple in-place modification over the slightly > convoluted patch. Opinions, anyone? From bob at redivi.com Fri Dec 24 02:13:47 2004 From: bob at redivi.com (Bob Ippolito) Date: Fri Dec 24 02:13:53 2004 Subject: [Pythonmac-SIG] Let's discuss MacPython distributions for january In-Reply-To: <02F45964-553F-11D9-B90F-000D933C27EA@conncoll.edu> References: <2E7AFD45-5538-11D9-81BB-000D934FF6B4@cwi.nl> <02F45964-553F-11D9-B90F-000D933C27EA@conncoll.edu> Message-ID: <1061A5B0-5549-11D9-B438-000A9567635C@redivi.com> On Dec 23, 2004, at 7:01 PM, Charles Hartman wrote: >> Fixing this for 2.4.1 and 2.3.5 themselves is rather easy (and >> sketched in the mail mentioned above). Fixing this in the >> Apple-installed 2.3 is a bit more difficult, though. We can either >> modify it in-place (with admin permission) or do a complicated patch >> that Ronald came up with last year. While in general you should not >> muck with Apple-installed things I think that for this once I have a >> preference for the simple in-place modification over the slightly >> convoluted patch. Opinions, anyone? > > As a more or less perpetual newbie at this, much as I welcome the > chance to upgrade, I cast my vote for a *reversible* change in the > Apple-installed version. If I screw everything up, I'd like to be able > to go back. Or, alternatively, make it impossible even for me to screw > up. (Ha ha.) It's pretty much impossible to screw up. Basically it should be an installer .pkg that simply tosses a single file to a specific place, replacing what was there. There is no need to revert to the original version of this file because that one is half-broken to begin with. -bob From ronaldoussoren at mac.com Fri Dec 24 10:13:42 2004 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Fri Dec 24 10:13:55 2004 Subject: [Pythonmac-SIG] Let's discuss MacPython distributions for january In-Reply-To: References: <2E7AFD45-5538-11D9-81BB-000D934FF6B4@cwi.nl> Message-ID: <1B5271AA-558C-11D9-85EE-000D93AD379E@mac.com> On 24-dec-04, at 1:01, Bob Ippolito wrote: > > +1 for the administrator privileged in-place patch to 10.3.x's 2.3.0 > (can/should be just an installer .pkg), the runtime hack is gross and > this is a very controlled environment so I say let's just fix it in > the right place. +1 from me too. IMHO it is unlikely that Apple will patch the Makefile in a future 10.3 release, which makes it safe to patch the file. One reason for using the hack I posted earlier is that it makes it possible to store include-files outside of /System while keeping them visible for disutils. It also changes the default install path for scripts. > > +1 for getting 2.4.1 and maybe 2.3.5 to build a usable destroot > framework for Darwinports. > > +0 for any patches to 2.3.x explicitly for Fink or Darwinports. > Darwinports uses -flat_namespace for 2.3.x, That's lame. Do you know why they do that? I'm -0 in doing patches for Fink or Darwinports. Ronald From bob at redivi.com Fri Dec 24 10:32:34 2004 From: bob at redivi.com (Bob Ippolito) Date: Fri Dec 24 10:57:57 2004 Subject: [Pythonmac-SIG] Let's discuss MacPython distributions for january In-Reply-To: <1B5271AA-558C-11D9-85EE-000D93AD379E@mac.com> References: <2E7AFD45-5538-11D9-81BB-000D934FF6B4@cwi.nl> <1B5271AA-558C-11D9-85EE-000D93AD379E@mac.com> Message-ID: On Dec 24, 2004, at 4:13 AM, Ronald Oussoren wrote: > On 24-dec-04, at 1:01, Bob Ippolito wrote: >> +0 for any patches to 2.3.x explicitly for Fink or Darwinports. >> Darwinports uses -flat_namespace for 2.3.x, > > That's lame. Do you know why they do that? Legacy from 10.1.x or 10.2.x support, probably. We definitely used "-undefined suppress" all over the place, on purpose, in the 10.1 days. Possibly my fault? I know I compiled a lot of things "-undefined suppress" in those days because it was the first way that I could make things (kinda) work. A lot of ignorance on my part, and not enough documentation on Apple's :) I think this month, or maybe last, marks three years of Mac use for me... Sometime in the Summer was 3 years of Python :) -bob From mwh at python.net Fri Dec 24 12:19:49 2004 From: mwh at python.net (Michael Hudson) Date: Fri Dec 24 12:19:50 2004 Subject: [Pythonmac-SIG] Let's discuss MacPython distributions for january In-Reply-To: <083F3C35-553D-11D9-B983-000A9567635C@redivi.com> (Bob Ippolito's message of "Thu, 23 Dec 2004 18:47:40 -0500") References: <2E7AFD45-5538-11D9-81BB-000D934FF6B4@cwi.nl> <2md5x0k31k.fsf@starship.python.net> <083F3C35-553D-11D9-B983-000A9567635C@redivi.com> Message-ID: <2m8y7oj63u.fsf@starship.python.net> Bob Ippolito writes: > On Dec 23, 2004, at 6:28 PM, Michael Hudson wrote: > >> Jack Jansen writes: >> >>> Second question: I think the solution to peaceful coexistence is that >>> all Pythons adopt the solution sketched in Bob's mail >>> >> 012292.html>. That discussion is rather technical, but what it boils >>> down to is that all Pythons (on 10.3) build their extensions with >>> "-undefined dynamic_lookup", thereby forestalling that extensions >>> inadvertently pull in a second, different, Python framework. >> >> Side question: do we know yet if the Python shipped with tiger will >> get this right? I think this is checkable by people not under NDA, >> but if not at least those people who have seen Tiger previews can >> think about it :) > > They got it right in the Python 2.3.3 that was posted along with the > Darwin 8.0b1 (?) sources, I'm pretty sure I pointed this out several > times. Quite possibly... > There is no reason to believe they will screw it up between then > (WWDC) and now :) Except that I tried to look for evidence of this in the WWDC source drop last night before posting and failed to find it... oh, is it in configure.ed? That seems a strange place to hang it, but oh well. Cheers, mwh -- It is never worth a first class man's time to express a majority opinion. By definition, there are plenty of others to do that. -- G. H. Hardy From hengist.podd at virgin.net Fri Dec 24 15:41:19 2004 From: hengist.podd at virgin.net (has) Date: Fri Dec 24 15:41:26 2004 Subject: [Pythonmac-SIG] [ann] appscript 0.9.0 Message-ID: Hi all, New versions of appscript, aem, osax and osaterminology released: http://freespace.virgin.net/hamish.sanderson/appscript.html Questions, suggestions, brickbats, etc. to the usual address. has -- http://freespace.virgin.net/hamish.sanderson/ From bob at redivi.com Fri Dec 24 18:55:40 2004 From: bob at redivi.com (Bob Ippolito) Date: Fri Dec 24 18:55:47 2004 Subject: [Pythonmac-SIG] Let's discuss MacPython distributions for january In-Reply-To: <2m8y7oj63u.fsf@starship.python.net> References: <2E7AFD45-5538-11D9-81BB-000D934FF6B4@cwi.nl> <2md5x0k31k.fsf@starship.python.net> <083F3C35-553D-11D9-B983-000A9567635C@redivi.com> <2m8y7oj63u.fsf@starship.python.net> Message-ID: <065DCCA0-55D5-11D9-A6A3-000A9567635C@redivi.com> On Dec 24, 2004, at 6:19 AM, Michael Hudson wrote: > Bob Ippolito writes: > >> On Dec 23, 2004, at 6:28 PM, Michael Hudson wrote: >> >>> Jack Jansen writes: >>> >>>> Second question: I think the solution to peaceful coexistence is >>>> that >>>> all Pythons adopt the solution sketched in Bob's mail >>>> >>> 012292.html>. That discussion is rather technical, but what it boils >>>> down to is that all Pythons (on 10.3) build their extensions with >>>> "-undefined dynamic_lookup", thereby forestalling that extensions >>>> inadvertently pull in a second, different, Python framework. >>> >>> Side question: do we know yet if the Python shipped with tiger will >>> get this right? I think this is checkable by people not under NDA, >>> but if not at least those people who have seen Tiger previews can >>> think about it :) >> >> They got it right in the Python 2.3.3 that was posted along with the >> Darwin 8.0b1 (?) sources, I'm pretty sure I pointed this out several >> times. > > Quite possibly... > >> There is no reason to believe they will screw it up between then >> (WWDC) and now :) > > Except that I tried to look for evidence of this in the WWDC source > drop last night before posting and failed to find it... oh, is it in > configure.ed? That seems a strange place to hang it, but oh well. I'm not going to bother looking again, but it was patched somewhere, and it linked extensions correctly. -bob From kid at kendermedia.com Sat Dec 25 03:08:10 2004 From: kid at kendermedia.com (Kevin Dangoor) Date: Sat Dec 25 03:08:16 2004 Subject: [Pythonmac-SIG] configure failing with Python 2.4 In-Reply-To: <5C64C36A-54FD-11D9-B983-000A9567635C@redivi.com> References: <41CAD3FB.30305@kendermedia.com> <41CAE2D6.2090503@kendermedia.com> <5C64C36A-54FD-11D9-B983-000A9567635C@redivi.com> Message-ID: <41CCCB8A.8010208@kendermedia.com> After trying to build a module today (and failing), I went searching around for the answer to this problem. It turns out that there are installation problems with older versions of Xcode. I had installed Xcode 1.1 from my Panther CDs. Downloading and installing Xcode 1.5 fixed the problem (and I've got Python 2.4 building in another window as I write this). Kevin Bob Ippolito wrote: > Reinstall Xcode and/or make sure you aren't using Fink or something > which may have installed an alternate compiler (make sure "which cc" > and "which gcc" point to /usr/bin). > > On Dec 23, 2004, at 10:23 AM, Kevin Dangoor wrote: > >> Err, while this might be enough info for someone to go on, I just >> realized that there's not much there... >> >> I'm running Mac OS 10.3.6. I have XCode/Developer Tools installed, >> though that didn't seem to make any difference. I even tried moving >> my .bashrc and .profile files out of the way to be sure that those >> weren't causing any grief. >> >> Kevin >> >> Kevin Dangoor wrote: >> >>> I'm thinking that I must be doing something simple wrong... >>> hopefully that's the case. >>> >>> I downloaded the Python 2.4 source and tried to run a basic >>> ./configure to see what I get. What I got was this error: >>> >>> checking for C++ compiler default output file name... configure: >>> error: C++ compiler cannot create executables >>> >>> which appears to be caused by >>> >>> configure:1772: c++ conftest.cc >&5 >>> ld: can't locate file for: -lcrt1.o >>> >>> While I'm sure I can track that down, I figured that I must be doing >>> something silly. Can anyone tell me what I'm missing? >> From mike at maibaum.org Sun Dec 26 00:01:05 2004 From: mike at maibaum.org (Michael Maibaum) Date: Sun Dec 26 00:01:09 2004 Subject: [Pythonmac-SIG] Let's discuss MacPython distributions for january In-Reply-To: References: <2E7AFD45-5538-11D9-81BB-000D934FF6B4@cwi.nl> <1B5271AA-558C-11D9-85EE-000D93AD379E@mac.com> Message-ID: <20041225230105.GA21169@remote.gene-hacker.net> On Fri, Dec 24, 2004 at 04:32:34AM -0500, Bob Ippolito wrote: >On Dec 24, 2004, at 4:13 AM, Ronald Oussoren wrote: > >>On 24-dec-04, at 1:01, Bob Ippolito wrote: >>>+0 for any patches to 2.3.x explicitly for Fink or Darwinports. >>>Darwinports uses -flat_namespace for 2.3.x, >> >>That's lame. Do you know why they do that? > >Legacy from 10.1.x or 10.2.x support, probably. We definitely used >"-undefined suppress" all over the place, on purpose, in the 10.1 days. > Possibly my fault? I know I compiled a lot of things "-undefined >suppress" in those days because it was the first way that I could make >things (kinda) work. A lot of ignorance on my part, and not enough >documentation on Apple's :) > >I think this month, or maybe last, marks three years of Mac use for >me... Sometime in the Summer was 3 years of Python :) I'm not that bothered about 2.3.x issues in DarwinPorts - but anything that makes 2.4 a better Mac and DarwinPorts citizen I'd be more than happy pushing to the dp side (all work on 2.3 issues, I just don't see them as comparibly important). I don't know enough about the internals of how MacPython builds to make useful suggestions, other than observing that building through a destroot is very broken for the 'extras' and somewhat broken for the core. Also prefix isn't totally obeyed. If you do prefix other than /usr/local python2.4, pythonw2.4, pydoc and symlinks to those end up in /usr/local and not the requested prefix. Michael From jo at johnochiltree.uklinux.net Sun Dec 26 13:45:46 2004 From: jo at johnochiltree.uklinux.net (John Ochiltree) Date: Sun Dec 26 13:45:57 2004 Subject: [Pythonmac-SIG] Python 2.4 on OS X 10.3.7 Message-ID: <0FF41D08-573C-11D9-824C-000D9352164A@johnochiltree.uklinux.net> I have successfully built and installed a framework version of python 2.4 using the source from python.org. However I cannot seem to be able to get readline working. It is installed on the system and is available in terminal windows and Apple's supplied python 2.3. I downloaded the gnu readline source and rebuilt/installed it and it seemed to work. I rebuilt python (adding --enable-readline , although I understand I should no longer have to do this) but still no success in python. Has anyone got any ideas John Ochiltree From hengist.podd at virgin.net Sun Dec 26 16:46:08 2004 From: hengist.podd at virgin.net (has) Date: Sun Dec 26 16:46:29 2004 Subject: [Pythonmac-SIG] py2app standalone options In-Reply-To: References: <8128F38C-686F-45F7-90C4-CB181B992AD1@mac.com> Message-ID: Bob Ippolito wrote: >>Not sure how: both are intended to build applications, and allow >>users to configure exactly how they're built. The only thing that >>differs is the workflow's order. > >One of py2app's goals is to integrate seamlessly with distutils and >to behave similarly to py2exe when it makes sense. That goal is >counter to making it suitable for inclusion into a GUI workflow, >unless that GUI's job is simply to piece together a setup.py script >(which is completely orthogonal to what py2app does). Distutils >isn't very good at pausing in the middle of a command, and py2app >executes as a single distutils command, therefore what you >specifically mentioned is not reasonable. Hmmm. I see your point. Perhaps somebody should tell the Disutils developers that MVC isn't just for Christmas? (Oh wait... I remember already sounding out the DU SIG - doing the canary-in-the-coalmine bit, as it were - but they seemed distinctly disinterested in rethinking its approach. Just grown too comfortable with their monolithic tower, I think.) >The goal for 0.2.0, which I think has already been achieved (sans >documentation), was to make it better than the alternatives for any >platform. When do you think we'll start seeing some formal documentation for py2app? >>Look at all this another way: in an ideal world, developers and >>their applications wouldn't need to deal with any of this >>dependency crap _at all_. Each app would merely list its >>requirements and the system would magically conjour up suitable >>components upon request. > >In order for that to happen, either every user will have to have >every version of every library already installed, or they would have >to have the newest version of every library already installed >(assuming that libraries would never be able to break backwards >compatibility). Hardly. All you need is a CPAN-style central repository and a runtime extension that knows how to look it up and download components on-demand. >You can already have that if you want it, but none of them are >perfect and none of them are suitable for the common user on Mac OS >X. Which is not to say that such a system could not be made suitable for the common user. All it needs is a will, and a really solid grasp of HCI (something OSS often isn't as strong on, but that's not insoluble either). >Why should an application developer even have to bother listing its >"requirements"? Developer shouldn't. That's what tools like modulegraph are for. >>>BTW. the GUI I'd like to see is a GUI that allows me to grafically >>>construct setup.py files. >> >>I think the biggest problem with setup.py files is that they're >>unnecessarily complicated. > >Honestly I can't see how you can really complain about setup.py >being "complicated": I assume Ronald was referring to setup.py in general, rather than to py2app's setup scripts (which don't lug around the gobs of static data that module/extension setup scripts do). ... Anyway, I think it's probably time this thread was cut loose; with MacPython 2.4 looming I think folk've got more useful stuff to be talking about right now. Will leave the last word to anyone that wants it. :) Regards, has -- http://freespace.virgin.net/hamish.sanderson/ From bob at redivi.com Sun Dec 26 20:20:57 2004 From: bob at redivi.com (Bob Ippolito) Date: Sun Dec 26 20:21:07 2004 Subject: [Pythonmac-SIG] py2app standalone options In-Reply-To: References: <8128F38C-686F-45F7-90C4-CB181B992AD1@mac.com> Message-ID: <4520D194-5773-11D9-97BB-000A9567635C@redivi.com> On Dec 26, 2004, at 10:46 AM, has wrote: > Bob Ippolito wrote: > >> The goal for 0.2.0, which I think has already been achieved (sans >> documentation), was to make it better than the alternatives for any >> platform. > > When do you think we'll start seeing some formal documentation for > py2app? Write some and I'll include it. Right now the only documentation I'm working on is PyObjC, which does include some py2app related documentation. >>> Look at all this another way: in an ideal world, developers and >>> their applications wouldn't need to deal with any of this dependency >>> crap _at all_. Each app would merely list its requirements and the >>> system would magically conjour up suitable components upon request. >> >> In order for that to happen, either every user will have to have >> every version of every library already installed, or they would have >> to have the newest version of every library already installed >> (assuming that libraries would never be able to break backwards >> compatibility). > > Hardly. All you need is a CPAN-style central repository and a runtime > extension that knows how to look it up and download components > on-demand. That doesn't fix the multiple versions problem. >> You can already have that if you want it, but none of them are >> perfect and none of them are suitable for the common user on Mac OS >> X. > > Which is not to say that such a system could not be made suitable for > the common user. All it needs is a will, and a really solid grasp of > HCI (something OSS often isn't as strong on, but that's not insoluble > either). It takes more than knowing how and wanting to do something to make it happen :) -bob From ronaldoussoren at mac.com Sun Dec 26 21:27:45 2004 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Sun Dec 26 21:27:49 2004 Subject: [Pythonmac-SIG] py2app standalone options In-Reply-To: References: <8128F38C-686F-45F7-90C4-CB181B992AD1@mac.com> Message-ID: <9A179E46-577C-11D9-85EE-000D93AD379E@mac.com> On 26-dec-04, at 16:46, has wrote: >>> I think the biggest problem with setup.py files is that they're >>> unnecessarily complicated. >> >> Honestly I can't see how you can really complain about setup.py being >> "complicated": > > I assume Ronald was referring to setup.py in general, rather than to > py2app's setup scripts (which don't lug around the gobs of static data > that module/extension setup scripts do). I was referring to the poor souls who think that you cannot program without and IDE :-). Ronald From Jack.Jansen at cwi.nl Sun Dec 26 22:09:16 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Sun Dec 26 22:09:09 2004 Subject: [Pythonmac-SIG] Let's discuss MacPython distributions for january In-Reply-To: References: <2E7AFD45-5538-11D9-81BB-000D934FF6B4@cwi.nl> Message-ID: <6680AAB2-5782-11D9-81BB-000D934FF6B4@cwi.nl> On 24-dec-04, at 1:01, Bob Ippolito wrote: >> In january I'd like to get two MacPythons out: >> - MacPython 2.4.1 (full installer for Panther, time permitting for >> Jaguar too) >> - MacPython 2.3 additions, version 3 > > There is the small issue of Zope X3 not being compatible with > MacPython 2.3.0 .. so perhaps a 2.3.5 distro should also be > considered, or considered instead of the additions? Well, I definitely want a version 3 of the additions, to replace the current one. A 2.3.5 MacPython distribution wouldn't tie in with Apple's Python. But is there any reason to have the whole MacPython stuff (toolbox modules, etc) to run Zope? Because if there isn't then a simple Python 2.3.5 (non-framework, standard unix build, installed into /usr/local) should do the trick. Actually, if we get everything right in the source tree then the darwinports or fink distribution should work just fine. >> The second feature is that they'll finally have the newer version of >> Package Manager (or, actually, the underlying pimp module), which >> allows the maintainer (me:-) to have a single database for all 10.3.X >> releases of MacOSX. > > Hopefully the GUI bugs are fixed too? They should be. But could you check in the bug database whether there are any still open, please? > What about distributing a version of Ronald's written-in-PyObjC > PackageManager instead, and having MacPython 2.4.1 and MacPython 2.3.5 > coming batteries included with PyObjC 1.2 plus py2app 1.7 (replacing > BuildApplet with py2applet)? Later, later. First I want to get distributions out that are pretty similar to what we have now, but with the problems (conflicts when building plugin modules, endless hassle to keep PackMan database up to date) fixed. > +0 for any patches to 2.3.x explicitly for Fink or Darwinports. Not specifically for Fink or Darwinports, but I want to get the -undefined dynamic_lookup fix into the source distributions for 2.3.x (and 2.4.x), so fink and darwinports should pick it up automatically. Unless they have their own fixes, and in that case their fixes are either just as good, or else we can scald the in public:-) -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From Jack.Jansen at cwi.nl Mon Dec 27 00:15:25 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Mon Dec 27 00:15:30 2004 Subject: [Pythonmac-SIG] Debuggers wanted for fixup script Message-ID: <0624E3AE-5794-11D9-81BB-000D934FF6B4@cwi.nl> I've added a script Mac/OSX/fixapplepython23.py to the CVS repository, only to the trunk for now, that will inspect and fix the Apple-installed Python 2.3 as per what we discussed here (making extensions build in a way that works, even if newer Pythons are installed). I'd like it if people could test the script, and test whether they see the warning (you need to run this script) if they do a framework install of 2.5a0 if their apple-python needs patching. Also, if people could run this on OSX 10.2 and 10.4, just to see that it doesn't cause any problems there, would be nice. The script does all sorts of error-checking (which hasn't been tested yet, of course:-), and I'm actually thinking of having the patch-installer (also discussed previously, this is a .pkg installer that will fix Apple-installed Python for people not building from source) also simply run this script, in stead of bluntly installing a modified copy of lib/config/Makefile. Opinions on this? -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From bob at redivi.com Mon Dec 27 06:28:15 2004 From: bob at redivi.com (Bob Ippolito) Date: Mon Dec 27 06:28:22 2004 Subject: [Pythonmac-SIG] Debuggers wanted for fixup script In-Reply-To: <0624E3AE-5794-11D9-81BB-000D934FF6B4@cwi.nl> References: <0624E3AE-5794-11D9-81BB-000D934FF6B4@cwi.nl> Message-ID: <1BC5C582-57C8-11D9-97BB-000A9567635C@redivi.com> On Dec 26, 2004, at 6:15 PM, Jack Jansen wrote: > I've added a script Mac/OSX/fixapplepython23.py to the CVS repository, > only to the trunk for now, that will inspect and fix the > Apple-installed Python 2.3 as per what we discussed here (making > extensions build in a way that works, even if newer Pythons are > installed). > > I'd like it if people could test the script, and test whether they see > the warning (you need to run this script) if they do a framework > install of 2.5a0 if their apple-python needs patching. > > Also, if people could run this on OSX 10.2 and 10.4, just to see that > it doesn't cause any problems there, would be nice. > > The script does all sorts of error-checking (which hasn't been tested > yet, of course:-), and I'm actually thinking of having the > patch-installer (also discussed previously, this is a .pkg installer > that will fix Apple-installed Python for people not building from > source) also simply run this script, in stead of bluntly installing a > modified copy of lib/config/Makefile. Opinions on this? Bluntly installing the Makefile will only be a problem if the user has an incorrect version of Mac OS X. The installer should check the version of the OS to be exactly 10.3.x as a precondition. This check can be done entirely in the Info.plist using functionality introduced in the Mac OS X 10.3 installer. There is no reason to have a script that does this, and error checking doesn't sound very useful as it will probably report "false positives" for people who have modified the Makefile in a similar but weaker or even mildly incorrect manner, but would still benefit from having the "officially patched" version. -bob From Jack.Jansen at cwi.nl Mon Dec 27 14:08:23 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Mon Dec 27 14:08:28 2004 Subject: [Pythonmac-SIG] More testers needed: Fix installer Message-ID: <63280D1C-5808-11D9-81BB-000D934FF6B4@cwi.nl> Ok, Bob, you win:-) I've created an installer package that replaces the Makefile after a simple test that you're actually running 10.3 and have that Makefile in the right place (i.e. didn't mess too much with your installation). If people could test this that'd be nice. Again, I'm especially interested in feedback from people running 10.2 or 10.4 (where the installer should refuse to run, with a decent message). You can find the package at . -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From mwh at python.net Mon Dec 27 15:04:34 2004 From: mwh at python.net (Michael Hudson) Date: Mon Dec 27 15:04:37 2004 Subject: [Pythonmac-SIG] More testers needed: Fix installer In-Reply-To: <63280D1C-5808-11D9-81BB-000D934FF6B4@cwi.nl> (Jack Jansen's message of "Mon, 27 Dec 2004 14:08:23 +0100") References: <63280D1C-5808-11D9-81BB-000D934FF6B4@cwi.nl> Message-ID: <2msm5rj0r1.fsf@starship.python.net> Jack Jansen writes: > Ok, Bob, you win:-) > > I've created an installer package that replaces the Makefile after a > simple test that you're actually running 10.3 and have that Makefile > in the right place (i.e. didn't mess too much with your installation). > > If people could test this that'd be nice. Again, I'm especially > interested in feedback from people running 10.2 or 10.4 (where the > installer should refuse to run, with a decent message). > > You can find the package at > . Indeed you can, and it seems to work (tm) on Panther here, but I'm *reasonably* sure you have chosen the wrong name for the package :) Cheers, mwh -- ZAPHOD: Listen three eyes, don't try to outweird me, I get stranger things than you free with my breakfast cereal. -- The Hitch-Hikers Guide to the Galaxy, Episode 7 From Jack.Jansen at cwi.nl Mon Dec 27 16:40:44 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Mon Dec 27 16:40:53 2004 Subject: [Pythonmac-SIG] More testers needed: Fix installer In-Reply-To: <2msm5rj0r1.fsf@starship.python.net> References: <63280D1C-5808-11D9-81BB-000D934FF6B4@cwi.nl> <2msm5rj0r1.fsf@starship.python.net> Message-ID: On 27-dec-04, at 15:04, Michael Hudson wrote: > Indeed you can, and it seems to work (tm) on Panther here, but I'm > *reasonably* sure you have chosen the wrong name for the package :) Yeah, consider that a working title. I may call it "The Installer that makes Apple-Installed Python on 10.3 build correct extension modules even after installing newer framework builds of Python". But suggestions for shorter names are welcome... -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From jo at johnochiltree.uklinux.net Mon Dec 27 16:53:31 2004 From: jo at johnochiltree.uklinux.net (John Ochiltree) Date: Mon Dec 27 16:53:44 2004 Subject: [Pythonmac-SIG] Python 2.4 on OS X 10.3.7 In-Reply-To: <41CFF752.901@anubics.org> References: <0FF41D08-573C-11D9-824C-000D9352164A@johnochiltree.uklinux.net> <41CFF752.901@anubics.org> Message-ID: <74C887B8-581F-11D9-A009-000D9352164A@johnochiltree.uklinux.net> On 27 Dec 2004, at 11:51, Enrico Franchi wrote: > John Ochiltree wrote: > >> . I rebuilt python (adding --enable-readline , although I understand >> I should no longer have to do this) but still no success in python. >> > > I specified in CFLAGS where are the libs and includes (-L and -I for > gcc). > I used readline from darwinports, so i set CFLAGS to -L/opt/local/lib > -I/opt/local/include > and it worked. > > Thanks, but where do I set these CFLAG values? Do I have to edit Modules/Setup? Sorry to be so dumb! From mww at opendarwin.org Mon Dec 27 17:02:31 2004 From: mww at opendarwin.org (Markus Weissmann) Date: Mon Dec 27 17:02:51 2004 Subject: [Pythonmac-SIG] More testers needed: Fix installer In-Reply-To: <63280D1C-5808-11D9-81BB-000D934FF6B4@cwi.nl> References: <63280D1C-5808-11D9-81BB-000D934FF6B4@cwi.nl> Message-ID: On 27. Dec 2004, at 14:08 Uhr, Jack Jansen wrote: > Ok, Bob, you win:-) > > I've created an installer package that replaces the Makefile after a > simple test that you're actually running 10.3 and have that Makefile > in the right place (i.e. didn't mess too much with your installation). > > If people could test this that'd be nice. Again, I'm especially > interested in feedback from people running 10.2 or 10.4 (where the > installer should refuse to run, with a decent message). > hmmm... I think someone told me that it (successfully) refused to install on some unknown, unreleased OS; -Markus > You can find the package at > . > -- > Jack Jansen, , http://www.cwi.nl/~jack > If I can't dance I don't want to be part of your revolution -- Emma > Goldman > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > --- Markus W. Weissmann http://www.mweissmann.de/ http://www.opendarwin.org/~mww/ From mwh at python.net Mon Dec 27 17:31:57 2004 From: mwh at python.net (Michael Hudson) Date: Mon Dec 27 17:32:01 2004 Subject: [Pythonmac-SIG] More testers needed: Fix installer In-Reply-To: (Jack Jansen's message of "Mon, 27 Dec 2004 16:40:44 +0100") References: <63280D1C-5808-11D9-81BB-000D934FF6B4@cwi.nl> <2msm5rj0r1.fsf@starship.python.net> Message-ID: <2moegfitxe.fsf@starship.python.net> Jack Jansen writes: > On 27-dec-04, at 15:04, Michael Hudson wrote: >> Indeed you can, and it seems to work (tm) on Panther here, but I'm >> *reasonably* sure you have chosen the wrong name for the package :) > > Yeah, consider that a working title. I may call it "The Installer that > makes > Apple-Installed Python on 10.3 build correct extension modules even > after installing > newer framework builds of Python". > > But suggestions for shorter names are welcome... But 10.3 is Panther, not Jaguar, right? Cheers, mwh -- There's an aura of unholy black magic about CLISP. It works, but I have no idea how it does it. I suspect there's a goat involved somewhere. -- Johann Hibschman, comp.lang.scheme From bob at redivi.com Mon Dec 27 17:38:44 2004 From: bob at redivi.com (Bob Ippolito) Date: Mon Dec 27 17:38:50 2004 Subject: [Pythonmac-SIG] More testers needed: Fix installer In-Reply-To: <2moegfitxe.fsf@starship.python.net> References: <63280D1C-5808-11D9-81BB-000D934FF6B4@cwi.nl> <2msm5rj0r1.fsf@starship.python.net> <2moegfitxe.fsf@starship.python.net> Message-ID: On Dec 27, 2004, at 11:31 AM, Michael Hudson wrote: > Jack Jansen writes: > >> On 27-dec-04, at 15:04, Michael Hudson wrote: >>> Indeed you can, and it seems to work (tm) on Panther here, but I'm >>> *reasonably* sure you have chosen the wrong name for the package :) >> >> Yeah, consider that a working title. I may call it "The Installer that >> makes >> Apple-Installed Python on 10.3 build correct extension modules even >> after installing >> newer framework builds of Python". >> >> But suggestions for shorter names are welcome... > > But 10.3 is Panther, not Jaguar, right? Yes. -bob From bob at redivi.com Mon Dec 27 17:44:13 2004 From: bob at redivi.com (Bob Ippolito) Date: Mon Dec 27 17:44:32 2004 Subject: [Pythonmac-SIG] More testers needed: Fix installer In-Reply-To: <63280D1C-5808-11D9-81BB-000D934FF6B4@cwi.nl> References: <63280D1C-5808-11D9-81BB-000D934FF6B4@cwi.nl> Message-ID: <89EF1AA8-5826-11D9-A79F-000A9567635C@redivi.com> On Dec 27, 2004, at 8:08 AM, Jack Jansen wrote: > Ok, Bob, you win:-) > > I've created an installer package that replaces the Makefile after a > simple test that you're actually running 10.3 and have that Makefile > in the right place (i.e. didn't mess too much with your installation). > > If people could test this that'd be nice. Again, I'm especially > interested in feedback from people running 10.2 or 10.4 (where the > installer should refuse to run, with a decent message). > > You can find the package at > . The Makefile is missing the MACOSX_DEPLOYMENT_TARGET=10.3 before the $(CC) .. which means that for most people, it won't compile extension modules, because not everyone has this set in their login scripts.. IIRC, The tradeoff is that distutils is *extremely* stupid and will no longer compile c++ modules correctly because it expects the compiler to be the first word in the variable expanded LDSHARED. This may or may not also be a problem with SciPy distutils. -bob From mwh at python.net Mon Dec 27 17:47:11 2004 From: mwh at python.net (Michael Hudson) Date: Mon Dec 27 17:47:15 2004 Subject: [Pythonmac-SIG] More testers needed: Fix installer In-Reply-To: References: <63280D1C-5808-11D9-81BB-000D934FF6B4@cwi.nl> <2msm5rj0r1.fsf@starship.python.net> <2moegfitxe.fsf@starship.python.net> Message-ID: On 27 Dec 2004, at 16:38, Bob Ippolito wrote: > On Dec 27, 2004, at 11:31 AM, Michael Hudson wrote: >> But 10.3 is Panther, not Jaguar, right? > > Yes. That was rhetorical :) I'm not being completely thick, am I? The file should surely be called PantherPythonFix.dmg. Cheers, mwh From bob at redivi.com Mon Dec 27 17:50:22 2004 From: bob at redivi.com (Bob Ippolito) Date: Mon Dec 27 17:50:36 2004 Subject: [Pythonmac-SIG] More testers needed: Fix installer In-Reply-To: References: <63280D1C-5808-11D9-81BB-000D934FF6B4@cwi.nl> <2msm5rj0r1.fsf@starship.python.net> <2moegfitxe.fsf@starship.python.net> Message-ID: <66548888-5827-11D9-A79F-000A9567635C@redivi.com> On Dec 27, 2004, at 11:47 AM, Michael Hudson wrote: > On 27 Dec 2004, at 16:38, Bob Ippolito wrote: >> On Dec 27, 2004, at 11:31 AM, Michael Hudson wrote: >>> But 10.3 is Panther, not Jaguar, right? >> >> Yes. > > That was rhetorical :) > > I'm not being completely thick, am I? The file should surely be > called PantherPythonFix.dmg. Yeah, you are correct. Maybe while we're at it, we should also patch Info.plist. For this particular build, Python.framework has a CFBundleVersion and CFBundleShortVersionString of 2.2 :) -bob From ronaldoussoren at mac.com Mon Dec 27 17:59:02 2004 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Mon Dec 27 17:59:09 2004 Subject: [Pythonmac-SIG] More testers needed: Fix installer In-Reply-To: <66548888-5827-11D9-A79F-000A9567635C@redivi.com> References: <63280D1C-5808-11D9-81BB-000D934FF6B4@cwi.nl> <2msm5rj0r1.fsf@starship.python.net> <2moegfitxe.fsf@starship.python.net> <66548888-5827-11D9-A79F-000A9567635C@redivi.com> Message-ID: <9C1EA488-5828-11D9-85EE-000D93AD379E@mac.com> On 27-dec-04, at 17:50, Bob Ippolito wrote: > > On Dec 27, 2004, at 11:47 AM, Michael Hudson wrote: > >> On 27 Dec 2004, at 16:38, Bob Ippolito wrote: >>> On Dec 27, 2004, at 11:31 AM, Michael Hudson wrote: >>>> But 10.3 is Panther, not Jaguar, right? >>> >>> Yes. >> >> That was rhetorical :) >> >> I'm not being completely thick, am I? The file should surely be >> called PantherPythonFix.dmg. > > Yeah, you are correct. > > Maybe while we're at it, we should also patch Info.plist. For this > particular build, Python.framework has a CFBundleVersion and > CFBundleShortVersionString of 2.2 :) How bad is that? That is, other than being ugly? Ronald From bob at redivi.com Mon Dec 27 18:05:23 2004 From: bob at redivi.com (Bob Ippolito) Date: Mon Dec 27 18:05:29 2004 Subject: [Pythonmac-SIG] More testers needed: Fix installer In-Reply-To: <9C1EA488-5828-11D9-85EE-000D93AD379E@mac.com> References: <63280D1C-5808-11D9-81BB-000D934FF6B4@cwi.nl> <2msm5rj0r1.fsf@starship.python.net> <2moegfitxe.fsf@starship.python.net> <66548888-5827-11D9-A79F-000A9567635C@redivi.com> <9C1EA488-5828-11D9-85EE-000D93AD379E@mac.com> Message-ID: <7F0DC1F9-5829-11D9-A79F-000A9567635C@redivi.com> On Dec 27, 2004, at 11:59 AM, Ronald Oussoren wrote: > On 27-dec-04, at 17:50, Bob Ippolito wrote: > >> >> On Dec 27, 2004, at 11:47 AM, Michael Hudson wrote: >> >>> On 27 Dec 2004, at 16:38, Bob Ippolito wrote: >>>> On Dec 27, 2004, at 11:31 AM, Michael Hudson wrote: >>>>> But 10.3 is Panther, not Jaguar, right? >>>> >>>> Yes. >>> >>> That was rhetorical :) >>> >>> I'm not being completely thick, am I? The file should surely be >>> called PantherPythonFix.dmg. >> >> Yeah, you are correct. >> >> Maybe while we're at it, we should also patch Info.plist. For this >> particular build, Python.framework has a CFBundleVersion and >> CFBundleShortVersionString of 2.2 :) > > How bad is that? That is, other than being ugly? Obviously not very, but Installer as of Mac OS X 10.3 has a requirements scheme that allows you to read keys from Info.plist bundles, so it might come in handy to keep this file synchronized with what it actually should be. It would also be an easy way to detect whether or not it has been patched. -bob From ronaldoussoren at mac.com Mon Dec 27 18:09:32 2004 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Mon Dec 27 18:09:37 2004 Subject: [Pythonmac-SIG] More testers needed: Fix installer In-Reply-To: <89EF1AA8-5826-11D9-A79F-000A9567635C@redivi.com> References: <63280D1C-5808-11D9-81BB-000D934FF6B4@cwi.nl> <89EF1AA8-5826-11D9-A79F-000A9567635C@redivi.com> Message-ID: <13B7A86E-582A-11D9-85EE-000D93AD379E@mac.com> On 27-dec-04, at 17:44, Bob Ippolito wrote: > > On Dec 27, 2004, at 8:08 AM, Jack Jansen wrote: > >> Ok, Bob, you win:-) >> >> I've created an installer package that replaces the Makefile after a >> simple test that you're actually running 10.3 and have that Makefile >> in the right place (i.e. didn't mess too much with your >> installation). >> >> If people could test this that'd be nice. Again, I'm especially >> interested in feedback from people running 10.2 or 10.4 (where the >> installer should refuse to run, with a decent message). >> >> You can find the package at >> . > > The Makefile is missing the MACOSX_DEPLOYMENT_TARGET=10.3 before the > $(CC) .. which means that for most people, it won't compile extension > modules, because not everyone has this set in their login scripts.. > > IIRC, The tradeoff is that distutils is *extremely* stupid and will no > longer compile c++ modules correctly because it expects the compiler > to be the first word in the variable expanded LDSHARED. This may or > may not also be a problem with SciPy distutils. I don't think this can be fixed without patching distutils. The patch shouldn't be too hard, but it may be too close to a 2.3.5 release to get it in there. Ronald From bob at redivi.com Mon Dec 27 18:25:01 2004 From: bob at redivi.com (Bob Ippolito) Date: Mon Dec 27 18:25:36 2004 Subject: [Pythonmac-SIG] More testers needed: Fix installer In-Reply-To: <13B7A86E-582A-11D9-85EE-000D93AD379E@mac.com> References: <63280D1C-5808-11D9-81BB-000D934FF6B4@cwi.nl> <89EF1AA8-5826-11D9-A79F-000A9567635C@redivi.com> <13B7A86E-582A-11D9-85EE-000D93AD379E@mac.com> Message-ID: <3D542B0E-582C-11D9-A79F-000A9567635C@redivi.com> On Dec 27, 2004, at 12:09 PM, Ronald Oussoren wrote: > > On 27-dec-04, at 17:44, Bob Ippolito wrote: > >> >> On Dec 27, 2004, at 8:08 AM, Jack Jansen wrote: >> >>> Ok, Bob, you win:-) >>> >>> I've created an installer package that replaces the Makefile after a >>> simple test that you're actually running 10.3 and have that Makefile >>> in the right place (i.e. didn't mess too much with your >>> installation). >>> >>> If people could test this that'd be nice. Again, I'm especially >>> interested in feedback from people running 10.2 or 10.4 (where the >>> installer should refuse to run, with a decent message). >>> >>> You can find the package at >>> . >> >> The Makefile is missing the MACOSX_DEPLOYMENT_TARGET=10.3 before the >> $(CC) .. which means that for most people, it won't compile extension >> modules, because not everyone has this set in their login scripts.. >> >> IIRC, The tradeoff is that distutils is *extremely* stupid and will >> no longer compile c++ modules correctly because it expects the >> compiler to be the first word in the variable expanded LDSHARED. >> This may or may not also be a problem with SciPy distutils. > > I don't think this can be fixed without patching distutils. The patch > shouldn't be too hard, but it may be too close to a 2.3.5 release to > get it in there. Correct, however, it looks like Jack has already patched 2.5 so that it will set MACOSX_DEPLOYMENT_TARGET to the configure time value if not already set, so it can be injected into 2.3.0 with this pkg fix and backported to 2.4.1 and maybe 2.3.5. -bob From Chris.Barker at noaa.gov Mon Dec 27 19:27:58 2004 From: Chris.Barker at noaa.gov (Chris Barker) Date: Mon Dec 27 19:31:57 2004 Subject: [Pythonmac-SIG] The versioning question... In-Reply-To: <4520D194-5773-11D9-97BB-000A9567635C@redivi.com> References: <8128F38C-686F-45F7-90C4-CB181B992AD1@mac.com> <4520D194-5773-11D9-97BB-000A9567635C@redivi.com> Message-ID: <41D0542E.9000404@noaa.gov> Bob Ippolito wrote: > That doesn't fix the multiple versions problem. This is a big issue that the core Pythonistas don't seem to be interested in addressing. It's odd, because I think it's a no-brainer that python modules need to be versioned, and there needs to be a way to have multiple versions co-existing and user (that is code) selectable. They are just like dynamic libraries in this regard. I think that's one reason Py2App and the like are so necessary now, it's the equivalent of statically linking an app. Particularly if Bob's idea of including PyObjC with MacPython gets implemented, it would be great to have a versioning system in place for it, so people could count on it being there, and not breaking apps that use when a new version comes out. Robin has added versioning to the latest wxPython, and I. for one am ecstatic. It works great for me. I am generally using 2.5.3, but have 2.4.2 installed, and a number of my apps depend on it (on Linux anyway, it's pretty useless on OS-X) It's great to be able to put: import wxversion wxversion.select("2.4") At the top of my apps, and know that they'll use the version of wxPython I tested against. Anyway, just a rant, but I do think something like this should be done for any major packages that come with MacPython, like PyObjC. It would be even better if there were a standard, Python-wide approach, but my read of comp.lang.python tells me it ain't gonna happen. Let's keep in mind how annoyed we all are that Apple supplied a python that makes it difficult to install a newer python without breaking things. Why should we not have the same standard for packages? -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov From bob at redivi.com Mon Dec 27 19:47:36 2004 From: bob at redivi.com (Bob Ippolito) Date: Mon Dec 27 19:47:56 2004 Subject: [Pythonmac-SIG] The versioning question... In-Reply-To: <41D0542E.9000404@noaa.gov> References: <8128F38C-686F-45F7-90C4-CB181B992AD1@mac.com> <4520D194-5773-11D9-97BB-000A9567635C@redivi.com> <41D0542E.9000404@noaa.gov> Message-ID: On Dec 27, 2004, at 1:27 PM, Chris Barker wrote: > Bob Ippolito wrote: >> That doesn't fix the multiple versions problem. > > This is a big issue that the core Pythonistas don't seem to be > interested in addressing. It's odd, because I think it's a no-brainer > that python modules need to be versioned, and there needs to be a way > to have multiple versions co-existing and user (that is code) > selectable. They are just like dynamic libraries in this regard. I > think that's one reason Py2App and the like are so necessary now, it's > the equivalent of statically linking an app. > > Particularly if Bob's idea of including PyObjC with MacPython gets > implemented, it would be great to have a versioning system in place > for it, so people could count on it being there, and not breaking apps > that use when a new version comes out. PyObjC is pretty good about maintaining backwards compatibility.. there's still some garbage in there like objc.runtime that nobody should be using anymore :) > Robin has added versioning to the latest wxPython, and I. for one am > ecstatic. It works great for me. I am generally using 2.5.3, but have > 2.4.2 installed, and a number of my apps depend on it (on Linux > anyway, it's pretty useless on OS-X) > > It's great to be able to put: > > import wxversion > wxversion.select("2.4") > > At the top of my apps, and know that they'll use the version of > wxPython I tested against. > > Anyway, just a rant, but I do think something like this should be done > for any major packages that come with MacPython, like PyObjC. > > It would be even better if there were a standard, Python-wide > approach, but my read of comp.lang.python tells me it ain't gonna > happen. I don't particularly like this approach, it doesn't solve any problems I've ever had, and it confuses stuff like py2app. You can still only use one version of wxPython per Python process. For an application, it's pretty easy to have it set a particular path on startup or include a local copy of its dependencies (a la py2app). The only "real" solution is with namespaces, like importing wx2_4 instead of wx, since extensions are effectively process-global.. but that is an obvious maintenance problem. > Let's keep in mind how annoyed we all are that Apple supplied a python > that makes it difficult to install a newer python without breaking > things. Why should we not have the same standard for packages? It's not really their fault that Python had bugs when they built it.. would've been nice if they were willing to upgrade, though. -bob From Jack.Jansen at cwi.nl Mon Dec 27 20:46:36 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Mon Dec 27 20:46:40 2004 Subject: [Pythonmac-SIG] More testers needed: Fix installer In-Reply-To: References: <63280D1C-5808-11D9-81BB-000D934FF6B4@cwi.nl> <2msm5rj0r1.fsf@starship.python.net> <2moegfitxe.fsf@starship.python.net> Message-ID: <04FF8425-5840-11D9-81BB-000D934FF6B4@cwi.nl> On 27-dec-04, at 17:47, Michael Hudson wrote: > On 27 Dec 2004, at 16:38, Bob Ippolito wrote: >> On Dec 27, 2004, at 11:31 AM, Michael Hudson wrote: >>> But 10.3 is Panther, not Jaguar, right? >> >> Yes. > > That was rhetorical :) > > I'm not being completely thick, am I? The file should surely be > called PantherPythonFix.dmg. Yes, yes, yes, yes, yes..... You have now all made your point, I mixed my cats up:-) Sorry about that, -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From Jack.Jansen at cwi.nl Mon Dec 27 20:53:20 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Mon Dec 27 20:53:22 2004 Subject: [Pythonmac-SIG] More testers needed: Fix installer In-Reply-To: <89EF1AA8-5826-11D9-A79F-000A9567635C@redivi.com> References: <63280D1C-5808-11D9-81BB-000D934FF6B4@cwi.nl> <89EF1AA8-5826-11D9-A79F-000A9567635C@redivi.com> Message-ID: On 27-dec-04, at 17:44, Bob Ippolito wrote: >> You can find the package at >> . > > The Makefile is missing the MACOSX_DEPLOYMENT_TARGET=10.3 before the > $(CC) .. which means that for most people, it won't compile extension > modules, because not everyone has this set in their login scripts.. Ah, forgot about that one, thanks! I'll pull the installer, and I'll create a new one tomorrow (with a different name:-). The same problem holds for the fixapplepython script, so I'll fix that one too. What would be the easiest fix for 2.3.5: backporting the distutils fixes (so it'll set MACOSX_DEPLOYMENT_TARGET) or simply setting that variable in the $(LD) macro (through configure)? -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From eric.nieuwland at xs4all.nl Mon Dec 27 22:30:32 2004 From: eric.nieuwland at xs4all.nl (Eric Nieuwland) Date: Mon Dec 27 22:30:38 2004 Subject: [Pythonmac-SIG] The versioning question... In-Reply-To: <41D0542E.9000404@noaa.gov> References: <8128F38C-686F-45F7-90C4-CB181B992AD1@mac.com> <4520D194-5773-11D9-97BB-000A9567635C@redivi.com> <41D0542E.9000404@noaa.gov> Message-ID: <897942DB-584E-11D9-8852-000393894CEA@xs4all.nl> Hi all, On 27 dec 2004, at 19:27, Chris Barker wrote: > Robin has added versioning to the latest wxPython, and I. for one am > ecstatic. It works great for me. I am generally using 2.5.3, but have > 2.4.2 installed, and a number of my apps depend on it (on Linux > anyway, it's pretty useless on OS-X) > > It's great to be able to put: > > import wxversion > wxversion.select("2.4") > > At the top of my apps, and know that they'll use the version of > wxPython I tested against. Would it be an idea to submit a PEP for extending the 'import' keyword? I can imagine it to be like: import spam version 1 import foo version 2, 4 import bar version 7, 1, 6 with version numbers consisting of some fixed maximum of parts and the version number parts not given might be wildcards. We could then have a per module version system like: .../ spam/ 1.0.1/ ... [version 1.0.1 stuff in here] 1.5.7/ ... [version 1.5.7 stuff in here] there should be nothing else in the module directory, except for a mechanism to further support versioning. Default behaviour of 'import spam' would be to select the most recent version. We might want to override that by pointing to some other version. This might be achieved using a symbolic link/alias/shortcut to the directory of that version (spam/current -> spam/1.0.1). More like the directory/module method would be to allow for a __version__.py file in 'spam'. Content of this file is to be determined, but I think it should at least something like __current__ or __version__ to act as the pointer to the current version. --eric From hengist.podd at virgin.net Mon Dec 27 23:29:02 2004 From: hengist.podd at virgin.net (has) Date: Mon Dec 27 23:30:57 2004 Subject: [Pythonmac-SIG] The versioning question... In-Reply-To: <41D0542E.9000404@noaa.gov> References: <8128F38C-686F-45F7-90C4-CB181B992AD1@mac.com> <4520D194-5773-11D9-97BB-000A9567635C@redivi.com> <41D0542E.9000404@noaa.gov> Message-ID: Chris Barker wrote: >>That doesn't fix the multiple versions problem. > >This is a big issue that the core Pythonistas don't seem to be >interested in addressing. It's odd, because I think it's a >no-brainer that python modules need to be versioned, and there needs >to be a way to have multiple versions co-existing and user (that is >code) selectable. Agree completely. I think the reason folk are reluctant to address it isn't that it's an inherently hard problem, but that to solve it now requires either 1. hard political decisions to achieve an easy technical solution (i.e. a solution that's not backwards-compatible with previous versions of Python and would require big changes to the way that module-related tools and community operate), or 2. difficult and costly technical solutions to obtain a politically expedient answer. Alas, that's weird and wobbly and completely paradoxical world of software for you. Most wonderfully pliable medium in the universe, yet constricted and bound by the inexorable weight of its own history. I suspect the only way to remain free is to be completely unsuccessful - at least without users there's nobody to upset but yourself. Oh well, maybe in Python 3000... ;) Cheers, has p.s. FWIW, I do remember proposing a versioning system in another such conversation - can't recall where, but could probably dig it up if you were really interested. I think it was quite a promising concept worth further investigation: simple and very flexible to use (most schemes are either simple and completely rigid, or supposedly flexible and undesireably complex and over-engineered) - sufficient to cover the majority of user needs out of the box, with the raw underlying APIs still available to anyone who might occasionally need to arrange something special. -- http://freespace.virgin.net/hamish.sanderson/ From Chris.Barker at noaa.gov Mon Dec 27 23:29:46 2004 From: Chris.Barker at noaa.gov (Chris Barker) Date: Mon Dec 27 23:33:46 2004 Subject: [Pythonmac-SIG] The versioning question... In-Reply-To: <897942DB-584E-11D9-8852-000393894CEA@xs4all.nl> References: <8128F38C-686F-45F7-90C4-CB181B992AD1@mac.com> <4520D194-5773-11D9-97BB-000A9567635C@redivi.com> <41D0542E.9000404@noaa.gov> <897942DB-584E-11D9-8852-000393894CEA@xs4all.nl> Message-ID: <41D08CDA.2090409@noaa.gov> Eric Nieuwland wrote: > Would it be an idea to submit a PEP for extending the 'import' keyword? As I mentioned, my read on this is that it's not going to happen at the python level, at least not for a while. This is based on various threads in c.l.p, and maybe python-dev. So, while I still think it's important, I'm not going to try to work for it now. Even with wxPython, there was some resistance to the versioning idea, which as far as I could tell boiled down to: "It would be much better to keep packages backward compatible" Which is also kind of what Bob I. said about PyObjC. However, while backward compatibility is great, you are going to want to break it some time. In the wxPython case, there was a lot that changed between 2.4.2 and 2.5.1 and 2.5.2, etc. This was an extreme case, but while maybe it would be a good idea to keep backward compatibility from 2.4.* to 2.5*, at some point, maybe version 3.0, you'll want to break it, and then it would be good to have a system in place. I just seems obvious to me that you should be able to upgrade a component on your system, whether it be a library, or a python module, without breaking anything that depends on the older component. That's why we have version numbers on dynamic libs. Whether it was Apple's fault or not, it's still been a pain that I can't just upgrade python on my OS-X box. What If Apple some day included PyObjC version X.y and uses it for some system components. Wouldn't you like to be able to upgrade to PyObjC version W.z on your own schedule, not Apple's? -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov From skip at pobox.com Tue Dec 28 00:02:16 2004 From: skip at pobox.com (Skip Montanaro) Date: Tue Dec 28 00:02:21 2004 Subject: [Pythonmac-SIG] The versioning question... In-Reply-To: References: <8128F38C-686F-45F7-90C4-CB181B992AD1@mac.com> <4520D194-5773-11D9-97BB-000A9567635C@redivi.com> <41D0542E.9000404@noaa.gov> Message-ID: <16848.38008.924768.10198@montanaro.dyndns.org> >>> That doesn't fix the multiple versions problem. >> >> This is a big issue that the core Pythonistas don't seem to be >> interested in addressing. It's odd, because I think it's a no-brainer >> that python modules need to be versioned, and there needs to be a way >> to have multiple versions co-existing and user (that is code) >> selectable. has> Agree completely. I think the reason folk are reluctant to address has> it isn't that it's an inherently hard problem, but that to solve it has> now requires either 1. hard political decisions to achieve an easy has> technical solution (i.e. a solution that's not backwards-compatible has> with previous versions of Python and would require big changes to has> the way that module-related tools and community operate), or has> 2. difficult and costly technical solutions to obtain a politically has> expedient answer. There's more to it than that: 1. Most people simply don't need it. My first brush with versioning Python modules occurred in the past few months at my current job, and that was mostly so our SWIG'd modules could be released in step with our locally written C++ libraries. I used Python for ten years before that without ever feeling the need for versioning. 2. I think it will be challenging to come up with a versioning scheme that works for everyone. To do versioning at work we had to solve issues related to module naming, directory structure, source code control and local build environment tools to make it work. has> Alas, that's weird and wobbly and completely paradoxical world of has> software for you.... Oh well, maybe in Python 3000... ;) Write a PEP and put it out for review. I don't recall seeing this raised in the Python community before. I certainly don't think it's something the core developers worry about, so maybe more "real world" input is necessary to get it to fly. Skip From charles.hartman at conncoll.edu Tue Dec 28 00:48:31 2004 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Tue Dec 28 00:48:53 2004 Subject: [Pythonmac-SIG] The versioning question... In-Reply-To: References: <8128F38C-686F-45F7-90C4-CB181B992AD1@mac.com> <4520D194-5773-11D9-97BB-000A9567635C@redivi.com> <41D0542E.9000404@noaa.gov> Message-ID: On Dec 27, 2004, at 5:29 PM, has wrote: > Alas, that's weird and wobbly and completely paradoxical world of > software for you. Most wonderfully pliable medium in the universe, yet > constricted and bound by the inexorable weight of its own history. I > suspect the only way to remain free is to be completely unsuccessful - > at least without users there's nobody to upset but yourself. Oh well, > maybe in Python 3000... ;) That's always been my solution (I learned it from my profession, that of a poet), and I should report that it works wonderfully. Charles Hartman Professor of English, Poet in Residence http://cherry.conncoll.edu/cohar http://villex.blogspot.com From bob at redivi.com Tue Dec 28 02:16:57 2004 From: bob at redivi.com (Bob Ippolito) Date: Tue Dec 28 02:17:03 2004 Subject: [Pythonmac-SIG] More testers needed: Fix installer In-Reply-To: References: <63280D1C-5808-11D9-81BB-000D934FF6B4@cwi.nl> <89EF1AA8-5826-11D9-A79F-000A9567635C@redivi.com> Message-ID: <2B041AB4-586E-11D9-AA13-000A9567635C@redivi.com> On Dec 27, 2004, at 2:53 PM, Jack Jansen wrote: > > On 27-dec-04, at 17:44, Bob Ippolito wrote: >>> You can find the package at >>> . >> >> The Makefile is missing the MACOSX_DEPLOYMENT_TARGET=10.3 before the >> $(CC) .. which means that for most people, it won't compile extension >> modules, because not everyone has this set in their login scripts.. > > Ah, forgot about that one, thanks! > > I'll pull the installer, and I'll create a new one tomorrow (with a > different name:-). > > The same problem holds for the fixapplepython script, so I'll fix that > one too. > > What would be the easiest fix for 2.3.5: backporting the distutils > fixes (so it'll set MACOSX_DEPLOYMENT_TARGET) or simply setting that > variable in the $(LD) macro (through configure)? My vote is for the distutils fixes (that set the env var outside the LDSHARED or whatever), so that compiling c++ will definitely work. -bob From bob at redivi.com Tue Dec 28 02:29:42 2004 From: bob at redivi.com (Bob Ippolito) Date: Tue Dec 28 02:29:48 2004 Subject: [Pythonmac-SIG] The versioning question... In-Reply-To: <41D08CDA.2090409@noaa.gov> References: <8128F38C-686F-45F7-90C4-CB181B992AD1@mac.com> <4520D194-5773-11D9-97BB-000A9567635C@redivi.com> <41D0542E.9000404@noaa.gov> <897942DB-584E-11D9-8852-000393894CEA@xs4all.nl> <41D08CDA.2090409@noaa.gov> Message-ID: On Dec 27, 2004, at 5:29 PM, Chris Barker wrote: > Eric Nieuwland wrote: > >> Would it be an idea to submit a PEP for extending the 'import' >> keyword? > > As I mentioned, my read on this is that it's not going to happen at > the python level, at least not for a while. This is based on various > threads in c.l.p, and maybe python-dev. So, while I still think it's > important, I'm not going to try to work for it now. > > Even with wxPython, there was some resistance to the versioning idea, > which as far as I could tell boiled down to: > > "It would be much better to keep packages backward compatible" > > Which is also kind of what Bob I. said about PyObjC. Personally I think the wx versioning mechanism is bad. It should've just been done with module names. Importing wx directly could reference the last version that was installed, and wx_2_4 could reference some specific version. The current versioning API is too "magical" and provides no means for static analysis without special-casing exactly the wx case. Then again, wx already does a lot of ridiculous magical things anyway that wreak havoc on application packagers, so why not make the mess even bigger? More fun for us! > However, while backward compatibility is great, you are going to want > to break it some time. In the wxPython case, there was a lot that > changed between 2.4.2 and 2.5.1 and 2.5.2, etc. This was an extreme > case, but while maybe it would be a good idea to keep backward > compatibility from 2.4.* to 2.5*, at some point, maybe version 3.0, > you'll want to break it, and then it would be good to have a system in > place. That's when you change the name of the top level module or package... It's the only solution that actually works, but people like to cry about it because it's ugly :) > I just seems obvious to me that you should be able to upgrade a > component on your system, whether it be a library, or a python module, > without breaking anything that depends on the older component. That's > why we have version numbers on dynamic libs. Whether it was Apple's > fault or not, it's still been a pain that I can't just upgrade python > on my OS-X box. What If Apple some day included PyObjC version X.y and > uses it for some system components. Wouldn't you like to be able to > upgrade to PyObjC version W.z on your own schedule, not Apple's? Upgrading is almost unilaterally a bad idea. Even backwards compatible libraries can cause breakage in applications that depend on misfeatures of a previous version. What you really want is to be able to run multiple versions of stuff in parallel, and that pretty much works. Yes, you need to patch Python if you want the older version to still be able to compile extensions, and that's more or less our fault. Other than that, having parallel Pythons works just fine. For third party packages, Apple seems to install them in the normal place (directly in site-packages or some equivalent referenced by a pth). It would be possible to upgrade these by normal means (replace).. however, by doing that, you're potentially breaking any installed software that uses it. If you want bleeding edge, or the dusty old past, you MUST run it in parallel, whether that's by having a separate Python installation or a way of flipping around sys.path. Except for modules that are specifically designed to run in parallel with other versions of themselves (by naming convention), you simply CAN NOT have two versions of the same thing available. -bob From Chris.Barker at noaa.gov Tue Dec 28 02:45:24 2004 From: Chris.Barker at noaa.gov (Chris Barker) Date: Tue Dec 28 02:49:25 2004 Subject: [Python-Dev] Re: [Pythonmac-SIG] The versioning question... In-Reply-To: <41D09C1E.1060009@v.loewis.de> References: <8128F38C-686F-45F7-90C4-CB181B992AD1@mac.com> <4520D194-5773-11D9-97BB-000A9567635C@redivi.com> <41D0542E.9000404@noaa.gov> <897942DB-584E-11D9-8852-000393894CEA@xs4all.nl> <41D09C1E.1060009@v.loewis.de> Message-ID: <41D0BAB4.70903@noaa.gov> Martin v. L?wis wrote: > No. Normally, packages should aim for backwards compatibility, so that > applications would only want to specify a minimum version, such as > > import xml > assert xml.version_info > (0,8,2) Well, yes, but life is not always so simple, and while, as a rule, version 2.3 should be backward compatible with 2.2, I see no reason to expect that version 5.0 and version 2.0 will be compatible. Frankly, backward compatibility can be a real impediment to progress. (when will "true division" be default?) > If you really want side-by-side installation of different versions, > and a mechanism to select between them, the package could support > > import xml_0_8_2 as xml > > IOW, "import-as" should be sufficient for what you want to achieve. This really doesn't work well for complex packages. I was quite involved with the debate about versioning for wxPython (and helped drive it happening) and that was what I originally proposed. The problem is that you have a whole pile of modules and libs and user code that all imports the package. There are a LOT of "import wx" lines in the wxPython library, and a whole bunch more in a sizable wxPython app. As you upgrade, every one of those would have to be changed to import wx_x_y_z as wx This was not considered a reasonable solution. Among other things, it's really nice to be able to make a small change in just one file, and be able to test your app against a new version. Other approaches were suggested and were used in the past: - A script that you run to change what version is installed - An environment variable that you set. - Whatever else I can't recall. Personally, I was only going to be really happy with an approach that worked at the python level, in one place. The versioning system that wxPython now has is quite nice, and seems to fit most people's needs well. However, it's also quite new, and who know what problems will arise. For those interested, here's a synopsis. http://wiki.wxpython.org/index.cgi/MultiVersionInstalls Skip Montanaro wrote: > There's more to it than that: > 1. Most people simply don't need it. My first brush with versioning > Python modules occurred in the past few months at my current job, and > that was mostly so our SWIG'd modules could be released in step with > our locally written C++ libraries. I used Python for ten years > before that without ever feeling the need for versioning. I'm surprised, but I think maturity and complexity has something to do with it. The more mature Python and its add-on packages become, the more this will be an issue. There was certainly a lot of uproar about backward compatible changes in Python itself, another issue that could be lessoned by a bit easier accommodation of multiple versions of python. (or why, or why did Redhat not put a version on their #! lines? have they yet?) > 2. I think it will be challenging to come up with a versioning scheme > that works for everyone. This is very true we had a hard enough time coming to a consensus among a small group of wxPython developers. I'm not sure we even did anyway, Robin just decided on one to implement. > To do versioning at work we had to solve > issues related to module naming, directory structure, source code > control and local build environment tools to make it work. Wow! that sounds a lot more complex that it has to be, but I'm sure there's a lot to what you've done. Note that you've kind of contradicted yourself (or at least contradicted Martin). I suspect your versioning issues would have been much simpler if Python itself had supported it. > Write a PEP and put it out for review. I don't recall seeing this raised in > the Python community before. That I'm surprised about. I've seen it (and brought it up) a number of times. I know there are a few major packages with roll your own versioning systems, wxPython, PyGTK, and PMW to mention a few. > I certainly don't think it's something the > core developers worry about, This is quite true, and why I haven't bothered with a PEP, but maybe I've got the thinking backwards, we need the PEP to get the "important" people thinking about it. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov From bob at redivi.com Tue Dec 28 03:37:42 2004 From: bob at redivi.com (Bob Ippolito) Date: Tue Dec 28 03:37:52 2004 Subject: [Python-Dev] Re: [Pythonmac-SIG] The versioning question... In-Reply-To: <41D0BAB4.70903@noaa.gov> References: <8128F38C-686F-45F7-90C4-CB181B992AD1@mac.com> <4520D194-5773-11D9-97BB-000A9567635C@redivi.com> <41D0542E.9000404@noaa.gov> <897942DB-584E-11D9-8852-000393894CEA@xs4all.nl> <41D09C1E.1060009@v.loewis.de> <41D0BAB4.70903@noaa.gov> Message-ID: <729AC65F-5879-11D9-AA13-000A9567635C@redivi.com> On Dec 27, 2004, at 8:45 PM, Chris Barker wrote: > The versioning system that wxPython now has is quite nice, and seems > to fit most people's needs well. However, it's also quite new, and who > know what problems will arise. For those interested, here's a > synopsis. > > http://wiki.wxpython.org/index.cgi/MultiVersionInstalls I just cleaned up a bunch of spelling on that wiki page and rewrote the "what about py2exe" section. It now mentions py2app, is (hopefully) written more clearly, and includes an easier alternative for bundling the desired version of wxPython (wxversion can be used from setup.py). -bob From skip at pobox.com Tue Dec 28 05:26:51 2004 From: skip at pobox.com (Skip Montanaro) Date: Tue Dec 28 05:27:18 2004 Subject: [Python-Dev] Re: [Pythonmac-SIG] The versioning question... In-Reply-To: <41D09C1E.1060009@v.loewis.de> References: <8128F38C-686F-45F7-90C4-CB181B992AD1@mac.com> <4520D194-5773-11D9-97BB-000A9567635C@redivi.com> <41D0542E.9000404@noaa.gov> <897942DB-584E-11D9-8852-000393894CEA@xs4all.nl> <41D09C1E.1060009@v.loewis.de> Message-ID: <16848.57483.204434.666107@montanaro.dyndns.org> Martin> If you really want side-by-side installation of different Martin> versions, and a mechanism to select between them, the package Martin> could support Martin> import xml_0_8_2 as xml Martin> IOW, "import-as" should be sufficient for what you want to achieve. That's more-or-less the scheme adopted where I work. If we have two versions of a sybase module installed side-by-side, the imports might look like: import local.db.sybase.v1 as sybase or import local.db.sybase.v2 as sybase It's a bit cumbersome, but it's worked okay for us so far. Skip From gravylovingslut at blueyonder.co.uk Mon Dec 27 21:12:01 2004 From: gravylovingslut at blueyonder.co.uk (Gravy) Date: Tue Dec 28 05:28:08 2004 Subject: [Pythonmac-SIG] Python 2.4 on OS X 10.3.7 In-Reply-To: <74C887B8-581F-11D9-A009-000D9352164A@johnochiltree.uklinux.net> References: <0FF41D08-573C-11D9-824C-000D9352164A@johnochiltree.uklinux.net> <41CFF752.901@anubics.org> <74C887B8-581F-11D9-A009-000D9352164A@johnochiltree.uklinux.net> Message-ID: <916DA1F6-5843-11D9-A009-000D9352164A@blueyonder.co.uk> On 27 Dec 2004, at 15:53, John Ochiltree wrote: > > On 27 Dec 2004, at 11:51, Enrico Franchi wrote: > >> John Ochiltree wrote: >> >>> . I rebuilt python (adding --enable-readline , although I understand >>> I should no longer have to do this) but still no success in python. >>> >> >> I specified in CFLAGS where are the libs and includes (-L and -I for >> gcc). >> I used readline from darwinports, so i set CFLAGS to -L/opt/local/lib >> -I/opt/local/include >> and it worked. >> >> > Thanks, but where do I set these CFLAG values? Do I have to edit > Modules/Setup? Sorry to be so dumb! > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > > Doh!! Set CFLAGS as an environment variable and everything worked fine. Thanks From martin at v.loewis.de Tue Dec 28 00:34:54 2004 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Tue Dec 28 05:28:10 2004 Subject: [Python-Dev] Re: [Pythonmac-SIG] The versioning question... In-Reply-To: <897942DB-584E-11D9-8852-000393894CEA@xs4all.nl> References: <8128F38C-686F-45F7-90C4-CB181B992AD1@mac.com> <4520D194-5773-11D9-97BB-000A9567635C@redivi.com> <41D0542E.9000404@noaa.gov> <897942DB-584E-11D9-8852-000393894CEA@xs4all.nl> Message-ID: <41D09C1E.1060009@v.loewis.de> Eric Nieuwland wrote: > Would it be an idea to submit a PEP for extending the 'import' keyword? No. Normally, packages should aim for backwards compatibility, so that applications would only want to specify a minimum version, such as import xml assert xml.version_info > (0,8,2) If you really want side-by-side installation of different versions, and a mechanism to select between them, the package could support import xml_0_8_2 as xml IOW, "import-as" should be sufficient for what you want to achieve. Regards, Martin From martin at v.loewis.de Tue Dec 28 14:30:46 2004 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Tue Dec 28 14:48:31 2004 Subject: [Python-Dev] Re: [Pythonmac-SIG] The versioning question... In-Reply-To: <41D0BAB4.70903@noaa.gov> References: <8128F38C-686F-45F7-90C4-CB181B992AD1@mac.com> <4520D194-5773-11D9-97BB-000A9567635C@redivi.com> <41D0542E.9000404@noaa.gov> <897942DB-584E-11D9-8852-000393894CEA@xs4all.nl> <41D09C1E.1060009@v.loewis.de> <41D0BAB4.70903@noaa.gov> Message-ID: <41D16006.8020103@v.loewis.de> Chris Barker wrote: > This really doesn't work well for complex packages. I was quite involved > with the debate about versioning for wxPython (and helped drive it > happening) and that was what I originally proposed. The problem is that > you have a whole pile of modules and libs and user code that all imports > the package. There are a LOT of "import wx" lines in the wxPython > library, and a whole bunch more in a sizable wxPython app. As you > upgrade, every one of those would have to be changed to > > import wx_x_y_z as wx Not at all. Import wx_x_y_z could do sys.modules["wx"] = wx_x_y_z and then all references to import wx would automatically resolve to the version that was imported first (or last, depending on your implementation strategy). > This was not considered a reasonable solution. Among other things, it's > really nice to be able to make a small change in just one file, and be > able to test your app against a new version. Even if the package is not prepared to register itself under a different name also, this one file could modify sys.modules. Or you can have a wx.py that reads from wx_x_y_z import * Then, wx.py would be that single file. > The versioning system that wxPython now has is quite nice, and seems to > fit most people's needs well. Very good! Then I don't see a need to change anything in Python. > This is quite true, and why I haven't bothered with a PEP, but maybe > I've got the thinking backwards, we need the PEP to get the "important" > people thinking about it. I don't think a PEP is needed - Python already appears to have everything you need to come up with your own versioning rules. Regards, Martin From kid at kendermedia.com Tue Dec 28 18:05:36 2004 From: kid at kendermedia.com (Kevin Dangoor) Date: Tue Dec 28 18:05:41 2004 Subject: [Pythonmac-SIG] py2app error with _py_suffixes Message-ID: <41D19260.508@kendermedia.com> First of all, thanks for all of the work put into py2app! Hard to imagine how much time it would have taken me to figure out all of the various things that it does (particularly since I'm new to Mac development). I was just going to rebuild an app and ran into this error: File "/purelib/py2app/py2app/util.py", line 203, in byte_compile NameError: global name '_py_suffixes' is not defined It was trying to byte compile a ".pyc" to a ".pyc" I don't see _py_suffixes defined anywhere... Thanks again for the cool tool Kevin From kid at kendermedia.com Tue Dec 28 18:14:41 2004 From: kid at kendermedia.com (Kevin Dangoor) Date: Tue Dec 28 18:14:48 2004 Subject: [Pythonmac-SIG] py2app error with _py_suffixes In-Reply-To: <41D19260.508@kendermedia.com> References: <41D19260.508@kendermedia.com> Message-ID: <41D19481.90007@kendermedia.com> One more bit of relevant info... I just noticed that the file in question was a ".ptl" file (from Quixote) that was compiled into a ".pyc". Kevin Kevin Dangoor wrote: > First of all, thanks for all of the work put into py2app! Hard to > imagine how much time it would have taken me to figure out all of the > various things that it does (particularly since I'm new to Mac > development). > > I was just going to rebuild an app and ran into this error: > > File "/purelib/py2app/py2app/util.py", line 203, in byte_compile > NameError: global name '_py_suffixes' is not defined > > It was trying to byte compile a ".pyc" to a ".pyc" > > I don't see _py_suffixes defined anywhere... > > Thanks again for the cool tool > > > Kevin > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > > > From bob at redivi.com Tue Dec 28 20:25:43 2004 From: bob at redivi.com (Bob Ippolito) Date: Tue Dec 28 20:25:49 2004 Subject: [Pythonmac-SIG] py2app error with _py_suffixes In-Reply-To: <41D19260.508@kendermedia.com> References: <41D19260.508@kendermedia.com> Message-ID: <4415E4D5-5906-11D9-AA13-000A9567635C@redivi.com> On Dec 28, 2004, at 12:05 PM, Kevin Dangoor wrote: > First of all, thanks for all of the work put into py2app! Hard to > imagine how much time it would have taken me to figure out all of the > various things that it does (particularly since I'm new to Mac > development). > > I was just going to rebuild an app and ran into this error: > > File "/purelib/py2app/py2app/util.py", line 203, in byte_compile > NameError: global name '_py_suffixes' is not defined > > It was trying to byte compile a ".pyc" to a ".pyc" > > I don't see _py_suffixes defined anywhere... > > Thanks again for the cool tool I have no idea. I'm not sure what version you are using, and svn trunk doesn't reference a "_py_suffixes" anywhere from any file. Try upgrading to svn trunk or wait for an 0.1.7 release later this week. -bob From bob at redivi.com Tue Dec 28 20:27:07 2004 From: bob at redivi.com (Bob Ippolito) Date: Tue Dec 28 20:27:13 2004 Subject: [Pythonmac-SIG] py2app error with _py_suffixes In-Reply-To: <41D19481.90007@kendermedia.com> References: <41D19260.508@kendermedia.com> <41D19481.90007@kendermedia.com> Message-ID: <76779FD3-5906-11D9-AA13-000A9567635C@redivi.com> On Dec 28, 2004, at 12:14 PM, Kevin Dangoor wrote: > Kevin Dangoor wrote: > >> First of all, thanks for all of the work put into py2app! Hard to >> imagine how much time it would have taken me to figure out all of the >> various things that it does (particularly since I'm new to Mac >> development). >> >> I was just going to rebuild an app and ran into this error: >> >> File "/purelib/py2app/py2app/util.py", line 203, in byte_compile >> NameError: global name '_py_suffixes' is not defined >> >> It was trying to byte compile a ".pyc" to a ".pyc" >> >> I don't see _py_suffixes defined anywhere... > > One more bit of relevant info... I just noticed that the file in > question was a ".ptl" file (from Quixote) that was compiled into a > ".pyc". That would probably explain it. py2app may very well not be compatible with alternatively compiled bytecode, I will have to look into it. Do you know if compiled ptl is compatible with py2exe? -bob From Andrew.Roazen at NAU.EDU Tue Dec 28 20:46:52 2004 From: Andrew.Roazen at NAU.EDU (Andrew Roazen) Date: Tue Dec 28 20:46:59 2004 Subject: [Pythonmac-SIG] Using TkAqua /Tkinter with custom Python 2.2 Message-ID: <5.1.0.14.2.20041228122640.024c4ec8@127.0.0.1> I was referred here by Kevin Walzer at tcl-mac's mailing list: > Can any of the core MacPython developers take a look at this thread and > give us the Pythonic viewpoint on these questions? (hooking TkAqua and > Tkinter into an old version of Python for the Mac with undocumented, > proprietary modifications: what issues should he consider?) Backstory: Curious Labs develops a 3D animation program called Poser. In 2000 they released a Windows/OS 9 version with a custom Python that has hooks to Poser internals. This version was succeeded by Poser 5 in 2002, but only for Windows (for reasons I won't go into here). When Poser 5 finally had a Mac release in 2003, it was Carbon for OS X. The Python shipping with it is a slightly modified MacPython 2.2 for Carbon. However, a growing number of Poser Python scripts are relying on Tkinter front ends and Tkinter was never successfully Carbonized. Poser's date for moving to Cocoa is fuzzy right now. For short term compatibility it would be desirable to fix this problem, perhaps using TkAqua. To reiterate Kevin's question: Assuming Curious Labs' modifications to MacPython 2.2 were nothing outside of Poser internals (i.e. variables to control character/prop/lighting values), what issues are involved in plugging TkAqua/Tkinter into this MP2.2 aka PoserPython? ---------- | Andrew Roazen, Web Development Specialist | Cline Library, Northern Arizona University |  928.523.6764 vCard The opinions expressed are those of the guy who sits at this desk, not his employers. From bob at redivi.com Tue Dec 28 20:59:19 2004 From: bob at redivi.com (Bob Ippolito) Date: Tue Dec 28 20:59:26 2004 Subject: [Pythonmac-SIG] Using TkAqua /Tkinter with custom Python 2.2 In-Reply-To: <5.1.0.14.2.20041228122640.024c4ec8@127.0.0.1> References: <5.1.0.14.2.20041228122640.024c4ec8@127.0.0.1> Message-ID: On Dec 28, 2004, at 2:46 PM, Andrew Roazen wrote: > I was referred here by Kevin Walzer at tcl-mac's mailing list: > > Can any of the core MacPython developers take a look at this thread > and > > give us the Pythonic viewpoint on these questions? (hooking TkAqua > and > > Tkinter into an old version of Python for the Mac with undocumented, > > proprietary modifications: what issues should he consider?) > > Backstory: > Curious Labs develops a 3D animation program called Poser. In 2000 > they released a Windows/OS 9 version with a custom Python that has > hooks to Poser internals. This version was succeeded by Poser 5 in > 2002, but only for Windows (for reasons I won't go into here). > > When Poser 5 finally had a Mac release in 2003, it was Carbon for OS > X. The Python shipping with it is a slightly modified MacPython 2.2 > for Carbon. However, a growing number of Poser Python scripts are > relying on Tkinter front ends and Tkinter was never successfully > Carbonized. > > Poser's date for moving to Cocoa is fuzzy right now. For short term > compatibility it would be desirable to fix this problem, perhaps using > TkAqua. > > To reiterate Kevin's question: Assuming Curious Labs' modifications to > MacPython 2.2 were nothing outside of Poser internals (i.e. variables > to control character/prop/lighting values), what issues are involved > in plugging TkAqua/Tkinter into this MP2.2 aka PoserPython? Presumably this Python is CFM based, because their OS 9 version must have been. That is likely to make it significantly harder, and CodeWarrior will probably be necessary in order to compile this Python and its extensions. I'm not sure if anyone aside from Jack and Just even remember how to do that.. I sure don't :) -bob From sw at wordtech-software.com Tue Dec 28 22:14:06 2004 From: sw at wordtech-software.com (Kevin Walzer) Date: Tue Dec 28 22:14:11 2004 Subject: [Pythonmac-SIG] py2applet question Message-ID: <41D1CC9E.5080409@wordtech-software.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, I've been playing with py2applet and py2app with a PyQt application. I'm running into this error when I try to run py2applet: Kevin-Walzers-Computer:~/Desktop/eric-3.5.1/eric kevin$ py2applet eric3.py from: can't read /var/mail/py2app.scripts.script_py2applet /usr/local/bin/py2applet: line 3: syntax error: unexpected end of file I can't get an applet generated either with the GUI or the command-line tool. Also, I get a crash message with the app bundle generated by py2app: ~ File "/Users/kevin/Desktop/eric3.app/Contents/Resources/__boot__.py", line 28, in ? ~ _run('eric3.py') ~ File "/Users/kevin/Desktop/eric3.app/Contents/Resources/__boot__.py", line 25, in _run ~ execfile(os.path.join(base, 'Python', script), globals(), globals()) ~ File "/Users/kevin/Desktop/eric3.app/Contents/Resources/Python/eric3.py", line 20, in ? ~ from UI.SingleApplication import SingleApplicationClient ~ File "UI/SingleApplication.pyc", line 17, in ? ~ File "Preferences/__init__.pyc", line 1270, in ? ~ File "Preferences/Shortcuts.pyc", line 17, in ? ImportError: No module named XML.XMLUtilities 2004-12-28 16:11:15.106 eric3[1890] eric3 Error 2004-12-28 16:11:15.107 eric3[1890] An unexpected error has occurred during execution of the main script ImportError: No module named XML.XMLUtilities I'm using the newest version of py2app (.1.6) that has the support for PyQt built-in. I'm just putting the name of the main script in the setup.py file, and not adding anyting else. Is there something special I need to do with the XML module in terms of referencing it in the setup.py script? I've actually run into this problem (w/XML modules) with other apps I've tried to build with py2app, so I'm not sure what to do. - -- Cheers, Kevin Walzer, PhD WordTech Software--Open Source Applications and Packages for OS X http://www.wordtech-software.com http://www.smallbizmac.com http://www.kevin-walzer.com mailto:sw@wordtech-software.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB0cydJmdQs+6YVcoRArbOAJ45zFDxUM6ST1LpC6BzXLy8o1lOIQCfX/Yd J38AuKNQoLlhexOY2ckjGmA= =KE2T -----END PGP SIGNATURE----- From bob at redivi.com Tue Dec 28 22:32:22 2004 From: bob at redivi.com (Bob Ippolito) Date: Tue Dec 28 22:32:37 2004 Subject: [Pythonmac-SIG] py2applet question In-Reply-To: <41D1CC9E.5080409@wordtech-software.com> References: <41D1CC9E.5080409@wordtech-software.com> Message-ID: On Dec 28, 2004, at 4:14 PM, Kevin Walzer wrote: > Kevin-Walzers-Computer:~/Desktop/eric-3.5.1/eric kevin$ py2applet > eric3.py > from: can't read /var/mail/py2app.scripts.script_py2applet > /usr/local/bin/py2applet: line 3: syntax error: unexpected end of file Sounds like the hash-bang is missing from /usr/local/bin/py2applet. I'm not sure why that is, I haven't been able to reproduce with svn trunk. > ~ from UI.SingleApplication import SingleApplicationClient > > ~ File "UI/SingleApplication.pyc", line 17, in ? > > ~ File "Preferences/__init__.pyc", line 1270, in ? > > ~ File "Preferences/Shortcuts.pyc", line 17, in ? > > ImportError: No module named XML.XMLUtilities This is because whatever you're wrapping is making some crazy non-import-bytecode based import of some XML package. You can not use the GUI py2applet with such an application, and you should probably create a setup.py. The command-line py2applet might be able to package such an application like this: % py2applet eric3.py --includes='XML.*' It really depends on what the XML is and how it's structured. > I'm using the newest version of py2app (.1.6) that has the support for > PyQt built-in. I'm just putting the name of the main script in the > setup.py file, and not adding anyting else. Is there something special > I > need to do with the XML module in terms of referencing it in the > setup.py script? I've actually run into this problem (w/XML modules) > with other apps I've tried to build with py2app, so I'm not sure what > to do. Where the heck does this XML module come from anyway? It's not in the standard library or anything else I've ever used. -bob From bac at ocf.berkeley.edu Tue Dec 28 23:11:38 2004 From: bac at ocf.berkeley.edu (Brett C.) Date: Tue Dec 28 23:11:32 2004 Subject: [Pythonmac-SIG] How badly is _locale broken? Message-ID: <41D1DA1A.5050206@ocf.berkeley.edu> I am planning to attempt to fix the _locale module (which 'locale' itself imports and uses) for OS X. As of this exact moment I am planning just fixing localeconv (thanks to CFNumberFormatter and setlocale still at least storing the supposed locale, even if it does ignore it), but I realized other stuff might be broken. Since I never personally use the module, does anyone know the extent of the breakage? Obviously I would rather just have to fix localeconv and keep my life simple, but if it is more extensive I can see what I can do. -Brett From Jack.Jansen at cwi.nl Tue Dec 28 23:20:51 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Tue Dec 28 23:20:53 2004 Subject: [Pythonmac-SIG] More testers needed: Fix installer v1.1 In-Reply-To: <63280D1C-5808-11D9-81BB-000D934FF6B4@cwi.nl> References: <63280D1C-5808-11D9-81BB-000D934FF6B4@cwi.nl> Message-ID: There's a new one, with a new name and the environment bug fixed: . Please give it a try, -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From Jack.Jansen at cwi.nl Tue Dec 28 23:27:37 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Tue Dec 28 23:27:42 2004 Subject: [Pythonmac-SIG] Using TkAqua /Tkinter with custom Python 2.2 In-Reply-To: <5.1.0.14.2.20041228122640.024c4ec8@127.0.0.1> References: <5.1.0.14.2.20041228122640.024c4ec8@127.0.0.1> Message-ID: On 28-dec-04, at 20:46, Andrew Roazen wrote: > I was referred here by Kevin Walzer at tcl-mac's mailing list: > > Can any of the core MacPython developers take a look at this thread > and > > give us the Pythonic viewpoint on these questions? (hooking TkAqua > and > > Tkinter into an old version of Python for the Mac with undocumented, > > proprietary modifications: what issues should he consider?) I posted a reply to this (I think on both pythonmac-sig and mactcl) last week. Did you see that message? -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From charles.hartman at conncoll.edu Wed Dec 29 02:07:18 2004 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Wed Dec 29 02:07:31 2004 Subject: [Pythonmac-SIG] Qt is Message-ID: commercial, I take it. I was hoping to try Kodos, which looks like a helpful learning tool. So, not knowing anything about it, I followed the trail from Kodos, to PyQt, to SIP, to Qt, to the little box that wants $1,550. Oops, I think I just stepped out of the GNU world & into the old. Charles Hartman http://cherry.conncoll.edu/cohar http://villex.blogspot.com From bob at redivi.com Wed Dec 29 02:19:11 2004 From: bob at redivi.com (Bob Ippolito) Date: Wed Dec 29 02:19:17 2004 Subject: [Pythonmac-SIG] Qt is In-Reply-To: References: Message-ID: On Dec 28, 2004, at 8:07 PM, Charles Hartman wrote: > commercial, I take it. I was hoping to try Kodos, which looks like a > helpful learning tool. So, not knowing anything about it, I followed > the trail from Kodos, to PyQt, to SIP, to Qt, to the little box that > wants $1,550. Oops, I think I just stepped out of the GNU world & into > the old. Qt is dual-licensed software. For X11 and Mac OS X, it is available under the terms of the QPL. You might want to look at RegExPlor , which does more or less the same thing but is PyObjC based. -bob From charles.hartman at conncoll.edu Wed Dec 29 02:24:22 2004 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Wed Dec 29 02:24:27 2004 Subject: [Pythonmac-SIG] Qt is In-Reply-To: References: Message-ID: <5E7F6822-5938-11D9-9FDE-000D933C27EA@conncoll.edu> Hey, that's great -- thanks! RegexPlor looks like what I need. (I've got a regex puzzle that's made my head hurt for two days. [Not knowing what I'm doing might have *something* to do with it.]) Charles Hartman http://cherry.conncoll.edu/cohar http://villex.blogspot.com On Dec 28, 2004, at 8:19 PM, Bob Ippolito wrote: > > On Dec 28, 2004, at 8:07 PM, Charles Hartman wrote: > >> commercial, I take it. I was hoping to try Kodos, which looks like a >> helpful learning tool. So, not knowing anything about it, I followed >> the trail from Kodos, to PyQt, to SIP, to Qt, to the little box that >> wants $1,550. Oops, I think I just stepped out of the GNU world & >> into the old. > > Qt is dual-licensed software. For X11 and Mac OS X, it is available > under the terms of the QPL. > > You might want to look at RegExPlor > , which does more or less > the same thing but is PyObjC based. > > -bob > From kid at kendermedia.com Wed Dec 29 04:18:06 2004 From: kid at kendermedia.com (Kevin Dangoor) Date: Wed Dec 29 04:18:09 2004 Subject: [Pythonmac-SIG] py2app error with _py_suffixes In-Reply-To: <76779FD3-5906-11D9-AA13-000A9567635C@redivi.com> References: <41D19260.508@kendermedia.com> <41D19481.90007@kendermedia.com> <76779FD3-5906-11D9-AA13-000A9567635C@redivi.com> Message-ID: <41D221EE.3050707@kendermedia.com> Bob Ippolito wrote: > > On Dec 28, 2004, at 12:14 PM, Kevin Dangoor wrote: > >> Kevin Dangoor wrote: >> >>> >>> I don't see _py_suffixes defined anywhere... >> >> >> One more bit of relevant info... I just noticed that the file in >> question was a ".ptl" file (from Quixote) that was compiled into a >> ".pyc". > > > That would probably explain it. py2app may very well not be > compatible with alternatively compiled bytecode, I will have to look > into it. Do you know if compiled ptl is compatible with py2exe? > > -bob I'm using py2app 0.1.6 (just downloaded today). At least in that version, there's a _py_suffixes referenced. I had my build script drop a _py_suffixes into the util module and that worked fine. Quixote's ptl compiler includes a handy function that compiles every ptl in a directory. Precompiling the ptls worked fine with py2app! That's a much more pleasant solution (to me, at least) than dropping the files in next to the app, which is what was suggested for py2exe. Kevin From bob at redivi.com Wed Dec 29 04:26:34 2004 From: bob at redivi.com (Bob Ippolito) Date: Wed Dec 29 04:26:46 2004 Subject: [Pythonmac-SIG] py2app error with _py_suffixes In-Reply-To: <41D221EE.3050707@kendermedia.com> References: <41D19260.508@kendermedia.com> <41D19481.90007@kendermedia.com> <76779FD3-5906-11D9-AA13-000A9567635C@redivi.com> <41D221EE.3050707@kendermedia.com> Message-ID: <709A41B0-5949-11D9-A28B-000A9567635C@redivi.com> On Dec 28, 2004, at 10:18 PM, Kevin Dangoor wrote: > Bob Ippolito wrote: > >> >> On Dec 28, 2004, at 12:14 PM, Kevin Dangoor wrote: >> >>> Kevin Dangoor wrote: >>> >>>> >>>> I don't see _py_suffixes defined anywhere... >>> >>> >>> One more bit of relevant info... I just noticed that the file in >>> question was a ".ptl" file (from Quixote) that was compiled into a >>> ".pyc". >> >> >> That would probably explain it. py2app may very well not be >> compatible with alternatively compiled bytecode, I will have to look >> into it. Do you know if compiled ptl is compatible with py2exe? > > I'm using py2app 0.1.6 (just downloaded today). At least in that > version, there's a _py_suffixes referenced. > > I had my build script drop a _py_suffixes into the util module and > that worked fine. Yuck. Well, svn trunk is significantly different and 0.1.7 will be out any day now (whichever day PyObjC 1.2 comes out). > Quixote's ptl compiler includes a handy function that compiles every > ptl in a directory. Precompiling the ptls worked fine with py2app! > That's a much more pleasant solution (to me, at least) than dropping > the files in next to the app, which is what was suggested for py2exe. Interesting, I'll have to look at Quixote at some point to see if I can integrate that as a recipe. If your app is open source, could you point me to its source so I can make it a use case? -bob From bob at redivi.com Wed Dec 29 04:35:15 2004 From: bob at redivi.com (Bob Ippolito) Date: Wed Dec 29 04:35:23 2004 Subject: [Pythonmac-SIG] Re: [Python-checkins] python/dist/src/Mac/OSX fixapplepython23.py, 1.1, 1.2 In-Reply-To: References: Message-ID: On Dec 28, 2004, at 4:30 PM, jackjansen@users.sourceforge.net wrote: > Update of /cvsroot/python/python/dist/src/Mac/OSX > In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv9229 > > Modified Files: > fixapplepython23.py > Log Message: > Just passing -undefined dynamic_lookup isn't enough: we also need to > set > the MACOSX_DEPLOYMENT_TARGET environment variable to 10.3 when calling > the > loader. And we do this with "env" because distutils apparently doesn't > understand environment variable assignments before command names. This is the wrong fix. Distutils is dumber than you think. This patch just breaks C++ compilation in a different way. The correct solution is a patch to distutils of some kind. from distutils/unixccompiler.py:174 if target_lang == "c++" and self.compiler_cxx: linker[0] = self.compiler_cxx[0] self.spawn(linker + ld_args) "linker" is the variable expanded LDSHARED (or whatever comes out of sysconfig.customize_compiler). -bob From fgranger at fgranger.com Wed Dec 29 09:12:40 2004 From: fgranger at fgranger.com (Fran=?ISO-8859-1?B?5w==?=ois Granger) Date: Wed Dec 29 09:12:09 2004 Subject: [Pythonmac-SIG] Popen2 Message-ID: I am trying to use popen2.popen3 and I am stuck. I tested the command line I am building and it works ok. This may be due to my lack of knowledge of the command line functionnalities... But this script either hang or raise an error. This is the bare bone script directly copied from the sample: #!/usr/bin/env python # -*- coding: utf-8 -*- """r, w, e = popen2.popen3('python slave.py') e.readlines() r.readlines() r.close() e.close() w.close()""" import popen2 theString = file('testfiles/notes.htm').read() source = 'macintosh' target = 'UTF-8' r, w, e = popen2.popen3('iconv -f ' + source.upper() + ' -t ' + target.upper() + '//TRANSLIT') w.write(theString) e.readlines() result = r.readlines() r.close() e.close() w.close() print result pass From bob at redivi.com Wed Dec 29 10:12:12 2004 From: bob at redivi.com (Bob Ippolito) Date: Wed Dec 29 10:12:23 2004 Subject: [Pythonmac-SIG] Popen2 In-Reply-To: References: Message-ID: On Dec 29, 2004, at 3:12 AM, Fran?ois Granger wrote: > I am trying to use popen2.popen3 and I am stuck. Don't! Use subprocess instead. Read this thread for the last discussion on this topic (that I recall, anyway). -bob From ronaldoussoren at mac.com Wed Dec 29 10:48:20 2004 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Wed Dec 29 10:48:21 2004 Subject: [Pythonmac-SIG] py2applet question In-Reply-To: References: <41D1CC9E.5080409@wordtech-software.com> Message-ID: On 28-dec-04, at 22:32, Bob Ippolito wrote: > > On Dec 28, 2004, at 4:14 PM, Kevin Walzer wrote: > >> Kevin-Walzers-Computer:~/Desktop/eric-3.5.1/eric kevin$ py2applet >> eric3.py >> from: can't read /var/mail/py2app.scripts.script_py2applet >> /usr/local/bin/py2applet: line 3: syntax error: unexpected end of file > > Sounds like the hash-bang is missing from /usr/local/bin/py2applet. > I'm not sure why that is, I haven't been able to reproduce with svn > trunk. That's because you fixed it several weeks ago :-) Ronald From ronaldoussoren at mac.com Wed Dec 29 10:50:52 2004 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Wed Dec 29 10:50:54 2004 Subject: [Pythonmac-SIG] How badly is _locale broken? In-Reply-To: <41D1DA1A.5050206@ocf.berkeley.edu> References: <41D1DA1A.5050206@ocf.berkeley.edu> Message-ID: <20A4B660-597F-11D9-85EE-000D93AD379E@mac.com> On 28-dec-04, at 23:11, Brett C. wrote: > I am planning to attempt to fix the _locale module (which 'locale' > itself imports and uses) for OS X. As of this exact moment I am > planning just fixing localeconv (thanks to CFNumberFormatter and > setlocale still at least storing the supposed locale, even if it does > ignore it), but I realized other stuff might be broken. > > Since I never personally use the module, does anyone know the extent > of the breakage? Obviously I would rather just have to fix localeconv > and keep my life simple, but if it is more extensive I can see what I > can do. Not linking with the CoreServices and Foundation frameworks would do the trick. That might cause problems elsewhere though :-(. Ronald From postmaster at fgranger.com Tue Dec 28 19:27:24 2004 From: postmaster at fgranger.com (Francois Granger) Date: Wed Dec 29 11:11:33 2004 Subject: [Pythonmac-SIG] Popen2 Message-ID: I am trying to use popen2.popen3 and I am stuck. I tested the command line I am building and it works ok. This may be due to my lack of knowledge of the command line functionnalities... But this script either hang or raise an error. This is the bare bone script directly copied from the sample: #!/usr/bin/env python # -*- coding: utf-8 -*- """r, w, e = popen2.popen3('python slave.py') e.readlines() r.readlines() r.close() e.close() w.close()""" import popen2 theString = file('testfiles/notes.htm').read() source = 'macintosh' target = 'UTF-8' r, w, e = popen2.popen3('iconv -f ' + source.upper() + ' -t ' + target.upper() + '//TRANSLIT') w.write(theString) e.readlines() result = r.readlines() r.close() e.close() w.close() print result pass From kblack at jsd.claremont.edu Tue Dec 28 19:51:30 2004 From: kblack at jsd.claremont.edu (Kersey Black) Date: Wed Dec 29 11:11:35 2004 Subject: [Pythonmac-SIG] dyld trying to link against wrong version of Python Message-ID: <7C5D4166-5901-11D9-A50E-000A95AF0E6C@jsd.claremont.edu> Hi all, I first confess to being a newbie, but that will probably be obvious. I am trying to set up my powerbook for python work. It has 10.3.7, current dev xcode tools, etc. I want Numeric, numarrray, and scipy modules. I thought I would upgrade to python 2.4, and tried to do so with a framework install. I ran into problems (getting waste to link in the compile), and realized, that having never used a mac for development (I do have unix experience) I would be better sticking to the core system already provided, Python 2.3. I then tried to use the package manager in MacPython-2.3 to install Numeric and numarray (from different sites). Numeric worked, numarray did not and was very out of date. So, i tried to compile the new version(1.1.1). I had some trouble with getting it to install, and while struggling with that I realized i better get rid of all traces of the aborted install of Python-2.4 framework. I removed" /Library/Frameworks/Python.framework [the default installation site for 2.4 build] /Library/Python /Applications/MacPython-2.4 ~/.idlerc /System/Library/Frameworks/Python.framwork/Versions/2.3/Headers/numarray and any preference files I could find related to python. over a couple of more times through this, I also removed and reinstalled /Applications/MacPython-2.3 (twice) I have removed other modules (Numeric, PIL. OpenGL), because I am not sure if there are conflicts. Here is the problem: I build and install numarray-1.1.1 into the /Library/Python directory I start Python-2.3 and ask for it to import numarray here is what I get: Traceback (most recent call last): File "", line 1, in ? File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages/numarray/__init__.py", line 42, in ? from numarrayall import * File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages/numarray/numarrayall.py", line 1, in ? from numerictypes import * File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages/numarray/numerictypes.py", line 35, in ? import numinclude File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages/numarray/numinclude.py", line 4, in ? import _ndarray ImportError: Failure linking new module: /Library/Frameworks/Python.framework/Versions/2.4/Python: dyld: python can't open library: /Library/Frameworks/Python.framework/Versions/2.4/Python (No such file or directory, errno = 2) It is still trying to link against a Python-2.4, even though I think I have removed all traces. Why is it trying to find the long since removed Python-2.4?? Further, if I import sys, and then import numarray, the import error is the same. BUT, if I import sys, try to import numarray which generates the same error above, then type sys.path, and then import numarray, the error goes away, but the import seems to have failed none the less. >>> sys.path ['', '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python23.zip', '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3', '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/plat-darwin', '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/plat-mac', '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/plat-mac/lib-scriptpackages', '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/lib-tk', '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/lib-dynload', '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages'] >>> import numarray >>> numarray.__version__ Traceback (most recent call last): File "", line 1, in ? AttributeError: 'module' object has no attribute '__version__' Any help would be greatly appreciated. Again, why is numarray thinking there is a 2.4 version. In other environments I would just reinstall Python-2.3 from the ground up, but working from the Apple CDs I do not see how to do that. If anyone knows how to do that, it could also be a solution, or not. Cheers, Kersey From bob at redivi.com Wed Dec 29 11:23:04 2004 From: bob at redivi.com (Bob Ippolito) Date: Wed Dec 29 11:23:12 2004 Subject: [Pythonmac-SIG] How badly is _locale broken? In-Reply-To: <20A4B660-597F-11D9-85EE-000D93AD379E@mac.com> References: <41D1DA1A.5050206@ocf.berkeley.edu> <20A4B660-597F-11D9-85EE-000D93AD379E@mac.com> Message-ID: On Dec 29, 2004, at 4:50 AM, Ronald Oussoren wrote: > On 28-dec-04, at 23:11, Brett C. wrote: > >> I am planning to attempt to fix the _locale module (which 'locale' >> itself imports and uses) for OS X. As of this exact moment I am >> planning just fixing localeconv (thanks to CFNumberFormatter and >> setlocale still at least storing the supposed locale, even if it does >> ignore it), but I realized other stuff might be broken. >> >> Since I never personally use the module, does anyone know the extent >> of the breakage? Obviously I would rather just have to fix >> localeconv and keep my life simple, but if it is more extensive I can >> see what I can do. > > Not linking with the CoreServices and Foundation frameworks would do > the trick. That might cause problems elsewhere though :-(. I think someone said this is fixed on 10.4, so you can just wait a while and it'll probably fix itself using the generic unix code. Yes, not linking to CoreFoundation will cause problems, because *something* will inevitably link to CF. For example, the py2app bootstrap will link to CF. A bunch of the extension modules in MacPython also independently link to CF-using frameworks. -bob From Jack.Jansen at cwi.nl Wed Dec 29 11:23:52 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Wed Dec 29 11:23:53 2004 Subject: [Pythonmac-SIG] Re: [Python-Dev] Re: [Python-checkins] python/dist/src/Mac/OSX fixapplepython23.py, 1.1, 1.2 In-Reply-To: References: Message-ID: On 29-dec-04, at 4:35, Bob Ippolito wrote: > This is the wrong fix. Distutils is dumber than you think. This > patch just breaks C++ compilation in a different way. The correct > solution is a patch to distutils of some kind. > > from distutils/unixccompiler.py:174 > > if target_lang == "c++" and self.compiler_cxx: > linker[0] = self.compiler_cxx[0] > self.spawn(linker + ld_args) > > "linker" is the variable expanded LDSHARED (or whatever comes out of > sysconfig.customize_compiler). Bah! Any suggestions as to what to do to get c++ compilation fixed? Also, could you point me to a readily available extension package that uses c++? -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From bob at redivi.com Wed Dec 29 11:30:59 2004 From: bob at redivi.com (Bob Ippolito) Date: Wed Dec 29 11:31:14 2004 Subject: [Pythonmac-SIG] dyld trying to link against wrong version of Python In-Reply-To: <7C5D4166-5901-11D9-A50E-000A95AF0E6C@jsd.claremont.edu> References: <7C5D4166-5901-11D9-A50E-000A95AF0E6C@jsd.claremont.edu> Message-ID: On Dec 28, 2004, at 1:51 PM, Kersey Black wrote: > I first confess to being a newbie, but that will probably be obvious. > I am trying to set up my powerbook for python work. It has 10.3.7, > current dev xcode tools, etc. > > I want Numeric, numarrray, and scipy modules. > I thought I would upgrade to python 2.4, and tried to do so with a > framework install. I ran into problems (getting waste to link in the > compile), and realized, that having never used a mac for development > (I do have unix experience) I would be better sticking to the core > system already provided, Python 2.3. > > I then tried to use the package manager in MacPython-2.3 to install > Numeric and numarray (from different sites). Numeric worked, numarray > did not and was very out of date. So, i tried to compile the new > version(1.1.1). I had some trouble with getting it to install, and > while struggling with that I realized i better get rid of all traces > of the aborted install of Python-2.4 framework. I would recommend not using anything from the undefined.org repository. I do not actively maintain it, so everything is out of date. I have no plans to update it until the infrastructure behind the package management crap changes, because what we have now is nasty and I just don't have time for it. > I removed" > /Library/Frameworks/Python.framework [the default installation site > for 2.4 build] > /Library/Python > /Applications/MacPython-2.4 > ~/.idlerc > /System/Library/Frameworks/Python.framwork/Versions/2.3/Headers/ > numarray > and any preference files I could find related to python. You forgot to remove your build directories.. see below. > over a couple of more times through this, I also > removed and reinstalled /Applications/MacPython-2.3 (twice) > > I have removed other modules (Numeric, PIL. OpenGL), because I am not > sure if there are conflicts. > > Here is the problem: > I build and install numarray-1.1.1 into the /Library/Python directory > I start Python-2.3 and ask for it to import numarray > here is what I get: > Traceback (most recent call last): > File "", line 1, in ? > File > "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/site-packages/numarray/__init__.py", line 42, in ? > from numarrayall import * > File > "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/site-packages/numarray/numarrayall.py", line 1, in ? > from numerictypes import * > File > "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/site-packages/numarray/numerictypes.py", line 35, in ? > import numinclude > File > "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/site-packages/numarray/numinclude.py", line 4, in ? > import _ndarray > ImportError: Failure linking new module: > /Library/Frameworks/Python.framework/Versions/2.4/Python: dyld: python > can't open library: > /Library/Frameworks/Python.framework/Versions/2.4/Python (No such > file or directory, errno = 2) > > It is still trying to link against a Python-2.4, even though I think I > have removed all traces. > Why is it trying to find the long since removed Python-2.4?? Because it was linked when the Python 2.4 framework existed. > Further, > if I import sys, and then import numarray, the import error is the > same. > BUT, if I import sys, try to import numarray which generates the same > error above, then type sys.path, and then import numarray, the error > goes away, but the import seems to have failed none the less. Python imports will fail once, and then leave a broken module in sys.modules, so a second import will erroneously succeed. It's dumb, but that's how Python works. > >>> sys.path > ['', > '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python23.zip', > '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3', > '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/plat-darwin', > '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/plat-mac', > '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/plat-mac/lib-scriptpackages', > '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/lib-tk', > '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/lib-dynload', > '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/site-packages'] > >>> import numarray > >>> numarray.__version__ > Traceback (most recent call last): > File "", line 1, in ? > AttributeError: 'module' object has no attribute '__version__' > > Any help would be greatly appreciated. Again, why is numarray > thinking there is a 2.4 version. In other environments I would just > reinstall Python-2.3 from the ground up, but working from the Apple > CDs I do not see how to do that. If anyone knows how to do that, it > could also be a solution, or not. This is a bug in Python 2.3.0 that has been discussed A LOT on this list, most recently . Your "phantom framework" problem is because you didn't clobber the build directory for numarray. It cached the incorrectly built extensions that were compiled when the Python 2.4 framework was present. Kill the build directory and compile/install again. -bob From ronaldoussoren at mac.com Wed Dec 29 11:32:32 2004 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Wed Dec 29 11:32:42 2004 Subject: [Pythonmac-SIG] How badly is _locale broken? In-Reply-To: References: <41D1DA1A.5050206@ocf.berkeley.edu> <20A4B660-597F-11D9-85EE-000D93AD379E@mac.com> Message-ID: On 29-dec-04, at 11:23, Bob Ippolito wrote: > On Dec 29, 2004, at 4:50 AM, Ronald Oussoren wrote: > >> On 28-dec-04, at 23:11, Brett C. wrote: >> >>> I am planning to attempt to fix the _locale module (which 'locale' >>> itself imports and uses) for OS X. As of this exact moment I am >>> planning just fixing localeconv (thanks to CFNumberFormatter and >>> setlocale still at least storing the supposed locale, even if it >>> does ignore it), but I realized other stuff might be broken. >>> >>> Since I never personally use the module, does anyone know the extent >>> of the breakage? Obviously I would rather just have to fix >>> localeconv and keep my life simple, but if it is more extensive I >>> can see what I can do. >> >> Not linking with the CoreServices and Foundation frameworks would do >> the trick. That might cause problems elsewhere though :-(. > > I think someone said this is fixed on 10.4, so you can just wait a > while and it'll probably fix itself using the generic unix code. > > Yes, not linking to CoreFoundation will cause problems, because > *something* will inevitably link to CF. For example, the py2app > bootstrap will link to CF. A bunch of the extension modules in > MacPython also independently link to CF-using frameworks. I know that. But not linking with CoreServices should fix _locale for python scripts that don't use mac-specific features. The correct fix would probably use CFLocale to implement the _locale module on OSX. Ronald From bob at redivi.com Wed Dec 29 11:40:30 2004 From: bob at redivi.com (Bob Ippolito) Date: Wed Dec 29 11:40:40 2004 Subject: [Pythonmac-SIG] Re: [Python-Dev] Re: [Python-checkins] python/dist/src/Mac/OSX fixapplepython23.py, 1.1, 1.2 In-Reply-To: References: Message-ID: <0F7FB55E-5986-11D9-9660-000A9567635C@redivi.com> On Dec 29, 2004, at 5:23 AM, Jack Jansen wrote: > On 29-dec-04, at 4:35, Bob Ippolito wrote: > >> This is the wrong fix. Distutils is dumber than you think. This >> patch just breaks C++ compilation in a different way. The correct >> solution is a patch to distutils of some kind. >> >> from distutils/unixccompiler.py:174 >> >> if target_lang == "c++" and self.compiler_cxx: >> linker[0] = self.compiler_cxx[0] >> self.spawn(linker + ld_args) >> >> "linker" is the variable expanded LDSHARED (or whatever comes out of >> sysconfig.customize_compiler). > > Bah! > > Any suggestions as to what to do to get c++ compilation fixed? I can think of two ways: 1. Patch distutils to actually do os.environ['MACOSX_DEPLOYMENT_TARGET'] = '10.3' because CCompiler.spawn doesn't take an environment dict. 2. Patch distutils to skip over environment variables (basically change that "0" into something smarter). This is probably less desirable because who knows where this happens, and who knows what third party compiler subclasses used this original stupid code as a template. In either case, setting the environment variable should only be done if it's not already set, and it should raise if is set to anything lower than 10.3. For example, an existing MACOSX_DEPLOYMENT_TARGET variable of 10.4 should be allowed. Values smaller than 10.3 should not be allowed because they are incompatible with the linker feature we're trying to enable. > Also, could you point me to a readily available extension package that > uses c++? I have no idea, but I remember this issue was brought up at some point during one of the many discussions of this issue. I think it was also mentioned that SciPy's distutils extensions (or is it a fork?) does something similarly stupid when frobbing in a Fortran compiler. -bob From bob at redivi.com Wed Dec 29 11:48:35 2004 From: bob at redivi.com (Bob Ippolito) Date: Wed Dec 29 11:48:41 2004 Subject: [Pythonmac-SIG] How badly is _locale broken? In-Reply-To: References: <41D1DA1A.5050206@ocf.berkeley.edu> <20A4B660-597F-11D9-85EE-000D93AD379E@mac.com> Message-ID: <3088E920-5987-11D9-9660-000A9567635C@redivi.com> On Dec 29, 2004, at 5:32 AM, Ronald Oussoren wrote: > On 29-dec-04, at 11:23, Bob Ippolito wrote: > >> On Dec 29, 2004, at 4:50 AM, Ronald Oussoren wrote: >> >>> On 28-dec-04, at 23:11, Brett C. wrote: >>> >>>> I am planning to attempt to fix the _locale module (which 'locale' >>>> itself imports and uses) for OS X. As of this exact moment I am >>>> planning just fixing localeconv (thanks to CFNumberFormatter and >>>> setlocale still at least storing the supposed locale, even if it >>>> does ignore it), but I realized other stuff might be broken. >>>> >>>> Since I never personally use the module, does anyone know the >>>> extent of the breakage? Obviously I would rather just have to fix >>>> localeconv and keep my life simple, but if it is more extensive I >>>> can see what I can do. >>> >>> Not linking with the CoreServices and Foundation frameworks would do >>> the trick. That might cause problems elsewhere though :-(. >> >> I think someone said this is fixed on 10.4, so you can just wait a >> while and it'll probably fix itself using the generic unix code. >> >> Yes, not linking to CoreFoundation will cause problems, because >> *something* will inevitably link to CF. For example, the py2app >> bootstrap will link to CF. A bunch of the extension modules in >> MacPython also independently link to CF-using frameworks. > > I know that. But not linking with CoreServices should fix _locale for > python scripts that don't use mac-specific features. Well, my patch to remove all non-libSystem dependencies from the Python core was accepted for Python 2.4, so we are already at this point. However, the mac toolbox functions can lazily import CF-using modules. I think the core probably uses some of these functions. Last I remember, the locale module itself linked to CF (directly or indirectly) so it could guess what the current locale should be :) > The correct fix would probably use CFLocale to implement the _locale > module on OSX. Yes, that would be a good fix. Alternatively, we could just punt on the issue and say "you need to use 10.X in order to have a working locale module", where 10.X is the version that Apple fixes CF. X is obviously greater than 3, but I don't think it will be much greater. It's been broken for this long, and Brett C. said he doesn't use the locale module, so it may be too much effort for too little reward. -bob From mwh at python.net Wed Dec 29 12:06:32 2004 From: mwh at python.net (Michael Hudson) Date: Wed Dec 29 12:06:34 2004 Subject: [Pythonmac-SIG] How badly is _locale broken? In-Reply-To: <3088E920-5987-11D9-9660-000A9567635C@redivi.com> (Bob Ippolito's message of "Wed, 29 Dec 2004 05:48:35 -0500") References: <41D1DA1A.5050206@ocf.berkeley.edu> <20A4B660-597F-11D9-85EE-000D93AD379E@mac.com> <3088E920-5987-11D9-9660-000A9567635C@redivi.com> Message-ID: <2md5wticsn.fsf@starship.python.net> Bob Ippolito writes: > Alternatively, we could just punt on the issue and say "you need to > use 10.X in order to have a working locale module", where 10.X is the > version that Apple fixes CF. X is obviously greater than 3, but I > don't think it will be much greater. It's been broken for this long, > and Brett C. said he doesn't use the locale module, so it may be too > much effort for too little reward. It would be nice if the unit tests stop failing, though. Cheers, mwh -- Screaming 14-year-old boys attempting to prove to each other that they are more 3133t than j00. -- Reason #8 for quitting slashdot today, from http://www.cs.washington.edu/homes/klee/misc/slashdot.html From bob at redivi.com Wed Dec 29 12:13:38 2004 From: bob at redivi.com (Bob Ippolito) Date: Wed Dec 29 12:13:49 2004 Subject: [Pythonmac-SIG] How badly is _locale broken? In-Reply-To: <2md5wticsn.fsf@starship.python.net> References: <41D1DA1A.5050206@ocf.berkeley.edu> <20A4B660-597F-11D9-85EE-000D93AD379E@mac.com> <3088E920-5987-11D9-9660-000A9567635C@redivi.com> <2md5wticsn.fsf@starship.python.net> Message-ID: On Dec 29, 2004, at 6:06 AM, Michael Hudson wrote: > Bob Ippolito writes: > >> Alternatively, we could just punt on the issue and say "you need to >> use 10.X in order to have a working locale module", where 10.X is the >> version that Apple fixes CF. X is obviously greater than 3, but I >> don't think it will be much greater. It's been broken for this long, >> and Brett C. said he doesn't use the locale module, so it may be too >> much effort for too little reward. > > It would be nice if the unit tests stop failing, though. So skip them and disable (or at least throw up a warning that says those locale functions don't actually work) the module if not using 10.X or later. -bob From sw at wordtech-software.com Wed Dec 29 16:31:46 2004 From: sw at wordtech-software.com (Kevin Walzer) Date: Wed Dec 29 16:31:51 2004 Subject: [Pythonmac-SIG] Kodos Message-ID: <41D2CDE2.4030701@wordtech-software.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have a working app bundle of Kodos put together...I haven't released it because I wasn't sure anyone would be interested in it, but it works fine with my PyQt-Mac distribution. Let me know if you'd like me to post it for download. - -- Cheers, Kevin Walzer, PhD WordTech Software--Open Source Applications and Packages for OS X http://www.wordtech-software.com http://www.smallbizmac.com http://www.kevin-walzer.com mailto:sw@wordtech-software.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB0s3hJmdQs+6YVcoRAvIuAJ4+4G31sPmDM0Z/ufrul0u3w1Lc3wCghgt8 3mlrb6FLlqehCL73pQh4FGQ= =LlBW -----END PGP SIGNATURE----- From sw at wordtech-software.com Wed Dec 29 17:58:03 2004 From: sw at wordtech-software.com (Kevin Walzer) Date: Wed Dec 29 17:58:19 2004 Subject: [Pythonmac-SIG] BuildApplet in next distro of MacPython? Message-ID: <41D2E21B.3020800@wordtech-software.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm curious about whether BuildApplet and PythonIDE will be included in the next iteration of MacPython, or whether these will be replaced by py2app and PyOxide. Although I know these are old technologies, especially BuildApplet, I'd like to request that they be retained, even if they're not updated or enhanced. The reason I'm asking is that I make extensive use of BuildApplet in the packages I maintain. I've had inconsistent luck with BundleBuilder, py2app, and py2applet--mostly bad luck. The nice thing about BuildApplet that it is, in fact, very simple, even dumb, in creating applications: it saves the script in question, that's it. It then becomes a simple matter to add the additional scripts that come with an application to the app bundle in the appropriate directory, to edit the info.plist file, to change the icon, etc. In short, I have control over almost the entire process of packaging. And I've documented this process pretty thoroughly at my website. I realize there are tradeoffs with this approach. Apps I bundle with BuildApplet don't have their external dependencies included (wxPython, PyQt, whatever). But if those external dependencies are installed on the ~ user machine, then the BuildApplet process works flawlessly. py2app is a lot more elegant and smarter in what it does in terms of packaging, but it's also more complex. That is, if there's an error, it's very hard--at least for me--to debug. The build process dies. I tested this yesterday with both py2app and py2applet with Eric3, an application I have successfully with BuildApplet. With both py2app and py2applet, something didn't get included, even though Bob has now added PyQt support to py2app. Neither he nor I could figure out what the problem was. The result was that the bundle created with py2app crashed, while py2applet just died during the build process. This isn't a complaint about py2app: I've tested it with simpler applications and it works beautifully. By all means, it should be the featured method for packaging apps in MacPython. But if BuildApplet and PythonIDE can be retained, even if it's deprecated, that would be enormously helpful to me. A workable alternative would be if Glenn Andreas continued to include support for BuildApplet in PyOxide. Glenn, is this possible? Cheers, Kevin Walzer, PhD WordTech Software--Open Source Applications and Packages for OS X http://www.wordtech-software.com http://www.smallbizmac.com http://www.kevin-walzer.com mailto:sw@wordtech-software.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB0uIaJmdQs+6YVcoRAuqLAJ9s5DDormJMRtyH/Lp1KccYCF/cLgCeMfKO WWWCmzfcOh5KCQXq/0nZTjY= =vwbz -----END PGP SIGNATURE----- From bob at redivi.com Wed Dec 29 18:57:51 2004 From: bob at redivi.com (Bob Ippolito) Date: Wed Dec 29 18:58:00 2004 Subject: [Pythonmac-SIG] BuildApplet in next distro of MacPython? In-Reply-To: <41D2E21B.3020800@wordtech-software.com> References: <41D2E21B.3020800@wordtech-software.com> Message-ID: <287A2B77-59C3-11D9-9660-000A9567635C@redivi.com> On Dec 29, 2004, at 11:58 AM, Kevin Walzer wrote: > I'm curious about whether BuildApplet and PythonIDE will be included in > the next iteration of MacPython, or whether these will be replaced by > py2app and PyOxide. Although I know these are old technologies, > especially BuildApplet, I'd like to request that they be retained, even > if they're not updated or enhanced. Nothing is going away anytime soon. I'm sure your concerns will be addressed by the time this is even an issue, assuming that you are willing to request features and report bugs to py2app. > The reason I'm asking is that I make extensive use of BuildApplet in > the > packages I maintain. I've had inconsistent luck with BundleBuilder, > py2app, and py2applet--mostly bad luck. If you give up on reporting issues and whatnot with py2app it's not ever going to suit your needs. py2app's alias build mode (-A) is equivalent to what BuildApplet does *except* the output isn't *ever* portable to other machines because it keeps references not copies to the scripts and data files. It works perfectly fine for "from IDE" use. > The nice thing about BuildApplet that it is, in fact, very simple, even > dumb, in creating applications: it saves the script in question, that's > it. It then becomes a simple matter to add the additional scripts that > come with an application to the app bundle in the appropriate > directory, > to edit the info.plist file, to change the icon, etc. > > In short, I have control over almost the entire process of packaging. > And I've documented this process pretty thoroughly at my website. Adding dependencies by hand is really sketchy. In order to do it right, it basically has to be all or nothing (until py2app has an interactive mode anyway). Right now py2app's "nothing" option is not portable to other machines. However since py2app alias bundles are so quick to create and the output is so small you can just make one at the destination machine. Which of course, already has "everything", including py2app. It is not even possible to correctly include the following, very common, kinds of dependencies after-the-fact: 1. Are compiled with an unpatched Python or 2. Are compiled in a 10.2 compatible way 3. Depend on third party dylibs By "not even possible" I mean that you won't do it correctly unless you REALLY know what you are doing with install_name_tool, etc. If you did, you would probably rather had py2app do it for you anyway, because I guarantee it's not any fun. > I realize there are tradeoffs with this approach. Apps I bundle with > BuildApplet don't have their external dependencies included (wxPython, > PyQt, whatever). But if those external dependencies are installed on > the > ~ user machine, then the BuildApplet process works flawlessly. That's an extremely big if and is only really relevant if you're distributing software to other Python developers or inside of a controlled organization. py2app's alias mode works a lot like that, except it's not portable to other machines because aliases and symlinks are used internally. However, in both scenarios where BuildApplet's output is useful, this is actually reasonable. Python developers can type "python setup.py py2app -A" themselves. In a controlled organization, this could be done as part of the installation process for your application, since py2app and everything else will already be installed by other means. > py2app is a lot more elegant and smarter in what it does in terms of > packaging, but it's also more complex. That is, if there's an error, > it's very hard--at least for me--to debug. The build process dies. I > tested this yesterday with both py2app and py2applet with Eric3, an > application I have successfully with BuildApplet. With both py2app and > py2applet, something didn't get included, even though Bob has now added > PyQt support to py2app. Neither he nor I could figure out what the > problem was. The result was that the bundle created with py2app > crashed, > while py2applet just died during the build process. If you want "stupid" output from py2app, pass --site-packages. This means your applications will work locally, since the missing modules will be searched for in the normal manner, but your application now has a high probability of not working on another machine. Hopefully it's obvious why this is not the default. Since you were unwilling to even post the results of my suggestion yesterday, implicating me in "neither he nor I could figure out..." is a bad way to put it. Basically, you haven't yet done anything beyond your initial message to help me figure it out, and are throwing your hands up because I didn't immediately know what kind of craziness is involved in Eric3 and how that affects py2app off the top of my head. That said, the way to solve this problem is to create a setup.py and tweak the includes option until the application has everything it needs. Write down which modules you had to add, and then figure out why the heck they were missing. If it turns out that this happened due to something in PyQt, not the application, then I can make py2app automatically work around whatever stupid import trick caused this to fail for PyQt from the recipe that currently deals with other sip-specific garbage. > This isn't a complaint about py2app: I've tested it with simpler > applications and it works beautifully. By all means, it should be the > featured method for packaging apps in MacPython. But if BuildApplet and > PythonIDE can be retained, even if it's deprecated, that would be > enormously helpful to me. > > A workable alternative would be if Glenn Andreas continued to include > support for BuildApplet in PyOxide. Glenn, is this possible? py2app is a better choice than BuildApplet for PyOxide. Adding support for BuildApplet before or in addition to py2app seems backwards. Adding support for alias mode is definitely important for something like PyOxide, which would suit your use case (aside from machine portability), and machine portability with a stupid bundle isn't really very useful or important, as I mentioned above. Perhaps in the future py2app will have a mode similar to alias mode that makes the stupidest dependency-free "self-contained" bundle that could possibly work (locally), but I am still unconvinced that this is more useful than dangerous and confusing. -bob From sw at wordtech-software.com Wed Dec 29 19:40:21 2004 From: sw at wordtech-software.com (Kevin Walzer) Date: Wed Dec 29 19:40:51 2004 Subject: [Pythonmac-SIG] BuildApplet in next distro of MacPython? In-Reply-To: <287A2B77-59C3-11D9-9660-000A9567635C@redivi.com> References: <41D2E21B.3020800@wordtech-software.com> <287A2B77-59C3-11D9-9660-000A9567635C@redivi.com> Message-ID: <41D2FA15.9010101@wordtech-software.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Bob Ippolito wrote: | | | If you give up on reporting issues and whatnot with py2app it's not ever | going to suit your needs. I won't stop reporting bugs. Frankly, part of the issue is that I don't have time to learn py2app deeply. At some point in the near future, I'm going to drill more deeply into it. | | | Adding dependencies by hand is really sketchy. In order to do it right, | it basically has to be all or nothing (until py2app has an interactive | mode anyway). Right now py2app's "nothing" option is not portable to | other machines. However since py2app alias bundles are so quick to | create and the output is so small you can just make one at the | destination machine. Which of course, already has "everything", | including py2app. Perhaps I wasn't clear. I don't add *any* dependencies except those that ~ come with the application itself: i.e. I simply copy the directory structure of the application (wxGlade, Pears, what have you) into the app bundle. Any external libraries such as wxPython have to be installed separately by the end user. | | Since you were unwilling to even post the results of my suggestion | yesterday, implicating me in "neither he nor I could figure out..." is a | bad way to put it. Basically, you haven't yet done anything beyond your | initial message to help me figure it out, and are throwing your hands up | because I didn't immediately know what kind of craziness is involved in | Eric3 and how that affects py2app off the top of my head. Yes, you're right, and I apologize for my tone there. Please attribute that to a hastily scribbled e-mail. Here's what I should have said: "The build died. Bob gave me a few suggestions to try, none of which I was able to make work. I contacted the developer of Eric3 to find out what module was missing, and he said it was specifically part of Eric3. ~ I haven't had time to drill more deeply into how to this module integrated into the build." | | That said, the way to solve this problem is to create a setup.py and | tweak the includes option until the application has everything it | needs. Write down which modules you had to add, and then figure out why | the heck they were missing. If it turns out that this happened due to | something in PyQt, not the application, then I can make py2app | automatically work around whatever stupid import trick caused this to | fail for PyQt from the recipe that currently deals with other | sip-specific garbage. OK. This is what I will do--when I have a bit more time. Going through that effort will get me better acquainted with py2app. | | | py2app is a better choice than BuildApplet for PyOxide. Adding support | for BuildApplet before or in addition to py2app seems backwards. Adding | support for alias mode is definitely important for something like | PyOxide, which would suit your use case (aside from machine | portability), and machine portability with a stupid bundle isn't really | very useful or important, as I mentioned above. | | Perhaps in the future py2app will have a mode similar to alias mode that | makes the stupidest dependency-free "self-contained" bundle that could | possibly work (locally), but I am still unconvinced that this is more | useful than dangerous and confusing. | | -bob | If "save as applet" from PythonIDE is as non-portable as you say, I'm curious why I haven't gotten any bug reports on the apps I've built that way. I do try to make the external dependencies (MacPython add-ons, wxPython, Tk, PyQt) explicit, and I do provide links for folks to download and install them. Perhaps that's the reason? Kevin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB0voUJmdQs+6YVcoRAg9nAJ9Elktb7TZU/+r9RbtoBdIpQVeuJACfVRkI k16ThhWMPH9VUZdph3Ye4Dk= =JTEZ -----END PGP SIGNATURE----- From charles.hartman at conncoll.edu Wed Dec 29 21:47:14 2004 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Wed Dec 29 21:47:20 2004 Subject: [Pythonmac-SIG] Kodos In-Reply-To: <41D2CDE2.4030701@wordtech-software.com> References: <41D2CDE2.4030701@wordtech-software.com> Message-ID: Yes please! With Bob Ippolito's helpful pointer (the QPL is **not** easily evident on the Troll web site) I now have the free version of PyQt, though I haven't tested it yet. I'd love to see Kodos. On the SourceForge.net page? Charles Hartman Professor of English, Poet in Residence http://cherry.conncoll.edu/cohar http://villex.blogspot.com On Dec 29, 2004, at 10:31 AM, Kevin Walzer wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I have a working app bundle of Kodos put together...I haven't released > it because I wasn't sure anyone would be interested in it, but it works > fine with my PyQt-Mac distribution. Let me know if you'd like me to > post > it for download. > > - -- > Cheers, > > Kevin Walzer, PhD > WordTech Software--Open Source Applications and Packages for OS X > http://www.wordtech-software.com > http://www.smallbizmac.com > http://www.kevin-walzer.com > mailto:sw@wordtech-software.com > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.4 (Darwin) > Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org > > iD8DBQFB0s3hJmdQs+6YVcoRAvIuAJ4+4G31sPmDM0Z/ufrul0u3w1Lc3wCghgt8 > 3mlrb6FLlqehCL73pQh4FGQ= > =LlBW > -----END PGP SIGNATURE----- > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From charles.hartman at conncoll.edu Wed Dec 29 21:51:26 2004 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Wed Dec 29 21:51:29 2004 Subject: [Pythonmac-SIG] BuildApplet in next distro of MacPython? In-Reply-To: <41D2E21B.3020800@wordtech-software.com> References: <41D2E21B.3020800@wordtech-software.com> Message-ID: <67F17673-59DB-11D9-9FDE-000D933C27EA@conncoll.edu> Please not PyOxide. I used it for a while, I like it -- but it doesn't work, and it hasn't been worked on or updated in months. The current PythonIDE is minimal and shabby, but it works just fine. Charles Hartman Professor of English, Poet in Residence http://cherry.conncoll.edu/cohar http://villex.blogspot.com On Dec 29, 2004, at 11:58 AM, Kevin Walzer wrote: > I'm curious about whether BuildApplet and PythonIDE will be included in > the next iteration of MacPython, or whether these will be replaced by > py2app and PyOxide. Although I know these are old technologies, > especially BuildApplet, I'd like to request that they be retained, even > if they're not updated or enhanced. From charles.hartman at conncoll.edu Wed Dec 29 21:52:52 2004 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Wed Dec 29 21:52:56 2004 Subject: [Pythonmac-SIG] Kodos In-Reply-To: <41D2CDE2.4030701@wordtech-software.com> References: <41D2CDE2.4030701@wordtech-software.com> Message-ID: <9B497B84-59DB-11D9-9FDE-000D933C27EA@conncoll.edu> Yes please! With Bob Ippolito's helpful pointer (the QPL is **not** easily evident on the Troll web site) I now have the free version of PyQt, though I haven't tested it yet. I'd love to see Kodos. On the SourceForge.net page? Charles Hartman Professor of English, Poet in Residence http://cherry.conncoll.edu/cohar http://villex.blogspot.com On Dec 29, 2004, at 10:31 AM, Kevin Walzer wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I have a working app bundle of Kodos put together...I haven't released > it because I wasn't sure anyone would be interested in it, but it works > fine with my PyQt-Mac distribution. Let me know if you'd like me to > post > it for download. > > - -- > Cheers, > > Kevin Walzer, PhD > WordTech Software--Open Source Applications and Packages for OS X > http://www.wordtech-software.com > http://www.smallbizmac.com > http://www.kevin-walzer.com > mailto:sw@wordtech-software.com > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.4 (Darwin) > Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org > > iD8DBQFB0s3hJmdQs+6YVcoRAvIuAJ4+4G31sPmDM0Z/ufrul0u3w1Lc3wCghgt8 > 3mlrb6FLlqehCL73pQh4FGQ= > =LlBW > -----END PGP SIGNATURE----- > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From bob at redivi.com Wed Dec 29 22:20:10 2004 From: bob at redivi.com (Bob Ippolito) Date: Wed Dec 29 22:20:24 2004 Subject: [Pythonmac-SIG] BuildApplet in next distro of MacPython? In-Reply-To: <41D2FA15.9010101@wordtech-software.com> References: <41D2E21B.3020800@wordtech-software.com> <287A2B77-59C3-11D9-9660-000A9567635C@redivi.com> <41D2FA15.9010101@wordtech-software.com> Message-ID: <6BFB92D0-59DF-11D9-9660-000A9567635C@redivi.com> On Dec 29, 2004, at 1:40 PM, Kevin Walzer wrote: > | py2app is a better choice than BuildApplet for PyOxide. Adding > support > | for BuildApplet before or in addition to py2app seems backwards. > Adding > | support for alias mode is definitely important for something like > | PyOxide, which would suit your use case (aside from machine > | portability), and machine portability with a stupid bundle isn't > really > | very useful or important, as I mentioned above. > | > | Perhaps in the future py2app will have a mode similar to alias mode > that > | makes the stupidest dependency-free "self-contained" bundle that > could > | possibly work (locally), but I am still unconvinced that this is more > | useful than dangerous and confusing. > > If "save as applet" from PythonIDE is as non-portable as you say, I'm > curious why I haven't gotten any bug reports on the apps I've built > that > way. I do try to make the external dependencies (MacPython add-ons, > wxPython, Tk, PyQt) explicit, and I do provide links for folks to > download and install them. Perhaps that's the reason? I said that py2app's alias mode is non-portable. BuildApplet creates portable applications that work if all dependencies are expected to already be installed. You probably haven't received bug reports because you have an audience of developers who are used to and willing to install all these dependencies. Pointing them all out probably helps, too. -bob From sw at wordtech-software.com Wed Dec 29 22:29:53 2004 From: sw at wordtech-software.com (Kevin Walzer) Date: Wed Dec 29 22:29:58 2004 Subject: [Pythonmac-SIG] BuildApplet in next distro of MacPython? In-Reply-To: <6BFB92D0-59DF-11D9-9660-000A9567635C@redivi.com> References: <41D2E21B.3020800@wordtech-software.com> <287A2B77-59C3-11D9-9660-000A9567635C@redivi.com> <41D2FA15.9010101@wordtech-software.com> <6BFB92D0-59DF-11D9-9660-000A9567635C@redivi.com> Message-ID: <41D321D1.3010508@wordtech-software.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Bob Ippolito wrote: | | I said that py2app's alias mode is non-portable. BuildApplet creates | portable applications that work if all dependencies are expected to | already be installed. Hmmm. That's a good argument to retain BuildApplet in some form. You probably haven't received bug reports because | you have an audience of developers who are used to and willing to | install all these dependencies. You're probably right. I will defintely be working more deeply with py2app because I'm planning to rewrite one or more of my AppleScript Studio applications in Python. Even though those will be open-source applications, they will be targeted at end users, and I will definitely want to create truly portable standalone apps with py2app. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB0yHRJmdQs+6YVcoRAl28AJ9dEsA13g/VW8fAoeDF1/OoelAepQCfZ/3o MqgX5NIMqrdav26xBJybQdw= =KnkD -----END PGP SIGNATURE----- From bob at redivi.com Wed Dec 29 22:45:22 2004 From: bob at redivi.com (Bob Ippolito) Date: Wed Dec 29 22:45:42 2004 Subject: [Pythonmac-SIG] BuildApplet in next distro of MacPython? In-Reply-To: <41D321D1.3010508@wordtech-software.com> References: <41D2E21B.3020800@wordtech-software.com> <287A2B77-59C3-11D9-9660-000A9567635C@redivi.com> <41D2FA15.9010101@wordtech-software.com> <6BFB92D0-59DF-11D9-9660-000A9567635C@redivi.com> <41D321D1.3010508@wordtech-software.com> Message-ID: On Dec 29, 2004, at 4:29 PM, Kevin Walzer wrote: > Bob Ippolito wrote: > > | I said that py2app's alias mode is non-portable. BuildApplet creates > | portable applications that work if all dependencies are expected to > | already be installed. > > Hmmm. That's a good argument to retain BuildApplet in some form. Not really, if anything else, it is an argument to add a "stupid" mode to py2app. However, as I've said before, I'm hesitant to prioritize that since its usage is limited to two targets: very controlled environments, and python software developers. In both cases, it's currently possible and likely better to specify your expected environment by exclusion. In other words, add an exclude for each module/package you expect the user to already have. This is counter to the "ease of use" of BuildApplet, but given how uncommon this use case is, how hard it is to test a BuildApplet application for dependencies (you need two machines), I'd rather leave it as-is for a while because people distributing applications built in this style should at least know what their dependencies are. In your case, you already have to know the definitive list of requirements for documentation purposes, so it's not hard to move that down to the setup.py as excludes. Back to the original problem, you said that these XML modules are specific to Eric3, which means that somewhere along the way Eric3 is doing some non-statement imports or exercising some bug in py2app 0.1.6. Try it again with py2app 0.1.7, which was soft launched earlier today in expectation of a PyObjC 1.2 release later today or tomorrow morning (when I've built+tested the Jaguar package). If that doesn't work, I'll take a look at Eric3 myself to see what's going on and either provide a workaround or compensate for what's going on in py2app 0.1.8. -bob From gandreas at gandreas.com Wed Dec 29 22:57:42 2004 From: gandreas at gandreas.com (gandreas@gandreas.com) Date: Wed Dec 29 22:57:45 2004 Subject: [Pythonmac-SIG] BuildApplet in next distro of MacPython? In-Reply-To: <67F17673-59DB-11D9-9FDE-000D933C27EA@conncoll.edu> References: <41D2E21B.3020800@wordtech-software.com> <67F17673-59DB-11D9-9FDE-000D933C27EA@conncoll.edu> Message-ID: On Dec 29, 2004, at 2:51 PM, Charles Hartman wrote: > Please not PyOxide. I used it for a while, I like it -- but it doesn't > work, and it hasn't been worked on or updated in months. The current > PythonIDE is minimal and shabby, but it works just fine. > > Actually, it has been worked on, but there isn't anything significant yet (OK, so the last release was in the beginning of October, that hardly means it's not being worked on or updated - after all, this all needs to be done in my limited free time). And I've used it on three different computer and works reasonably well on all of them - where are you seeing problems? What exactly happens, etc...? I can't fix what I don't know about. Don't forget - the source is fully available, so you can always work on it yourself and submit fixes, etc... But back on topic (sort of) - I plan to continue to support BundleBuilder (in as much as it is currently supported), but I do plan to add support for py2app. No further work on bundle builder will be done, however, since the future is py2app (though feel free to submit patches on it). Glenn Andreas????????????????????? gandreas@gandreas.com? oh my! Mad, Bad, and Dangerous to Know From sw at wordtech-software.com Wed Dec 29 23:43:06 2004 From: sw at wordtech-software.com (Kevin Walzer) Date: Wed Dec 29 23:43:13 2004 Subject: [Pythonmac-SIG] BuildApplet in next distro of MacPython? In-Reply-To: References: <41D2E21B.3020800@wordtech-software.com> <287A2B77-59C3-11D9-9660-000A9567635C@redivi.com> <41D2FA15.9010101@wordtech-software.com> <6BFB92D0-59DF-11D9-9660-000A9567635C@redivi.com> <41D321D1.3010508@wordtech-software.com> Message-ID: <41D332FA.3000708@wordtech-software.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 | | Back to the original problem, you said that these XML modules are | specific to Eric3, which means that somewhere along the way Eric3 is | doing some non-statement imports or exercising some bug in py2app | 0.1.6. Try it again with py2app 0.1.7, which was soft launched earlier | today in expectation of a PyObjC 1.2 release later today or tomorrow | morning (when I've built+tested the Jaguar package). If that doesn't | work, I'll take a look at Eric3 myself to see what's going on and either | provide a workaround or compensate for what's going on in py2app 0.1.8. | | -bob | I installed 0.1.7 and gave it a try on the stable version (3.4.2) of Eric3 that I'm shipping with my PyQt-distro. Everything built flawlessly, reflecting the support you've added for PyQt. The version of Eric3 that has been giving me problems across the board, including with py2app, is 3.5.1. It's buggy and crashes whenever I'm trying to save files. I have no idea why it does this, especially since I have all the current dependencies built and installed correctly. There was a bug in Qt 3.3.2 that caused problems with QScintilla, but that was fixed for 3.3.3. The problems with 3.5.1 were still there with the new version of py2app. So, I'm convinced the issue is the new version of Eric, and it's so buggy in general that I wouldn't waste any further time trying to tweak py2app to work with it. I'm waiting for the release of Qt 4 early next year, and then the follow-up releases of PyQt. At that point I'll revisit Eric3. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB0zL5JmdQs+6YVcoRAvydAJ4giO54ljDyhydnk55hskxw2McQowCcDXkW 6M7/RbUqXGzvq21Ucgns6Ng= =blN+ -----END PGP SIGNATURE----- From Jack.Jansen at cwi.nl Thu Dec 30 00:06:01 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Thu Dec 30 00:06:03 2004 Subject: [Pythonmac-SIG] How badly is _locale broken? In-Reply-To: References: <41D1DA1A.5050206@ocf.berkeley.edu> <20A4B660-597F-11D9-85EE-000D93AD379E@mac.com> Message-ID: <3517159E-59EE-11D9-81BB-000D934FF6B4@cwi.nl> On 29-dec-04, at 11:32, Ronald Oussoren wrote: > I know that. But not linking with CoreServices should fix _locale for > python scripts that don't use mac-specific features. If I understand correctly it's the loading of CoreServices that causes the _locale problem, right? If that's indeed the case then I think not linking with CoreServices would make this problem even worse: imagine a scenario where an unsuspecting user has working code in a toy app, but it fails when used in his GUI app (which happens to use CoreServices). Or code that works standalone but not in . -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From bob at redivi.com Thu Dec 30 00:24:14 2004 From: bob at redivi.com (Bob Ippolito) Date: Thu Dec 30 00:24:38 2004 Subject: [Pythonmac-SIG] How badly is _locale broken? In-Reply-To: <3517159E-59EE-11D9-81BB-000D934FF6B4@cwi.nl> References: <41D1DA1A.5050206@ocf.berkeley.edu> <20A4B660-597F-11D9-85EE-000D93AD379E@mac.com> <3517159E-59EE-11D9-81BB-000D934FF6B4@cwi.nl> Message-ID: On Dec 29, 2004, at 6:06 PM, Jack Jansen wrote: > > On 29-dec-04, at 11:32, Ronald Oussoren wrote: >> I know that. But not linking with CoreServices should fix _locale for >> python scripts that don't use mac-specific features. > > If I understand correctly it's the loading of CoreServices that causes > the _locale problem, right? If that's indeed the case then I think not > linking with CoreServices would make this problem even worse: imagine > a scenario where an unsuspecting user has working code in a toy app, > but it fails when used in his GUI app (which happens to use > CoreServices). Or code that works standalone but not in favorite IDE here>. IIRC it's the CoreFoundation loader that abuses some private functionality that forces the C locale. Simply faulting on any symbol in CoreFoundation will cause this loader to run. I think CoreServices uses CoreFoundation, which may have caused the confusion, but I'm pretty sure it's a CoreFoundation issue. Fortunately, the _locale module links to CoreFoundation (directly or indirectly) anyway to get the current locale (or something like that). The way it does things on current versions of OS X probably doesn't do anything useful, but at least it's broken even with the reduced core dependencies in Python 2.4. -bob From Jack.Jansen at cwi.nl Thu Dec 30 00:25:58 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Thu Dec 30 00:26:00 2004 Subject: [Pythonmac-SIG] The PantherPythonFix installer and C++ extensions In-Reply-To: <0F7FB55E-5986-11D9-9660-000A9567635C@redivi.com> References: <0F7FB55E-5986-11D9-9660-000A9567635C@redivi.com> Message-ID: On 29-dec-04, at 11:40, Bob Ippolito wrote: [Bob notes that my PantherPythonFix installer will break C++ compilation because distutils simply replaces the first component of LDSHARED with "c++"] >> Any suggestions as to what to do to get c++ compilation fixed? > > I can think of two ways: > > 1. Patch distutils to actually do > os.environ['MACOSX_DEPLOYMENT_TARGET'] = '10.3' because > CCompiler.spawn doesn't take an environment dict. > 2. Patch distutils to skip over environment variables (basically > change that "0" into something smarter). This is probably less > desirable because who knows where this happens, and who knows what > third party compiler subclasses used this original stupid code as a > template. Both of these mean that "the simple installer that just puts a new Makefile into lib/python2.3/config" has just gone out the window:-( I think I have a better alternative to both of these suggestions (basically what I just checked in for 2.5a0: allow the Makefile to force a setting for MACOSX_DEPLOYMENT_TARGET, unless it was set already), but that still leaves the problem that there's more files to patch. We could of course replace sysconfig.py and sysconfig.pyc in place, but I don't feel happy about that. (So: please argue that it isn't a problem). Or we could install a newer, patched distutils into /Library/Python/2.3. But that has the problem that it'll obliterate any other newer distutils the end user may have installed. Also not a good idea. Or maybe someone here has a silver bullet? -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From Jack.Jansen at cwi.nl Thu Dec 30 00:42:01 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Thu Dec 30 00:42:05 2004 Subject: [Pythonmac-SIG] BuildApplet in next distro of MacPython? In-Reply-To: <41D2E21B.3020800@wordtech-software.com> References: <41D2E21B.3020800@wordtech-software.com> Message-ID: <3CB0106D-59F3-11D9-81BB-000D934FF6B4@cwi.nl> On 29-dec-04, at 17:58, Kevin Walzer wrote: > I'm curious about whether BuildApplet and PythonIDE will be included in > the next iteration of MacPython, or whether these will be replaced by > py2app and PyOxide. Although I know these are old technologies, > especially BuildApplet, I'd like to request that they be retained, even > if they're not updated or enhanced. Just to give the party line on this: - BuildApplet and PythonIDE will be with us as-is for the MacPython 2.4 series of releases. They may move into some dark corner when replacements are available, but they will be available. - Like you (and has, if I understand him correctly) I think the minimal functionality BuildApplet provides has a place in the grand scheme of things. Bob is 100% right in all of his arguments (it doesn't work, it can't work, it won't work anywhere else, it'll only work in a very limited number of cases, etc etc etc), but BuildApplet has been with us for 10 years now and proven it's worth. And what it does was copied from "save as applet" in Apple's Script Editor (along with all the warts) and that is still going strong after 15 years. So if I have a say in things there'll be something as simple as BuildApplet for a long time to come:-) -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From bob at redivi.com Thu Dec 30 00:55:37 2004 From: bob at redivi.com (Bob Ippolito) Date: Thu Dec 30 00:55:53 2004 Subject: [Pythonmac-SIG] Re: The PantherPythonFix installer and C++ extensions In-Reply-To: References: <0F7FB55E-5986-11D9-9660-000A9567635C@redivi.com> Message-ID: <23401465-59F5-11D9-9660-000A9567635C@redivi.com> On Dec 29, 2004, at 6:25 PM, Jack Jansen wrote: > > On 29-dec-04, at 11:40, Bob Ippolito wrote: > [Bob notes that my PantherPythonFix installer will break C++ > compilation because distutils simply replaces the first component of > LDSHARED with "c++"] >>> Any suggestions as to what to do to get c++ compilation fixed? >> >> I can think of two ways: >> >> 1. Patch distutils to actually do >> os.environ['MACOSX_DEPLOYMENT_TARGET'] = '10.3' because >> CCompiler.spawn doesn't take an environment dict. >> 2. Patch distutils to skip over environment variables (basically >> change that "0" into something smarter). This is probably less >> desirable because who knows where this happens, and who knows what >> third party compiler subclasses used this original stupid code as a >> template. > > Both of these mean that "the simple installer that just puts a new > Makefile into lib/python2.3/config" has just gone out the window:-( Yeah.. I'd rather have broken C++ support than broken linker support though.. so this patch is better than no patch. > I think I have a better alternative to both of these suggestions > (basically what I just checked in for 2.5a0: allow the Makefile to > force a setting for MACOSX_DEPLOYMENT_TARGET, unless it was set > already), but that still leaves the problem that there's more files to > patch. > > We could of course replace sysconfig.py and sysconfig.pyc in place, > but I don't feel happy about that. (So: please argue that it isn't a > problem). I'm +1 for replacing sysconfig.py. It's known to be exactly the one included with 2.3.0. The user gets what they deserve if they made their own changes to sysconfig.py here. > Or we could install a newer, patched distutils into > /Library/Python/2.3. But that has the problem that it'll obliterate > any other newer distutils the end user may have installed. Also not a > good idea. -1.. you would also need to use a weird .pth hack to make sure it gets into sys.path before stdlib.. -bob From rkern at ucsd.edu Thu Dec 30 02:58:22 2004 From: rkern at ucsd.edu (Robert Kern) Date: Thu Dec 30 03:13:41 2004 Subject: [Pythonmac-SIG] Re: Re: [Python-checkins] python/dist/src/Mac/OSX fixapplepython23.py, 1.1, 1.2 In-Reply-To: <0F7FB55E-5986-11D9-9660-000A9567635C@redivi.com> References: <0F7FB55E-5986-11D9-9660-000A9567635C@redivi.com> Message-ID: Bob Ippolito wrote: > I have no idea, but I remember this issue was brought up at some point > during one of the many discussions of this issue. I think it was also > mentioned that SciPy's distutils extensions (or is it a fork?) does > something similarly stupid when frobbing in a Fortran compiler. Extension, and yes it does something similarly stupid. -- Robert Kern rkern@ucsd.edu "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From dp at ulaluma.com Thu Dec 30 05:48:56 2004 From: dp at ulaluma.com (Donovan Preston) Date: Thu Dec 30 05:49:12 2004 Subject: [Pythonmac-SIG] BuildApplet in next distro of MacPython? In-Reply-To: <41D2FA15.9010101@wordtech-software.com> References: <41D2E21B.3020800@wordtech-software.com> <287A2B77-59C3-11D9-9660-000A9567635C@redivi.com> <41D2FA15.9010101@wordtech-software.com> Message-ID: <1CDF9BCE-5A1E-11D9-8E43-000A95864FC4@ulaluma.com> On Dec 29, 2004, at 10:40 AM, Kevin Walzer wrote: > Perhaps I wasn't clear. I don't add *any* dependencies except those > that > ~ come with the application itself: i.e. I simply copy the directory > structure of the application (wxGlade, Pears, what have you) into the > app bundle. Any external libraries such as wxPython have to be > installed > separately by the end user. You can just as easily do this with app bundles built by py2app. dp From bob at redivi.com Thu Dec 30 06:55:14 2004 From: bob at redivi.com (Bob Ippolito) Date: Thu Dec 30 06:55:23 2004 Subject: [Pythonmac-SIG] BuildApplet in next distro of MacPython? In-Reply-To: <1CDF9BCE-5A1E-11D9-8E43-000A95864FC4@ulaluma.com> References: <41D2E21B.3020800@wordtech-software.com> <287A2B77-59C3-11D9-9660-000A9567635C@redivi.com> <41D2FA15.9010101@wordtech-software.com> <1CDF9BCE-5A1E-11D9-8E43-000A95864FC4@ulaluma.com> Message-ID: <5FEEE509-5A27-11D9-A11A-000A9567635C@redivi.com> On Dec 29, 2004, at 11:48 PM, Donovan Preston wrote: > > On Dec 29, 2004, at 10:40 AM, Kevin Walzer wrote: > >> Perhaps I wasn't clear. I don't add *any* dependencies except those >> that >> ~ come with the application itself: i.e. I simply copy the directory >> structure of the application (wxGlade, Pears, what have you) into the >> app bundle. Any external libraries such as wxPython have to be >> installed >> separately by the end user. > > You can just as easily do this with app bundles built by py2app. Yeah, if your main script doesn't have any detected dependencies.. or they're explicitly excluded. -bob From ronaldoussoren at mac.com Thu Dec 30 09:46:01 2004 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Thu Dec 30 09:45:58 2004 Subject: [Pythonmac-SIG] ANN: pyobjc-1.2 Message-ID: <3B7A08B9-5A3F-11D9-85EE-000D93AD379E@mac.com> PyObjC 1.2 is now available for download at http://pyobjc.sourceforge.net/ PyObjC is a bridge between Python and Objective-C. It allows full featured Cocoa applications to be written in pure Python. It is also easy to use other frameworks containing Objective-C class libraries from Python and to mix in Objective-C, C and C++ source. Python is a highly dynamic programming language with a shallow learning curve. It combines remarkable power with very clear syntax. The installer package includes a number of Xcode templates for easily creating new Cocoa-Python projects. PyObjC also supports full introspection of Objective-C classes and direct invocation of Objective-C APIs from the interactive interpreter. PyObjC requires Mac OS X 10.2 or later and Python 2.3 or later. PyObjC works both with the Apple provided Python installation in Mac OS X 10.3 (and later) and with MacPython 2.3. This release features several bugfixes, improved documentation as well as support for categories, easier customization and basic support for creating Interface Builder palettes. See the news file at http://pyobjc.sourceforge.net/NEWS-1.2.txt for more information. PyObjC is released with an open source license (MIT style). From ronaldoussoren at mac.com Thu Dec 30 10:02:11 2004 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Thu Dec 30 10:02:20 2004 Subject: [Pythonmac-SIG] The PantherPythonFix installer and C++ extensions In-Reply-To: References: <0F7FB55E-5986-11D9-9660-000A9567635C@redivi.com> Message-ID: <7E033C22-5A41-11D9-85EE-000D93AD379E@mac.com> On 30-dec-04, at 0:25, Jack Jansen wrote: > > On 29-dec-04, at 11:40, Bob Ippolito wrote: > [Bob notes that my PantherPythonFix installer will break C++ > compilation because distutils simply replaces the first component of > LDSHARED with "c++"] >>> Any suggestions as to what to do to get c++ compilation fixed? >> >> I can think of two ways: >> >> 1. Patch distutils to actually do >> os.environ['MACOSX_DEPLOYMENT_TARGET'] = '10.3' because >> CCompiler.spawn doesn't take an environment dict. >> 2. Patch distutils to skip over environment variables (basically >> change that "0" into something smarter). This is probably less >> desirable because who knows where this happens, and who knows what >> third party compiler subclasses used this original stupid code as a >> template. > > Both of these mean that "the simple installer that just puts a new > Makefile into lib/python2.3/config" has just gone out the window:-( In the quick-and-dirty-hacks category: you could write two simple shell-scripts that start the compiler with the right environment variables: run-cc: #!/bin/sh env MACOSX_DEPLOYMENT_TARGET=10.3 gcc "${@}" run-c++: #!/bin/sh env MACOSX_DEPLOYMENT_TARGET=10.3 gcc "${@}" The scripts can then be used in the CC and CXX variables in the patched makefile. Ronald From charles.hartman at conncoll.edu Thu Dec 30 16:11:46 2004 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Thu Dec 30 16:11:51 2004 Subject: [Pythonmac-SIG] wxDocsViewer Message-ID: <1F3599AA-5A75-11D9-9E60-000D933C27EA@conncoll.edu> Somehow I seem to have broken wxDocsViewer -- the viewer program comes up but no files appear onscreen. (They seem to be stored as .zip files inside the app bundle's resources folder, but I can't open them from within wxDocsViewer.) I tried re-downloading it, but no good; apparently I did something to my system that busted it. The most recent thing I did was to load PyQt (and free Qt and SIP) -- could that have anything to do with it? Sorry to be so clueless about something presumably simple. Charles Hartman Professor of English, Poet in Residence http://cherry.conncoll.edu/cohar http://villex.blogspot.com From Jack.Jansen at cwi.nl Thu Dec 30 17:44:42 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Thu Dec 30 17:44:42 2004 Subject: [Pythonmac-SIG] The PantherPythonFix installer and C++ extensions In-Reply-To: <7E033C22-5A41-11D9-85EE-000D93AD379E@mac.com> References: <0F7FB55E-5986-11D9-9660-000A9567635C@redivi.com> <7E033C22-5A41-11D9-85EE-000D93AD379E@mac.com> Message-ID: <1ADC484A-5A82-11D9-81BB-000D934FF6B4@cwi.nl> On 30-dec-04, at 10:02, Ronald Oussoren wrote: > > In the quick-and-dirty-hacks category: you could write two simple > shell-scripts that start the compiler with the right environment > variables: > > run-cc: > #!/bin/sh > > env MACOSX_DEPLOYMENT_TARGET=10.3 gcc "${@}" > > run-c++: > #!/bin/sh > env MACOSX_DEPLOYMENT_TARGET=10.3 gcc "${@}" Here's an even better idea (I think), please think about whether it would fly: In the Makefile we not only change LDSHARED and BLDSHARED to start with " env MACOSX_DEPLOYMENT_TARGET=10.3", but also CXX. That'll teach distutils to fiddle with our command lines:-) Only question is: would this have any adverse side efffects? -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From bob at redivi.com Thu Dec 30 18:49:11 2004 From: bob at redivi.com (Bob Ippolito) Date: Thu Dec 30 18:49:25 2004 Subject: [Pythonmac-SIG] The PantherPythonFix installer and C++ extensions In-Reply-To: <1ADC484A-5A82-11D9-81BB-000D934FF6B4@cwi.nl> References: <0F7FB55E-5986-11D9-9660-000A9567635C@redivi.com> <7E033C22-5A41-11D9-85EE-000D93AD379E@mac.com> <1ADC484A-5A82-11D9-81BB-000D934FF6B4@cwi.nl> Message-ID: <1CCAFDE0-5A8B-11D9-A11A-000A9567635C@redivi.com> On Dec 30, 2004, at 11:44 AM, Jack Jansen wrote: > > On 30-dec-04, at 10:02, Ronald Oussoren wrote: >> >> In the quick-and-dirty-hacks category: you could write two simple >> shell-scripts that start the compiler with the right environment >> variables: >> >> run-cc: >> #!/bin/sh >> >> env MACOSX_DEPLOYMENT_TARGET=10.3 gcc "${@}" >> >> run-c++: >> #!/bin/sh >> env MACOSX_DEPLOYMENT_TARGET=10.3 gcc "${@}" > > Here's an even better idea (I think), please think about whether it > would fly: > In the Makefile we not only change LDSHARED and BLDSHARED to start > with " env MACOSX_DEPLOYMENT_TARGET=10.3", but also CXX. That'll teach > distutils to fiddle with our command lines:-) > > Only question is: would this have any adverse side efffects? Same problem. If you replace the first word, you'll end up with either "g++ gcc..." or "g++ MACOSX_DEPLOYMENT_TARGET=10.3 gcc..." depending on whether "env" was used or not. -bob From ronaldoussoren at mac.com Thu Dec 30 20:52:31 2004 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Thu Dec 30 20:52:35 2004 Subject: [Pythonmac-SIG] The PantherPythonFix installer and C++ extensions In-Reply-To: <1CCAFDE0-5A8B-11D9-A11A-000A9567635C@redivi.com> References: <0F7FB55E-5986-11D9-9660-000A9567635C@redivi.com> <7E033C22-5A41-11D9-85EE-000D93AD379E@mac.com> <1ADC484A-5A82-11D9-81BB-000D934FF6B4@cwi.nl> <1CCAFDE0-5A8B-11D9-A11A-000A9567635C@redivi.com> Message-ID: <57836F3E-5A9C-11D9-85EE-000D93AD379E@mac.com> On 30-dec-04, at 18:49, Bob Ippolito wrote: > > On Dec 30, 2004, at 11:44 AM, Jack Jansen wrote: > >> >> On 30-dec-04, at 10:02, Ronald Oussoren wrote: >>> >>> In the quick-and-dirty-hacks category: you could write two simple >>> shell-scripts that start the compiler with the right environment >>> variables: >>> >>> run-cc: >>> #!/bin/sh >>> >>> env MACOSX_DEPLOYMENT_TARGET=10.3 gcc "${@}" >>> >>> run-c++: >>> #!/bin/sh >>> env MACOSX_DEPLOYMENT_TARGET=10.3 gcc "${@}" >> >> Here's an even better idea (I think), please think about whether it >> would fly: >> In the Makefile we not only change LDSHARED and BLDSHARED to start >> with " env MACOSX_DEPLOYMENT_TARGET=10.3", but also CXX. That'll >> teach distutils to fiddle with our command lines:-) >> >> Only question is: would this have any adverse side efffects? > > Same problem. If you replace the first word, you'll end up with > either "g++ gcc..." or "g++ MACOSX_DEPLOYMENT_TARGET=10.3 gcc..." > depending on whether "env" was used or not. Wouldn't you end up with 'env MAC.. gcc' when linking c++ extensions? distutils changes the first word which is 'env' in either case. Ronald From bob at redivi.com Thu Dec 30 21:01:35 2004 From: bob at redivi.com (Bob Ippolito) Date: Thu Dec 30 21:01:57 2004 Subject: [Pythonmac-SIG] The PantherPythonFix installer and C++ extensions In-Reply-To: <57836F3E-5A9C-11D9-85EE-000D93AD379E@mac.com> References: <0F7FB55E-5986-11D9-9660-000A9567635C@redivi.com> <7E033C22-5A41-11D9-85EE-000D93AD379E@mac.com> <1ADC484A-5A82-11D9-81BB-000D934FF6B4@cwi.nl> <1CCAFDE0-5A8B-11D9-A11A-000A9567635C@redivi.com> <57836F3E-5A9C-11D9-85EE-000D93AD379E@mac.com> Message-ID: <9BE7CF12-5A9D-11D9-A11A-000A9567635C@redivi.com> On Dec 30, 2004, at 2:52 PM, Ronald Oussoren wrote: > > On 30-dec-04, at 18:49, Bob Ippolito wrote: > >> >> On Dec 30, 2004, at 11:44 AM, Jack Jansen wrote: >> >>> >>> On 30-dec-04, at 10:02, Ronald Oussoren wrote: >>>> >>>> In the quick-and-dirty-hacks category: you could write two simple >>>> shell-scripts that start the compiler with the right environment >>>> variables: >>>> >>>> run-cc: >>>> #!/bin/sh >>>> >>>> env MACOSX_DEPLOYMENT_TARGET=10.3 gcc "${@}" >>>> >>>> run-c++: >>>> #!/bin/sh >>>> env MACOSX_DEPLOYMENT_TARGET=10.3 gcc "${@}" >>> >>> Here's an even better idea (I think), please think about whether it >>> would fly: >>> In the Makefile we not only change LDSHARED and BLDSHARED to start >>> with " env MACOSX_DEPLOYMENT_TARGET=10.3", but also CXX. That'll >>> teach distutils to fiddle with our command lines:-) >>> >>> Only question is: would this have any adverse side efffects? >> >> Same problem. If you replace the first word, you'll end up with >> either "g++ gcc..." or "g++ MACOSX_DEPLOYMENT_TARGET=10.3 gcc..." >> depending on whether "env" was used or not. > > Wouldn't you end up with 'env MAC.. gcc' when linking c++ extensions? > distutils changes the first word which is 'env' in either case. Oh.. right. But then given a bunch of .o files, it will probably not link in libstdc++. Who knows what SciPy will do with Fortran... -bob From Jack.Jansen at cwi.nl Thu Dec 30 22:56:07 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Thu Dec 30 22:56:08 2004 Subject: [Pythonmac-SIG] The PantherPythonFix installer and C++ extensions In-Reply-To: <9BE7CF12-5A9D-11D9-A11A-000A9567635C@redivi.com> References: <0F7FB55E-5986-11D9-9660-000A9567635C@redivi.com> <7E033C22-5A41-11D9-85EE-000D93AD379E@mac.com> <1ADC484A-5A82-11D9-81BB-000D934FF6B4@cwi.nl> <1CCAFDE0-5A8B-11D9-A11A-000A9567635C@redivi.com> <57836F3E-5A9C-11D9-85EE-000D93AD379E@mac.com> <9BE7CF12-5A9D-11D9-A11A-000A9567635C@redivi.com> Message-ID: <9BC7A87C-5AAD-11D9-81BB-000D934FF6B4@cwi.nl> On 30-dec-04, at 21:01, Bob Ippolito wrote: > > On Dec 30, 2004, at 2:52 PM, Ronald Oussoren wrote: > >> >> On 30-dec-04, at 18:49, Bob Ippolito wrote: >> >>> >>> On Dec 30, 2004, at 11:44 AM, Jack Jansen wrote: >>> >>>> >>>> On 30-dec-04, at 10:02, Ronald Oussoren wrote: >>>>> >>>>> In the quick-and-dirty-hacks category: you could write two simple >>>>> shell-scripts that start the compiler with the right environment >>>>> variables: >>>>> >>>>> run-cc: >>>>> #!/bin/sh >>>>> >>>>> env MACOSX_DEPLOYMENT_TARGET=10.3 gcc "${@}" >>>>> >>>>> run-c++: >>>>> #!/bin/sh >>>>> env MACOSX_DEPLOYMENT_TARGET=10.3 gcc "${@}" >>>> >>>> Here's an even better idea (I think), please think about whether it >>>> would fly: >>>> In the Makefile we not only change LDSHARED and BLDSHARED to start >>>> with " env MACOSX_DEPLOYMENT_TARGET=10.3", but also CXX. That'll >>>> teach distutils to fiddle with our command lines:-) >>>> >>>> Only question is: would this have any adverse side efffects? >>> >>> Same problem. If you replace the first word, you'll end up with >>> either "g++ gcc..." or "g++ MACOSX_DEPLOYMENT_TARGET=10.3 gcc..." >>> depending on whether "env" was used or not. >> >> Wouldn't you end up with 'env MAC.. gcc' when linking c++ extensions? >> distutils changes the first word which is 'env' in either case. > > Oh.. right. But then given a bunch of .o files, it will probably not > link in libstdc++. Who knows what SciPy will do with Fortran... Sigh, you're right. Which leaves two options: 1. Always use g++ to link in LDSHARED (in addition to the "env" tricks above). Would this have any adverse consequences? 2. Use Ronald's idea of wrapper scripts for both gcc and g++. We'd have to come up with decent names, though (so that if they're accidentally deleted the user may at least have an idea what they were supposed to do), maybe something like macpy23-gcc and macpy23-g++? Also, we'd need a place to put them. /Library/Python/2.3-PythonPantherFix? /System/yaddayaddayadda/python2.3/config/PythonPantherFix? Other ideas? -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From Chris.Barker at noaa.gov Thu Dec 30 23:25:16 2004 From: Chris.Barker at noaa.gov (Chris Barker) Date: Thu Dec 30 23:25:13 2004 Subject: [Pythonmac-SIG] Py2App 0.1.7 Message-ID: <41D4804C.5030209@noaa.gov> Hi all (but particularly Bob) I just installed Py2App with the installer, but when I tried to use it I got: Traceback (most recent call last): File "setup.py", line 21, in ? import py2app File "/purelib/py2app/py2app/__init__.py", line 33, in ? File "/purelib/py2app/py2app/install.py", line 15, in ? File "/purelib/py2app/py2app/command/__init__.py", line 1, in ? File "/purelib/py2app/py2app/build_app.py", line 20, in ? File "/purelib/py2app/modulegraph/find_modules.py", line 21, in ? File "/purelib/py2app/modulegraph/modulegraph.py", line 15, in ? ImportError: No module named ObjectGraph My first question was: "where the heck is /purelib ?" After some poking around, I found that indeed, there is no module objectgraph in: /Library/Python/2.3/altgraph/ which is version "0.6.1" but there is one in: /Library/Python/2.3/py2app/altgraph which is version "0.6.3" As I'd never heard of altgraph before, I'm guessing that the older version was installed by a previous version of Py2App, and Py2app now puts it in a different place, and the older one is being found first. To test this, I removed the older one, and then got: Traceback (most recent call last): File "./setup.py", line 10, in ? import py2app File "/purelib/py2app/py2app/__init__.py", line 33, in ? File "/purelib/py2app/py2app/install.py", line 15, in ? File "/purelib/py2app/py2app/command/__init__.py", line 1, in ? File "/purelib/py2app/py2app/build_app.py", line 25, in ? ImportError: No module named MachOGraph So I then deleted everything outside of /Users that had py2app in it. Then re-installed py2app. Running it again, I got the same error: ImportError: No module named MachOGraph Looking in the source, I see that MachOGraph.py is in src/macholib, but in my python installation macholib is in both /Library/Python/2.3/ and /Library/Python/2.3/py2app/ just like altgraph. lather, rinse repeat, and BINGO! it works. So, am I right that those older versions of altgraph and macholib were installed by an older Py2app? If so, some sort of waring should be put in about that. Also, while it's probably a good idea that you're now putting those packages inside the Py2app directory, it would probably be better to load them as: from Py2app.macholib import MachOGraph So that you know you're getting the version you installed for Py2app. By the way, if I needed altgraph for something else, I'd now be kind of screwed. Tome, this supports the argument I've been making for versioning. If we had a standard approach for versioning python packages, you could have the Py2app installer install the version of altgraph (and whatever else) it needs, and not screw up an exiting installation that other folk's code might be depending on. -Chris PS: Now that it works, it works fabulously! My simple wxPython app built with the very simplest of setup.py files, except for wxversion, which I'm going to go read Bob's changes in the Wiki, and figure out how to do that. Nice job. -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov From bob at redivi.com Fri Dec 31 01:15:23 2004 From: bob at redivi.com (Bob Ippolito) Date: Fri Dec 31 01:16:04 2004 Subject: [Pythonmac-SIG] Py2App 0.1.7 In-Reply-To: <41D4804C.5030209@noaa.gov> References: <41D4804C.5030209@noaa.gov> Message-ID: <10450F8E-5AC1-11D9-9DE6-000A9567635C@redivi.com> On Dec 30, 2004, at 5:25 PM, Chris Barker wrote: > I just installed Py2App with the installer, but when I tried to use it > I got: > > Traceback (most recent call last): > File "setup.py", line 21, in ? > import py2app > File "/purelib/py2app/py2app/__init__.py", line 33, in ? > File "/purelib/py2app/py2app/install.py", line 15, in ? > File "/purelib/py2app/py2app/command/__init__.py", line 1, in ? > File "/purelib/py2app/py2app/build_app.py", line 20, in ? > File "/purelib/py2app/modulegraph/find_modules.py", line 21, in ? > File "/purelib/py2app/modulegraph/modulegraph.py", line 15, in ? > ImportError: No module named ObjectGraph > > > My first question was: > > "where the heck is /purelib ?" That's an artifact of how the distutils install command compiles .py files under bdist_mpkg, eventually I'll fix that. > So, am I right that those older versions of altgraph and macholib were > installed by an older Py2app? Yes, probably 0.1.5. It has been in the py2app directory since 0.1.6. > If so, some sort of waring should be put in about that. I think that they should've been removed by the installer.. Oh well, there probably isn't much I can do about it now. Hopefully most people are already up to date or don't have it installed. > Also, while it's probably a good idea that you're now putting those > packages inside the Py2app directory, it would probably be better to > load them as: > > from Py2app.macholib import MachOGraph > > So that you know you're getting the version you installed for Py2app. py2app is not a package, it's just a directory pointed to by a pth. I "own" all these packages, so this is not a problem, except in the rare-ish case where an old version is installed. > By the way, if I needed altgraph for something else, I'd now be kind > of screwed. Tome, this supports the argument I've been making for > versioning. If we had a standard approach for versioning python > packages, you could have the Py2app installer install the version of > altgraph (and whatever else) it needs, and not screw up an exiting > installation that other folk's code might be depending on. The packages altgraph (my fork of "graphlib"), modulegraph, bdist_mpkg, macholib, and py2app are all exclusively maintained by me, and are only released as part of py2app. You don't need them for "something else", especially an older version. -bob From Chris.Barker at noaa.gov Fri Dec 31 01:31:29 2004 From: Chris.Barker at noaa.gov (Chris Barker) Date: Fri Dec 31 01:31:27 2004 Subject: [Pythonmac-SIG] Py2App 0.1.7 In-Reply-To: <10450F8E-5AC1-11D9-9DE6-000A9567635C@redivi.com> References: <41D4804C.5030209@noaa.gov> <10450F8E-5AC1-11D9-9DE6-000A9567635C@redivi.com> Message-ID: <41D49DE1.4040607@noaa.gov> Bob Ippolito wrote: >> My first question was: >> "where the heck is /purelib ?" > > That's an artifact of how the distutils install command compiles .py > files under bdist_mpkg, eventually I'll fix that. Thanks. It made the error confusing enough that it took me a while to figure out what was going on. >> So, am I right that those older versions of altgraph and macholib were >> installed by an older Py2app? > > Yes, probably 0.1.5. It has been in the py2app directory since 0.1.6. makes sense. I had 0.1.4 or something in my download directory. >> If so, some sort of waring should be put in about that. that is, "warning". > py2app is not a package, it's just a directory pointed to by a pth. but couldn't be? I why isn't it in site-packages anyway? Though I imagine you have a good reason, I'd like to know what it is. The whole pth thing seems kind of clunky to me. > The packages altgraph (my fork of "graphlib"), modulegraph, bdist_mpkg, > macholib, and py2app are all exclusively maintained by me, and are only > released as part of py2app. So putting them in the py2app dir, where you have them now, makes sense. > You don't need them for "something else", especially an older version. When this problem arose, I just did a quick google search for altgraph, and it looked like a generally useful package, so It wasn't clear that it is used exclusively for py2app. Oh well, I've got it all working now, very well, as a matter of fact. Now I just need to figure out how to give my app an icon. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov From bob at redivi.com Fri Dec 31 01:52:56 2004 From: bob at redivi.com (Bob Ippolito) Date: Fri Dec 31 01:53:04 2004 Subject: [Pythonmac-SIG] Py2App 0.1.7 In-Reply-To: <41D49DE1.4040607@noaa.gov> References: <41D4804C.5030209@noaa.gov> <10450F8E-5AC1-11D9-9DE6-000A9567635C@redivi.com> <41D49DE1.4040607@noaa.gov> Message-ID: <4F61AE4E-5AC6-11D9-9DE6-000A9567635C@redivi.com> On Dec 30, 2004, at 7:31 PM, Chris Barker wrote: > Bob Ippolito wrote: > >> py2app is not a package, it's just a directory pointed to by a pth. > > but couldn't be? I why isn't it in site-packages anyway? Though I > imagine you have a good reason, I'd like to know what it is. The whole > pth thing seems kind of clunky to me. I'm using a pth file so that I can put five separate packages in the same place that don't have a whole lot to do with each other but should be distributed together. Adding an extra level of nesting to the python namespace would just be a pain in the ass for me and no real help to anyone. >> The packages altgraph (my fork of "graphlib"), modulegraph, >> bdist_mpkg, macholib, and py2app are all exclusively maintained by >> me, and are only released as part of py2app. > > So putting them in the py2app dir, where you have them now, makes > sense. Exactly, that's what the pth file is for. >> You don't need them for "something else", especially an older version. > > When this problem arose, I just did a quick google search for > altgraph, and it looked like a generally useful package, so It wasn't > clear that it is used exclusively for py2app. Sounds like you found another package on google.. unless the references are in my svn repo or blog, it shouldn't be mentioned anywhere. It is pretty useful, but I'm not willing to support it. If you want stability or documentation, you're better off using graphlib. Even though I have made some enhancements, I reserve the right to do whatever I want to altgraph at this time. > Oh well, I've got it all working now, very well, as a matter of fact. > > Now I just need to figure out how to give my app an icon. 1) make an icns file 2.a) name it the same thing as your main script and add it to data_files or resources 2.b) specify it with the iconfile option 2.c) add it to data_files or resources with any name and specify it with a CFBundleIcon plist key -bob From bob at redivi.com Fri Dec 31 05:03:16 2004 From: bob at redivi.com (Bob Ippolito) Date: Fri Dec 31 05:03:32 2004 Subject: [Pythonmac-SIG] ANN: py2app 0.1.7 Message-ID: This announcement is available in HTML at: http://bob.pythonmac.org/archives/2004/12/30/ann-py2app-017/ `py2app`_ is the bundlebuilder replacement we've all been waiting for. It is implemented as a distutils command, similar to `py2exe`_, that builds Mac OS X applications from Python scripts, extensions, and related data files. It tries very hard to include all dependencies it can find so that your application can be distributed standalone, as Mac OS X applications should be. `py2app`_ 0.1.7 is included in the installer for `PyObjC`_ 1.2. If you have installed `PyObjC`_ 1.2, then you already have `py2app`_ 0.1.7 installed. Download and related links are here: http://undefined.org/python/#py2app `py2app`_ 0.1.7 is a bug fix release: * The ``bdist_mpkg`` script will now set up sys.path properly, for setup scripts that require local imports. * ``bdist_mpkg`` will now correctly accept ``ReadMe``, ``License``, ``Welcome``, and ``background`` files by parameter. * ``bdist_mpkg`` can now display a custom background again (0.1.6 broke this). * ``bdist_mpkg`` now accepts a ``build-base=`` argument, to put build files in an alternate location. * ``py2app`` will now accept main scripts with a ``.pyw`` extension. * ``py2app``'s not_stdlib_filter will now ignore a ``site-python`` directory as well as ``site-packages``. * ``py2app``'s plugin bundle template no longer displays GUI dialogs by default, but still links to ``AppKit``. * ``py2app`` now ensures that the directory of the main script is now added to ``sys.path`` when scanning modules. * The ``py2app`` build command has been refactored such that it would be easier to change its behavior by subclassing. * ``py2app`` alias bundles can now cope with editors that do atomic saves (write new file, swap names with existing file). * ``macholib`` now has minimal support for fat binaries. It still assumes big endian and will not make any changes to a little endian header. * Add a warning message when using the ``install`` command rather than installing from a package. * New ``simple/structured`` example that shows how you could package an application that is organized into several folders. * New ``PyObjC/pbplugin`` Xcode Plug-In example. Since I have been slacking and the last announcement was for 0.1.4, here are the changes for the soft-launched releases 0.1.5 and 0.1.6: `py2app`_ 0.1.6 was a major feature enhancements release: * ``py2applet`` and ``bdist_mpkg`` scripts have been moved to Python modules so that the functionality can be shared with the tools. * Generic graph-related functionality from ``py2app`` was moved to ``altgraph.ObjectGraph`` and ``altgraph.GraphUtil``. * ``bdist_mpkg`` now outputs more specific plist requirements (for future compatibility). * ``py2app`` can now create plugin bundles (MH_BUNDLE) as well as executables. * New recipe for supporting extensions built with `sip`_, such as `PyQt`_. Note that due to the way that `sip`_ works, when one sip-based extension is used, *all* sip-based extensions are included in your application. In practice, this means anything provided by `Riverbank`_, I don't think anyone else uses `sip`_ (publicly). * New recipe for `PyOpenGL`_. This is very naive and simply includes the whole thing, rather than trying to monkeypatch their brain-dead version acquisition routine in ``__init__``. * Bootstrap now sets ``ARGVZERO`` and ``EXECUTABLEPATH`` environment variables, corresponding to the ``argv[0]`` and the ``_NSGetExecutablePath(...)`` that the bundle saw. This is only really useful if you need to relaunch your own application. * More correct ``dyld`` search behavior. * Refactored ``macholib`` to use ``altgraph``, can now generate `GraphViz`_ graphs and more complex analysis of dependencies can be done. * ``macholib`` was refactored to be easier to maintain, and the structure handling has been optimized a bit. * The few tests that there are were refactored in `py.test`_ style. * New `PyQt`_ example. * New `PyOpenGL`_ example. `py2app`_ 0.1.5 was a major feature enhancements release: * Added a ``bdist_mpkg`` distutils extension, for creating Installer an metapackage from any distutils script. - Includes PackageInstaller tool - bdist_mpkg script - setup.py enhancements to support bdist_mpkg functionality * Added a ``PackageInstaller`` tool, a droplet that performs the same function as the ``bdist_mpkg`` script. * Create a custom ``bdist_mpkg`` subclass for `py2app`_'s setup script. * Source package now includes `PJE`_'s `setuptools`_ extension to distutils. * Added lots of metadata to the setup script. * ``py2app.modulegraph`` is now a top-level package, ``modulegraph``. * ``py2app.find_modules`` is now ``modulegraph.find_modules``. * Should now correctly handle paths (and application names) with unicode characters in them. * New ``--strip`` option for ``py2app`` build command, strips all Mach-O files in output application bundle. * New ``--bdist-base=`` option for ``py2app`` build command, allows an alternate build directory to be specified. * New `docutils`_ recipe. * Support for non-framework Python, such as the one provided by `DarwinPorts`_. .. _`py.test`: http://codespeak.net/py/current/doc/test.html .. _`GraphViz`: http://www.pixelglow.com/graphviz/ .. _`PyOpenGL`: http://pyopengl.sf.net/ .. _`Riverbank`: http://www.riverbankcomputing.co.uk/ .. _`sip`: http://www.riverbankcomputing.co.uk/sip/index.php .. _`PyQt`: http://www.riverbankcomputing.co.uk/pyqt/index.php .. _`DarwinPorts`: http://darwinports.opendarwin.org/ .. _`docutils`: http://docutils.sf.net/ .. _`setuptools`: http://cvs.eby-sarna.com/PEAK/setuptools/ .. _`PJE`: http://dirtSimple.org/ .. _`py2app`: http://undefined.org/python/#py2app .. _`py2exe`: http://starship.python.net/crew/theller/py2exe/ .. _`PyObjC`: http://pyobjc.sf.net/ From bac at OCF.Berkeley.EDU Fri Dec 31 09:00:59 2004 From: bac at OCF.Berkeley.EDU (Brett C.) Date: Fri Dec 31 09:01:15 2004 Subject: [Pythonmac-SIG] How badly is _locale broken? In-Reply-To: <3088E920-5987-11D9-9660-000A9567635C@redivi.com> References: <41D1DA1A.5050206@ocf.berkeley.edu> <20A4B660-597F-11D9-85EE-000D93AD379E@mac.com> <3088E920-5987-11D9-9660-000A9567635C@redivi.com> Message-ID: <41D5073B.5070100@ocf.berkeley.edu> Bob Ippolito wrote: > On Dec 29, 2004, at 5:32 AM, Ronald Oussoren wrote: >> >> I know that. But not linking with CoreServices should fix _locale for >> python scripts that don't use mac-specific features. > > > Well, my patch to remove all non-libSystem dependencies from the Python > core was accepted for Python 2.4, so we are already at this point. > However, the mac toolbox functions can lazily import CF-using modules. > I think the core probably uses some of these functions. Last I > remember, the locale module itself linked to CF (directly or indirectly) > so it could guess what the current locale should be :) > It is directly linked against CoreFoundation (there is function called mac_getstcript() in the extension module that is used to implement locale.getdefaultlocale . >> The correct fix would probably use CFLocale to implement the _locale >> module on OSX. > > > Yes, that would be a good fix. > Right. As I said I want to use CFNumberFormatter with CFLocale objects to fill in the dict returned by locale.localeconv as best as possible. > Alternatively, we could just punt on the issue and say "you need to use > 10.X in order to have a working locale module", where 10.X is the > version that Apple fixes CF. X is obviously greater than 3, but I don't > think it will be much greater. It's been broken for this long, and > Brett C. said he doesn't use the locale module, so it may be too much > effort for too little reward. > I have figured out the mapping of attributes from CFNumberFormatter to locale.localeconv, so doing that shouldn't be too painful. The only serious problem was going to be if there was more breakage (such as strcoll and such) that needed fixing. Dealing with localeconv so that test_locale stops failing (which, as a test, is really weak) should not be too bad. And just leaving 10.3 users out in the cold seems slightly mean, even when 10.4 comes out (due out in 2005, right?). Normally I would say we should just have the entire locale module just raise an exception if it is imported on a version that has this problem, but nl_langinfo actually works so that seems extreme. So I think I will go ahead and fix localeconv and see what 10.4 fixes when it comes out. -Brett From Jack.Jansen at cwi.nl Fri Dec 31 13:07:36 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Fri Dec 31 13:07:33 2004 Subject: [Pythonmac-SIG] Testers needed again: Fix installer 1.2 Message-ID: <8F295280-5B24-11D9-81BB-000D934FF6B4@cwi.nl> There's yet another new version of the Python 2.3 fix installer available: . This one should also make C++ extensions build correctly again with apple-installed Python 2.3 on 10.3, after installing a later framework build. Please let me know whether it works, especially with real C++ extensions (I only tried a toy extension). And, for the record, I used Ronalds solution of using driver scripts for gcc and g++ that set the MACOSX_DEPLOYMENT_TARGET environment variable before running the compiler. -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From piet at cs.uu.nl Fri Dec 31 16:27:07 2004 From: piet at cs.uu.nl (Piet van Oostrum) Date: Fri Dec 31 16:27:13 2004 Subject: [Pythonmac-SIG] Testers needed again: Fix installer 1.2 In-Reply-To: <8F295280-5B24-11D9-81BB-000D934FF6B4@cwi.nl> (Jack Jansen's message of "Fri, 31 Dec 2004 13:07:36 +0100") References: <8F295280-5B24-11D9-81BB-000D934FF6B4@cwi.nl> Message-ID: >>>>> Jack Jansen (JJ) wrote: JJ> There's yet another new version of the Python 2.3 fix installer available: JJ> . Apparently now (correctly) named PantherPythonFix.dmg -- Piet van Oostrum URL: http://www.cs.uu.nl/~piet [PGP] Private email: P.van.Oostrum@hccnet.nl From piet at cs.uu.nl Fri Dec 31 16:27:07 2004 From: piet at cs.uu.nl (Piet van Oostrum) Date: Fri Dec 31 16:49:37 2004 Subject: [Pythonmac-SIG] Testers needed again: Fix installer 1.2 In-Reply-To: <8F295280-5B24-11D9-81BB-000D934FF6B4@cwi.nl> (Jack Jansen's message of "Fri, 31 Dec 2004 13:07:36 +0100") References: <8F295280-5B24-11D9-81BB-000D934FF6B4@cwi.nl> Message-ID: <16853.29974.412578.280677@ordesa.local> >>>>> Jack Jansen (JJ) wrote: JJ> There's yet another new version of the Python 2.3 fix installer available: JJ> . Apparently now (correctly) named PantherPythonFix.dmg -- Piet van Oostrum URL: http://www.cs.uu.nl/~piet [PGP] Private email: P.van.Oostrum@hccnet.nl