From eliswilson at hushmail.com Wed May 1 01:11:31 2013 From: eliswilson at hushmail.com (eliswilson at hushmail.com) Date: Tue, 30 Apr 2013 19:11:31 -0400 Subject: [Pythonmac-SIG] Biggest Fake Conference in Computer Science Message-ID: <20130430231131.90804E6718@smtp.hushmail.com> Biggest Fake Conference in Computer Science We are researchers from different parts of the world and conducted a study on the world?s biggest bogus computer science conference WORLDCOMP http://sites.google.com/site/worlddump1 organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia richer. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. This fake paper is different from the two fake papers already published (see https://sites.google.com/site/worlddump4 for details) in WORLDCOMP. We MUST say that you should look at the above website if you have any thoughts of participating in WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP?s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP?s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and threatens the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia?s) pockets. Prof. Hamid Arabnia makes a lot of tricks. For example, he appeared in a newspaper to fool the public, claiming him a victim of cyber-attack (see Item 8 in Section 5 of above website). Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP?13 because of the fears of their image being tarnished due to WORLDCOMP?s fraudulent activities. That is why WORLDCOMP?13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP?s website is just an email address! We ask Prof. Hamid Arabnia to publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also ask him to look at the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 and respond if he has any professional values. Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet?s activities at http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links. From jamyad7 at gmail.com Wed May 1 14:37:18 2013 From: jamyad7 at gmail.com (Yuma Antoine Decaux) Date: Wed, 1 May 2013 22:37:18 +1000 Subject: [Pythonmac-SIG] NSSpeechSynthesizer from AppKit? In-Reply-To: <14414E39-929E-4A94-BE39-CB28D89B3791@gmail.com> References: <14414E39-929E-4A94-BE39-CB28D89B3791@gmail.com> Message-ID: <9148776F-91D9-427B-974E-C605C6B08C8A@gmail.com> Hi, I've been trying to find a way to have speech output on an assignment GUI i'm working on for uni in Tkinter (they are forcing me) and since none of the UI elements on it are accessible, i'm trying to use either pyobjc with AppKit and some event handlers in Tkinter to get speech synthesis. I've just successfully installed pyobjc and looked at the API notes. I couldn't find NSSynthesizer. Is this not available? Just asking before i go any further. Best regards, Yuma From kw at codebykevin.com Wed May 1 15:21:11 2013 From: kw at codebykevin.com (Kevin Walzer) Date: Wed, 01 May 2013 09:21:11 -0400 Subject: [Pythonmac-SIG] NSSpeechSynthesizer from AppKit? In-Reply-To: <9148776F-91D9-427B-974E-C605C6B08C8A@gmail.com> References: <14414E39-929E-4A94-BE39-CB28D89B3791@gmail.com> <9148776F-91D9-427B-974E-C605C6B08C8A@gmail.com> Message-ID: <518116C7.5030702@codebykevin.com> On 5/1/13 8:37 AM, Yuma Antoine Decaux wrote: > Hi, > > I've been trying to find a way to have speech output on an assignment GUI i'm working on for uni in Tkinter (they are forcing me) and since none of the UI elements on it are accessible, i'm trying to use either pyobjc with AppKit and some event handlers in Tkinter to get speech synthesis. > > I've just successfully installed pyobjc and looked at the API notes. I couldn't find NSSynthesizer. Is this not available? > Were you aware that this API can be called from the command line? The tool is /usr/bin/say and its documentation can be found via "man say". The overhead of pyobjc isn't necessary here. --Kevin -- Kevin Walzer Code by Kevin/Mobile Code by Kevin http://www.codebykevin.com http://www.wtmobilesoftware.com From ronaldoussoren at mac.com Wed May 1 15:43:17 2013 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Wed, 1 May 2013 15:43:17 +0200 Subject: [Pythonmac-SIG] NSSpeechSynthesizer from AppKit? In-Reply-To: <9148776F-91D9-427B-974E-C605C6B08C8A@gmail.com> References: <14414E39-929E-4A94-BE39-CB28D89B3791@gmail.com> <9148776F-91D9-427B-974E-C605C6B08C8A@gmail.com> Message-ID: On 1 May, 2013, at 14:37, Yuma Antoine Decaux wrote: > Hi, > > I've been trying to find a way to have speech output on an assignment GUI i'm working on for uni in Tkinter (they are forcing me) and since none of the UI elements on it are accessible, i'm trying to use either pyobjc with AppKit and some event handlers in Tkinter to get speech synthesis. > > I've just successfully installed pyobjc and looked at the API notes. I couldn't find NSSynthesizer. Is this not available? > > Just asking before i go any further. NSSpeechSyntheziser is supported. There is nothing useful to mention beyond what's in the Apple documentation for the class, hence it is not mentioned in the API notes. The following should work: from Cocoa import NSSpeechSynthesizer sp = NSSpeachSynthesizer.alloc().initWithVoice_(None) # use default voice sp.startSpeakingString_("hello world") You should probably ensure that the synthesizer object hangs around until it is done speaking. Ronald From jamyad7 at gmail.com Thu May 2 07:34:06 2013 From: jamyad7 at gmail.com (Yuma Antoine Decaux) Date: Thu, 2 May 2013 15:34:06 +1000 Subject: [Pythonmac-SIG] NSSpeechSynthesizer from AppKit? In-Reply-To: References: <14414E39-929E-4A94-BE39-CB28D89B3791@gmail.com> <9148776F-91D9-427B-974E-C605C6B08C8A@gmail.com> Message-ID: <24198CE1-C5E6-420E-B77B-3D138CBE206A@gmail.com> Thanks for that, it worked perfectly. Very exciting way to start understanding mac os related frameworks. Best regards, Yuma "Light has no value without darkness" Mob: +61 (0)410732547 Skype: Shainobi1 twitter: http://www.twitter.com/triple7 This message is protected by article 4-210 of a certain book of laws but you don't have to worry about privacy issues if you are the intended recipient. However, if any freakish circumstance such as ip sniffing, honey pot open relay servers or an honest mistake caused a transmission error, please advise the sender and throw your laptop into a bubble bath to avoid all illicit data retention. On 1/05/2013, at 11:43 PM, Ronald Oussoren wrote: > > On 1 May, 2013, at 14:37, Yuma Antoine Decaux wrote: > >> Hi, >> >> I've been trying to find a way to have speech output on an assignment GUI i'm working on for uni in Tkinter (they are forcing me) and since none of the UI elements on it are accessible, i'm trying to use either pyobjc with AppKit and some event handlers in Tkinter to get speech synthesis. >> >> I've just successfully installed pyobjc and looked at the API notes. I couldn't find NSSynthesizer. Is this not available? >> >> Just asking before i go any further. > > NSSpeechSyntheziser is supported. There is nothing useful to mention beyond what's in the Apple documentation for the class, hence it is not mentioned in the API notes. > > The following should work: > > from Cocoa import NSSpeechSynthesizer > > sp = NSSpeachSynthesizer.alloc().initWithVoice_(None) # use default voice > sp.startSpeakingString_("hello world") > > You should probably ensure that the synthesizer object hangs around until it is done speaking. > > Ronald > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: zato1.jpg Type: image/jpeg Size: 6427 bytes Desc: not available URL: From o.cornu at gmail.com Mon May 13 10:05:40 2013 From: o.cornu at gmail.com (Olivier Cornu) Date: Mon, 13 May 2013 10:05:40 +0200 Subject: [Pythonmac-SIG] Exclude certain files from py2app built apps Message-ID: Hi, We have a python app we distribute on several platforms, including a py2app-built standalone application for Mac. Some of our data_files are platform-specific (icons, man pages?) and should therefore only be included where relevant. We use the MANIFEST.in mechanism to select which data_files get excluded from the builds produced. However, py2app does not seem to abide by it. We've also tried defining data_files more restrictively so that only desired files figures in it. The whole data/ folder gets included nonetheless. So far, the only solution we've found to this problem is to remove undesired files from the .app folder using a post-processing shell script (i.e. running after py2app). A rather inelegant hack. What is the standard way to get fine-grained control over what data files py2app includes/excludes? We noticed that, contrary to other setup.py build commands, py2app does not create a egg-info directory on its own. Is it normal beahvior? Would py2app follow this egg-info regarding data files, if we built one beforehand? Thanks! ___ ??????o -------------- next part -------------- An HTML attachment was scrubbed... URL: From ronaldoussoren at mac.com Mon May 13 11:10:46 2013 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Mon, 13 May 2013 11:10:46 +0200 Subject: [Pythonmac-SIG] Exclude certain files from py2app built apps In-Reply-To: References: Message-ID: <41FDC2B9-F0D4-49BD-AD95-00792439068D@mac.com> On 13 May, 2013, at 10:05, Olivier Cornu wrote: > Hi, > > We have a python app we distribute on several platforms, including a py2app-built standalone application for Mac. > > Some of our data_files are platform-specific (icons, man pages?) and should therefore only be included where relevant. We use the MANIFEST.in mechanism to select which data_files get excluded from the builds produced. However, py2app does not seem to abide by it. py2app does not use the MANIFEST file, that file is meant to be used with the sdist command. > We've also tried defining data_files more restrictively so that only desired files figures in it. The whole data/ folder gets included nonetheless. > So far, the only solution we've found to this problem is to remove undesired files from the .app folder using a post-processing shell script (i.e. running after py2app). A rather inelegant hack. py2app currently doesn't have a way to filter which parts of a data folder gets included in the application bundle (that is, when you tell py2app to include 'data' you cannot tell it to exclude 'data/windows.dat'). > > What is the standard way to get fine-grained control over what data files py2app includes/excludes? > We noticed that, contrary to other setup.py build commands, py2app does not create a egg-info directory on its own. py2app doesn't use the egg-info data at all (and will also not include the egg-info directories of packages it copies into the application). That py2app is a distutils command is an historical accident, in the long run I'd like to refactor py2app into a standalone tool with a distutils command for backward compatibility. I have no idea when I'll get around to actually doing that. > Is it normal beahvior? Would py2app follow this egg-info regarding data files, if we built one beforehand? No. Ronald From o.cornu at gmail.com Mon May 13 18:55:22 2013 From: o.cornu at gmail.com (Olivier Cornu) Date: Mon, 13 May 2013 18:55:22 +0200 Subject: [Pythonmac-SIG] Exclude certain files from py2app built apps In-Reply-To: <41FDC2B9-F0D4-49BD-AD95-00792439068D@mac.com> References: <41FDC2B9-F0D4-49BD-AD95-00792439068D@mac.com> Message-ID: Thanks for your quick reply. :-= On Mon, May 13, 2013 at 11:10 AM, Ronald Oussoren wrote: > > py2app does not use the MANIFEST file, that file is meant to be used with > the sdist command. > Well, on my machine (Linux/Python-2.7), it seems bdist, bdist_rpm and bdist_egg (among others) do generate an egg-info directory following MANIFEST.in directives, just like sdist. Which appears to contradict your point; Or did i miss something? > > We've also tried defining data_files more restrictively so that only > desired files figures in it. The whole data/ folder gets included > nonetheless. > Sorry, i mixed things up: py2app does respect data_files. This problem happened using distutils/setuptools, to build other package on other platforms: defining data_files wasn't enough to get them included, they had to appear in a MANIFEST(.in) as well. As i'm looking for a unified way of specifying included files across building methods i discarded this one, but it wasn't because of py2app. > > So far, the only solution we've found to this problem is to remove > undesired files from the .app folder using a post-processing shell script > (i.e. running after py2app). A rather inelegant hack. > > py2app currently doesn't have a way to filter which parts of a data folder > gets included in the application bundle (that is, when you tell py2app to > include 'data' you cannot tell it to exclude 'data/windows.dat'). > Alright, no way to exclude files. I guess we'll just go "positive" and specify only needed ones in data_files then -- even though it's going to be more verbose a declaration. ;-) It does work with py2app, although as mentioned above, it does not seem to work with other tools. Is it just me day dreaming about a single mechanism to include files among different setup.py commands, or is there one that i just can't put my hand on? Am i the only one surprised that i need to rely on different mechanisms to tell setup.py what to include, just because the sub-command is different? ___ ??????o -------------- next part -------------- An HTML attachment was scrubbed... URL: From ronaldoussoren at mac.com Mon May 13 19:15:52 2013 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Mon, 13 May 2013 19:15:52 +0200 Subject: [Pythonmac-SIG] Exclude certain files from py2app built apps In-Reply-To: References: <41FDC2B9-F0D4-49BD-AD95-00792439068D@mac.com> Message-ID: On 13 May, 2013, at 18:55, Olivier Cornu wrote: > Thanks for your quick reply. :-= > > > On Mon, May 13, 2013 at 11:10 AM, Ronald Oussoren wrote: > > py2app does not use the MANIFEST file, that file is meant to be used with the sdist command. > > Well, on my machine (Linux/Python-2.7), it seems bdist, bdist_rpm and bdist_egg (among others) do generate an egg-info directory following MANIFEST.in directives, just like sdist. Which appears to contradict your point; Or did i miss something? But does bdist_egg actually include those files (I'm too lazy to check this right now)? > > > We've also tried defining data_files more restrictively so that only desired files figures in it. The whole data/ folder gets included nonetheless. > > Sorry, i mixed things up: py2app does respect data_files. This problem happened using distutils/setuptools, to build other package on other platforms: defining data_files wasn't enough to get them included, they had to appear in a MANIFEST(.in) as well. > As i'm looking for a unified way of specifying included files across building methods i discarded this one, but it wasn't because of py2app. > > > So far, the only solution we've found to this problem is to remove undesired files from the .app folder using a post-processing shell script (i.e. running after py2app). A rather inelegant hack. > > py2app currently doesn't have a way to filter which parts of a data folder gets included in the application bundle (that is, when you tell py2app to include 'data' you cannot tell it to exclude 'data/windows.dat'). > > Alright, no way to exclude files. I guess we'll just go "positive" and specify only needed ones in data_files then -- even though it's going to be more verbose a declaration. ;-) > It does work with py2app, although as mentioned above, it does not seem to work with other tools. Is it just me day dreaming about a single mechanism to include files among different setup.py commands, or is there one that i just can't put my hand on? > Am i the only one surprised that i need to rely on different mechanisms to tell setup.py what to include, just because the sub-command is different? The goals of the various command's are different. In particular, your MANIFEST.in will normally include files that aren't needed at runtime, such as the ReadMe file, other documentation and examples. Those should be included in the sdist, and possibly be installed, but aren't needed in an application bundle (or a windows executable created with py2app). Distutils, and by extension setuptools, does not really have a formal description of its behavior the behavior is more or less an accumulation of years of development by different people that do not necessarily have deep knowlegde of distutils. And that's just the core project, external tools like py2app are a whole different story (and I write that as the py2app maintainer). In the long run distutils will likely be replaced by better tools, the folks over on the distutils-sig are working on that. The first steps, that are making good progres, and to create a binary distribution format ("wheels") as the interface between a build-tool (like distutils) and an installation tool (like easy_install or pip), and a well defined installation format. Followup steps will define other interfaces (such as a way the installer can detect which build tool it should use to convert an sdist into a binary distribution for installation). With some luck Python 3.4 will include at least support for the wheel format and a basic installer. Ronald > ___ > ??????o > From paulcoones at comcast.net Mon May 13 19:53:25 2013 From: paulcoones at comcast.net (Paul Coones) Date: Mon, 13 May 2013 10:53:25 -0700 Subject: [Pythonmac-SIG] dynamic module in Blender does not define init function Message-ID: I am getting a message when I try to import a dynamic library included in a module into Blender Text window: ImportError: dynamic module does not define init function (PyInit__LeapPython) What does this message mean and what do I need to do to eliminate it? The library is _LeapPython.so I believe it contains c++ methods (wrapped), that get called in python. Paul Coones paulcoones at comcast.net From o.cornu at gmail.com Mon May 13 23:29:21 2013 From: o.cornu at gmail.com (Olivier Cornu) Date: Mon, 13 May 2013 23:29:21 +0200 Subject: [Pythonmac-SIG] Exclude certain files from py2app built apps In-Reply-To: References: <41FDC2B9-F0D4-49BD-AD95-00792439068D@mac.com> Message-ID: On Mon, May 13, 2013 at 7:15 PM, Ronald Oussoren wrote: > > On 13 May, 2013, at 18:55, Olivier Cornu wrote: > > > Well, on my machine (Linux/Python-2.7), it seems bdist, bdist_rpm and > bdist_egg (among others) do generate an egg-info directory following > MANIFEST.in directives, just like sdist. Which appears to contradict your > point; Or did i miss something? > > But does bdist_egg actually include those files (I'm too lazy to check > this right now)? > It does include the egg-info directory (renamed in capitals EGG-INFO). It doesn't include MANIFEST(.in). > The goals of the various command's are different. In particular, your > MANIFEST.in will normally include files that aren't needed at runtime, such > as the ReadMe file, other documentation and examples. Those should be > included in the sdist, and possibly be installed, but aren't needed in an > application bundle (or a windows executable created with py2app). > > Distutils, and by extension setuptools, does not really have a formal > description of its behavior the behavior is more or less an accumulation of > years of development by different people that do not necessarily have deep > knowlegde of distutils. And that's just the core project, external tools > like py2app are a whole different story (and I write that as the py2app > maintainer). > I appreciate that. A rather common situation in the open-source world i believe: the project i'm working on, although smaller and less central to the community, fits the descriptions just as well? Yet regarding data_files, if i understand correctly there are two, perhaps three interpretations of what it means (where to install data files? Which data file gets included? Both?). We're talking about the same argument of the same function of the same module, here. I mean, i understand different heuristics are chosen by different people in different situations. I understand misunderstanding or going around frozen interfaces to get to one's ends. Yet i don't think i'm putting the API convergence bar very high either by expecting one function argument to mean just one thing. If it has to mean something else, why not just call it differently? As it is, with no documentation whatsoever, it is as effective a trap as one could willingly design? ;) > In the long run distutils will likely be replaced by better tools, the > folks over on the distutils-sig are working on that. The first steps, that > are making good progres, and to create a binary distribution format > ("wheels") as the interface between a build-tool (like distutils) and an > installation tool (like easy_install or pip), and a well defined > installation format. Followup steps will define other interfaces (such as > a way the installer can detect which build tool it should use to convert an > sdist into a binary distribution for installation). With some luck Python > 3.4 will include at least support for the wheel format and a basic > installer. > Well, thanks for the update: that looks exciting! Where can i learn more about it? ___ ??????o -------------- next part -------------- An HTML attachment was scrubbed... URL: From ronaldoussoren at mac.com Tue May 14 08:37:16 2013 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Tue, 14 May 2013 08:37:16 +0200 Subject: [Pythonmac-SIG] dynamic module in Blender does not define init function In-Reply-To: References: Message-ID: <252890B1-D61F-4862-BA02-9EF1A99064B5@mac.com> On 13 May, 2013, at 19:53, Paul Coones wrote: > I am getting a message when I try to import a dynamic library included in a module into Blender Text window: > > ImportError: dynamic module does not define init function (PyInit__LeapPython) > > What does this message mean and what do I need to do to eliminate it? > > The library is _LeapPython.so > I believe it contains c++ methods (wrapped), that get called in python. This likely means that _LeapPython.so was build for Python 2 while blender uses Python 3. Ronald > > > Paul Coones > paulcoones at comcast.net > > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG From ronaldoussoren at mac.com Wed May 15 21:53:38 2013 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Wed, 15 May 2013 21:53:38 +0200 Subject: [Pythonmac-SIG] ASL library Message-ID: Hi, With OSX 10.8 the stdout and stderr streams of applications no longer end up in Console.app, which is fairly annoying when debugging problems in applications created with py2app. I've been researching how I can work around this, and seem to be successfull (the fix is in the repository, and I hope to push out a release next weekend after rebuilding the stub executables in a VM that has a compiler that can generate PPC binaries). Anyways, while researching the solution I started playing with ASL (the Apple replacement for the venerable syslog API), and now know way too much about that libary. I've created a python binding for ASL while the information is still fresh, it for now is only available on bitbucket: . I need to do some testing on older OSX releases before I push a proper release to PyPI, even if I don't expect problems. The library not only makes it possible to write arbitrary messages to the ASL database, but can also be used to query the database. Hopefully I won't have to write C code the next time I want to play with ASL :-) Ronald From bergs at janelia.hhmi.org Wed May 15 22:32:05 2013 From: bergs at janelia.hhmi.org (Berg, Stuart) Date: Wed, 15 May 2013 20:32:05 +0000 Subject: [Pythonmac-SIG] py2app + pyqt: Differences between command-line and double-click Message-ID: Hi, I'm using py2app to packages my (cross-platform) PyQt app into a Mac OS X application bundle. (py2app is great, btw!) I was wondering if anyone could point me to some documentation that explains in detail how a python app bundle's launch process differs from launching the python app directly from the command-line. My app bundle seems to function exactly the same in most respects, but my main window doesn't activate unless I manually activate the application via command-tab. I give a few more details in this question on stack overflow: http://stackoverflow.com/questions/16574315/qt-mainwindow-does-not-appear-until-application-is-activated-manually Any ideas, suggestions, or links would be appreciated. Thanks, Stuart From michael.mccracken at gmail.com Wed May 15 22:50:13 2013 From: michael.mccracken at gmail.com (Michael McCracken) Date: Wed, 15 May 2013 13:50:13 -0700 Subject: [Pythonmac-SIG] py2app + pyqt: Differences between command-line and double-click In-Reply-To: References: Message-ID: Hi, I answered on stack overflow too - but the short version is call show() *then also call* raise_() on your main window. The answer to an earlier version of this question has a couple of links for more background: http://stackoverflow.com/questions/3662559/why-does-my-pyqt-application-open-in-the-background-on-mac-os-x On Wed, May 15, 2013 at 1:32 PM, Berg, Stuart wrote: > Hi, > > I'm using py2app to packages my (cross-platform) PyQt app into a Mac OS X > application bundle. (py2app is great, btw!) > > I was wondering if anyone could point me to some documentation that > explains in detail how a python app bundle's launch process differs from > launching the python app directly from the command-line. My app bundle > seems to function exactly the same in most respects, but my main window > doesn't activate unless I manually activate the application via command-tab. > > I give a few more details in this question on stack overflow: > > http://stackoverflow.com/questions/16574315/qt-mainwindow-does-not-appear-until-application-is-activated-manually > > Any ideas, suggestions, or links would be appreciated. > > Thanks, > Stuart > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bergs at janelia.hhmi.org Wed May 15 23:31:44 2013 From: bergs at janelia.hhmi.org (Berg, Stuart) Date: Wed, 15 May 2013 21:31:44 +0000 Subject: [Pythonmac-SIG] py2app + pyqt: Differences between command-line and double-click In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From michael.mccracken at gmail.com Wed May 15 23:50:44 2013 From: michael.mccracken at gmail.com (Michael McCracken) Date: Wed, 15 May 2013 14:50:44 -0700 Subject: [Pythonmac-SIG] py2app + pyqt: Differences between command-line and double-click In-Reply-To: References: Message-ID: There aren't any other window-focus related gotchas that I know of in the bootstrap code, and I've looked at most of it - can you share more about your program, and perhaps show what your setup.py looks like? On Wed, May 15, 2013 at 2:31 PM, Berg, Stuart wrote: > Hi Michael, > > Thanks for your response. I am already calling show() and then raise() > (though my SO question didn't make that clear -- sorry about that). I > think I'm having a different issue than the one in the link you provided, > because my app behaves correctly when launched from the command line. It > only misbehaves when launched from the app-bundle (i.e. when launched with > double-click). > > For that reason, I suspect that perhaps there may be a subtle difference > in the way the app bundle launches the main thread. (Grasping in the dark > here...) Any py2app experts out there care to comment? > > -Stuart > > On May 15, 2013, at 4:50 PM, Michael McCracken wrote: > > Hi, I answered on stack overflow too - but the short version is call > show() *then also call* raise_() on your main window. > > The answer to an earlier version of this question has a couple of links > for more background: > http://stackoverflow.com/questions/3662559/why-does-my-pyqt-application-open-in-the-background-on-mac-os-x > > > On Wed, May 15, 2013 at 1:32 PM, Berg, Stuart wrote: > >> Hi, >> >> I'm using py2app to packages my (cross-platform) PyQt app into a Mac OS X >> application bundle. (py2app is great, btw!) >> >> I was wondering if anyone could point me to some documentation that >> explains in detail how a python app bundle's launch process differs from >> launching the python app directly from the command-line. My app bundle >> seems to function exactly the same in most respects, but my main window >> doesn't activate unless I manually activate the application via command-tab. >> >> I give a few more details in this question on stack overflow: >> >> http://stackoverflow.com/questions/16574315/qt-mainwindow-does-not-appear-until-application-is-activated-manually >> >> Any ideas, suggestions, or links would be appreciated. >> >> Thanks, >> Stuart >> >> _______________________________________________ >> Pythonmac-SIG maillist - Pythonmac-SIG at python.org >> http://mail.python.org/mailman/listinfo/pythonmac-sig >> unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ronaldoussoren at mac.com Thu May 16 07:43:41 2013 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Thu, 16 May 2013 07:43:41 +0200 Subject: [Pythonmac-SIG] py2app + pyqt: Differences between command-line and double-click In-Reply-To: References: Message-ID: <2C0731DD-AB01-4C8E-88E4-3703C96CF072@mac.com> On 15 May, 2013, at 22:32, "Berg, Stuart" wrote: > Hi, > > I'm using py2app to packages my (cross-platform) PyQt app into a Mac OS X application bundle. (py2app is great, btw!) > > I was wondering if anyone could point me to some documentation that explains in detail how a python app bundle's launch process differs from launching the python app directly from the command-line. My app bundle seems to function exactly the same in most respects, but my main window doesn't activate unless I manually activate the application via command-tab. > > I give a few more details in this question on stack overflow: > http://stackoverflow.com/questions/16574315/qt-mainwindow-does-not-appear-until-application-is-activated-manually > > Any ideas, suggestions, or links would be appreciated. That's odd. I would expect the opposite behavior because your application should get the focus when launched by the finder and the terminal still has focus when you start a script in the Terminal app. Does the Qt application example in py2app's repository have the same behavior (last time I checked it worked fine on my machine)? What application does have the focus when you double click on the application? And btw, what do you mean by "launch from the terminal" in your SO question? Are you starting the .app from the Terminal using 'MyApp.app/Contents/MyAp', or by running 'open MyApp.app' or even by just running 'python myapp.py'? Ronald > > Thanks, > Stuart > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG From nad at acm.org Sun May 19 04:49:57 2013 From: nad at acm.org (Ned Deily) Date: Sat, 18 May 2013 19:49:57 -0700 Subject: [Pythonmac-SIG] OS X IDLE and Tkinter users: new releases of Tcl/Tk & Python Message-ID: As I hope you've read already, new releases of Python are now available: 3.3.2, 3.2.5, and 2.7.5. There is also a recent release of Tcl/Tk 8.5: 8.5.14. If you use Tkinter apps, like IDLE, from one of the python.org 64-bit/32-bit OS X installers for 3.3.x, 3.2.x, or 2.7.x for OS X 10.6, 10.7, or 10.8, it would be great if you could install and try out these latest combinations. Tkinter apps have proven to turn up edge cases in the newer Cocoa implementation of Tk 8.5 on OS X; a number of problems have been fixed in recent releases. Since these kinds of problems are difficult to test for automatically, it is important to get real user experience and feedback. Please report any suspected new problems to the Python bug tracker. Thanks for your help! http://www.python.org/download/ http://www.python.org/download/mac/tcltk/ http://www.activestate.com/activetcl/downloads http://bugs.python.org -- Ned Deily, nad at acm.org From fsteele at mindspring.com Tue May 21 16:04:44 2013 From: fsteele at mindspring.com (fsteele at mindspring.com) Date: Tue, 21 May 2013 10:04:44 -0400 (GMT-04:00) Subject: [Pythonmac-SIG] Py2app-built app giving error 255 on loading AppKit? Message-ID: <33327952.1369145084545.JavaMail.root@wamui-junio.atl.sa.earthlink.net> I've built an app with Py2app. It runs as expected on my development machine, but on machines (10.7.5 and 10.8.2, at least) without a development environment, I get: testmini1:~ administrator$ /Users/administrator/Desktop/EasySetup.app/Contents/MacOS/EasySetup ; exit; Traceback (most recent call last): File "/Users/administrator/Desktop/EasySetup.app/Contents/Resources/__boot__.py", line 43, in _run() File "/Users/administrator/Desktop/EasySetup.app/Contents/Resources/__boot__.py", line 38, in _run exec(compile(source, path, 'exec'), globals(), globals()) File "/Users/administrator/Desktop/EasySetup.app/Contents/Resources/EasySetup.py", line 13, in import AppKit File "AppKit/__init__.pyc", line 43, in File "AppKit/_AppKit.pyc", line 14, in File "AppKit/_AppKit.pyc", line 10, in __load ImportError: dlopen(/Users/administrator/Desktop/EasySetup.app/Contents/Resources/lib/python2.7/lib-dynload/AppKit/_AppKit.so, 2): Symbol not found: _OBJC_CLASS_$_NSObject Referenced from: /Users/administrator/Desktop/EasySetup.app/Contents/Resources/lib/python2.7/lib-dynload/AppKit/_AppKit.so Expected in: /usr/lib/libobjc.A.dylib in /Users/administrator/Desktop/EasySetup.app/Contents/Resources/lib/python2.7/lib-dynload/AppKit/_AppKit.so 2013-05-21 09:19:44.502 EasySetup[393:707] EasySetup Error The _AppKit.so file referenced is in the location referenced. I've deleted /build and /dist and rebuilt the app. My setup.py: from setuptools import setup APP = ['EasySetup.py'] DATA_FILES = ['EasySetup/MainMenu.xib', 'loggers.py', 'MacTools.py', 'create_corplocaladministrator-1.0.pkg', 'macepoprodagentinstall.sh', 'corp-logo.png'] OPTIONS = {'argv_emulation': False, 'iconfile':'EasySetup.icns'} setup( app=APP, data_files=DATA_FILES, install_requires=["pyobjc"], options={'py2app': OPTIONS}, setup_requires=['py2app'], ) I'm using virtualenv, where "yolk -list" gives: python - 2.7.3 - active development (/usr/local/Cellar/python/2.7.3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload) altgraph - 0.10.2 - active beautifulsoup4 - 4.1.3 - active macholib - 1.5.1 - active modulegraph - 0.10.4 - active pexpect - 2.4 - active pip - 1.3.1 - active py2app - 0.7.3 - non-active pyobjc-core - 2.5.1 - active pyobjc-framework-Accounts - 2.5.1 - active pyobjc-framework-AddressBook - 2.5.1 - active pyobjc-framework-AppleScriptKit - 2.5.1 - active pyobjc-framework-AppleScriptObjC - 2.5.1 - active pyobjc-framework-Automator - 2.5.1 - active pyobjc-framework-CFNetwork - 2.5.1 - active pyobjc-framework-CalendarStore - 2.5.1 - active pyobjc-framework-Cocoa - 2.5.1 - active pyobjc-framework-Collaboration - 2.5.1 - active pyobjc-framework-CoreData - 2.5.1 - active pyobjc-framework-CoreLocation - 2.5.1 - active pyobjc-framework-CoreText - 2.5.1 - active pyobjc-framework-DictionaryServices - 2.5.1 - active pyobjc-framework-EventKit - 2.5.1 - active pyobjc-framework-ExceptionHandling - 2.5.1 - active pyobjc-framework-FSEvents - 2.5.1 - active pyobjc-framework-InputMethodKit - 2.5.1 - active pyobjc-framework-InstallerPlugins - 2.5.1 - active pyobjc-framework-InstantMessage - 2.5.1 - active pyobjc-framework-LatentSemanticMapping - 2.5.1 - active pyobjc-framework-LaunchServices - 2.5.1 - active pyobjc-framework-Message - 2.5.1 - active pyobjc-framework-PreferencePanes - 2.5.1 - active pyobjc-framework-PubSub - 2.5.1 - active pyobjc-framework-QTKit - 2.5.1 - active pyobjc-framework-Quartz - 2.5.1 - active pyobjc-framework-ScreenSaver - 2.5.1 - active pyobjc-framework-ScriptingBridge - 2.5.1 - active pyobjc-framework-SearchKit - 2.5.1 - active pyobjc-framework-ServerNotification - 2.5.1 - active pyobjc-framework-ServiceManagement - 2.5.1 - active pyobjc-framework-Social - 2.5.1 - active pyobjc-framework-SyncServices - 2.5.1 - active pyobjc-framework-SystemConfiguration - 2.5.1 - active pyobjc-framework-WebKit - 2.5.1 - active pyobjc - 2.5.1 - active requests - 1.2.0 - active setuptools - 0.6c11 - active wsgiref - 0.1.2 - active development (/usr/local/Cellar/python/2.7.3/Frameworks/Python.framework/Versions/2.7/lib/python2.7) yolk - 0.4.3 - active There are so many threads in play, I'm not sure which to yank on first. Does anybody see anything that rings any alarm bells? Any suggestions on further investigation? Thanks! Frank From ronaldoussoren at mac.com Wed May 22 10:15:41 2013 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Wed, 22 May 2013 10:15:41 +0200 Subject: [Pythonmac-SIG] Py2app-built app giving error 255 on loading AppKit? In-Reply-To: <33327952.1369145084545.JavaMail.root@wamui-junio.atl.sa.earthlink.net> References: <33327952.1369145084545.JavaMail.root@wamui-junio.atl.sa.earthlink.net> Message-ID: <3B1A9D50-3A86-45C1-B842-7DB8E1B24BF0@mac.com> On 21 May, 2013, at 16:04, fsteele at mindspring.com wrote: > I've built an app with Py2app. It runs as expected on my development machine, but on machines (10.7.5 and 10.8.2, at least) without a development environment, I get: > > testmini1:~ administrator$ /Users/administrator/Desktop/EasySetup.app/Contents/MacOS/EasySetup ; exit; > Traceback (most recent call last): > File "/Users/administrator/Desktop/EasySetup.app/Contents/Resources/__boot__.py", line 43, in > _run() > File "/Users/administrator/Desktop/EasySetup.app/Contents/Resources/__boot__.py", line 38, in _run > exec(compile(source, path, 'exec'), globals(), globals()) > File "/Users/administrator/Desktop/EasySetup.app/Contents/Resources/EasySetup.py", line 13, in > import AppKit > File "AppKit/__init__.pyc", line 43, in > File "AppKit/_AppKit.pyc", line 14, in > File "AppKit/_AppKit.pyc", line 10, in __load > ImportError: dlopen(/Users/administrator/Desktop/EasySetup.app/Contents/Resources/lib/python2.7/lib-dynload/AppKit/_AppKit.so, 2): Symbol not found: _OBJC_CLASS_$_NSObject > Referenced from: /Users/administrator/Desktop/EasySetup.app/Contents/Resources/lib/python2.7/lib-dynload/AppKit/_AppKit.so > Expected in: /usr/lib/libobjc.A.dylib > in /Users/administrator/Desktop/EasySetup.app/Contents/Resources/lib/python2.7/lib-dynload/AppKit/_AppKit.so > 2013-05-21 09:19:44.502 EasySetup[393:707] EasySetup Error > > The _AppKit.so file referenced is in the location referenced. I've deleted /build and /dist and rebuilt the app. It is odd that the problem occurs on all machines without development tools. What's the deployment target of the application? You can check the actual deployment target in binaries (such as _AppKit.so) using "otool -vl FILENAME", look for 'LC_VERSION_MIN_MACOSX'. Having a too high deployment target could explain why the app doesn't work on 10.7, but not why it doesn't work on 10.8 machines without devtools. Ronald > > My setup.py: > > from setuptools import setup > > APP = ['EasySetup.py'] > DATA_FILES = ['EasySetup/MainMenu.xib', 'loggers.py', 'MacTools.py', 'create_corplocaladministrator-1.0.pkg', 'macepoprodagentinstall.sh', 'corp-logo.png'] > OPTIONS = {'argv_emulation': False, 'iconfile':'EasySetup.icns'} > > setup( > app=APP, > data_files=DATA_FILES, > install_requires=["pyobjc"], > options={'py2app': OPTIONS}, > setup_requires=['py2app'], > ) > > > I'm using virtualenv, where "yolk -list" gives: > > python - 2.7.3 - active development (/usr/local/Cellar/python/2.7.3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload) > altgraph - 0.10.2 - active > beautifulsoup4 - 4.1.3 - active > macholib - 1.5.1 - active > modulegraph - 0.10.4 - active > pexpect - 2.4 - active > pip - 1.3.1 - active > py2app - 0.7.3 - non-active > pyobjc-core - 2.5.1 - active > pyobjc-framework-Accounts - 2.5.1 - active > pyobjc-framework-AddressBook - 2.5.1 - active > pyobjc-framework-AppleScriptKit - 2.5.1 - active > pyobjc-framework-AppleScriptObjC - 2.5.1 - active > pyobjc-framework-Automator - 2.5.1 - active > pyobjc-framework-CFNetwork - 2.5.1 - active > pyobjc-framework-CalendarStore - 2.5.1 - active > pyobjc-framework-Cocoa - 2.5.1 - active > pyobjc-framework-Collaboration - 2.5.1 - active > pyobjc-framework-CoreData - 2.5.1 - active > pyobjc-framework-CoreLocation - 2.5.1 - active > pyobjc-framework-CoreText - 2.5.1 - active > pyobjc-framework-DictionaryServices - 2.5.1 - active > pyobjc-framework-EventKit - 2.5.1 - active > pyobjc-framework-ExceptionHandling - 2.5.1 - active > pyobjc-framework-FSEvents - 2.5.1 - active > pyobjc-framework-InputMethodKit - 2.5.1 - active > pyobjc-framework-InstallerPlugins - 2.5.1 - active > pyobjc-framework-InstantMessage - 2.5.1 - active > pyobjc-framework-LatentSemanticMapping - 2.5.1 - active > pyobjc-framework-LaunchServices - 2.5.1 - active > pyobjc-framework-Message - 2.5.1 - active > pyobjc-framework-PreferencePanes - 2.5.1 - active > pyobjc-framework-PubSub - 2.5.1 - active > pyobjc-framework-QTKit - 2.5.1 - active > pyobjc-framework-Quartz - 2.5.1 - active > pyobjc-framework-ScreenSaver - 2.5.1 - active > pyobjc-framework-ScriptingBridge - 2.5.1 - active > pyobjc-framework-SearchKit - 2.5.1 - active > pyobjc-framework-ServerNotification - 2.5.1 - active > pyobjc-framework-ServiceManagement - 2.5.1 - active > pyobjc-framework-Social - 2.5.1 - active > pyobjc-framework-SyncServices - 2.5.1 - active > pyobjc-framework-SystemConfiguration - 2.5.1 - active > pyobjc-framework-WebKit - 2.5.1 - active > pyobjc - 2.5.1 - active > requests - 1.2.0 - active > setuptools - 0.6c11 - active > wsgiref - 0.1.2 - active development (/usr/local/Cellar/python/2.7.3/Frameworks/Python.framework/Versions/2.7/lib/python2.7) > yolk - 0.4.3 - active > > There are so many threads in play, I'm not sure which to yank on first. Does anybody see anything that rings any alarm bells? Any suggestions on further investigation? > > Thanks! > Frank > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG From fsteele at gmail.com Wed May 22 17:02:40 2013 From: fsteele at gmail.com (Frank Steele) Date: Wed, 22 May 2013 11:02:40 -0400 Subject: [Pythonmac-SIG] Py2app-built app giving error 255 on loading AppKit? In-Reply-To: <3B1A9D50-3A86-45C1-B842-7DB8E1B24BF0@mac.com> References: <33327952.1369145084545.JavaMail.root@wamui-junio.atl.sa.earthlink.net> <3B1A9D50-3A86-45C1-B842-7DB8E1B24BF0@mac.com> Message-ID: That was it -- Thanks! I built a new Python 2.7.4 virtual environment this morning, and code built with gives 10.6 as the minimum target. I'm not sure how my 2.7.3 environment got built with 10.8 only. Best, Frank On May 22, 2013, at 4:15 AM, Ronald Oussoren wrote: > > On 21 May, 2013, at 16:04, fsteele at mindspring.com wrote: > >> I've built an app with Py2app. It runs as expected on my development machine, but on machines (10.7.5 and 10.8.2, at least) without a development environment, I get: >> >> testmini1:~ administrator$ /Users/administrator/Desktop/EasySetup.app/Contents/MacOS/EasySetup ; exit; >> Traceback (most recent call last): >> File "/Users/administrator/Desktop/EasySetup.app/Contents/Resources/__boot__.py", line 43, in >> _run() >> File "/Users/administrator/Desktop/EasySetup.app/Contents/Resources/__boot__.py", line 38, in _run >> exec(compile(source, path, 'exec'), globals(), globals()) >> File "/Users/administrator/Desktop/EasySetup.app/Contents/Resources/EasySetup.py", line 13, in >> import AppKit >> File "AppKit/__init__.pyc", line 43, in >> File "AppKit/_AppKit.pyc", line 14, in >> File "AppKit/_AppKit.pyc", line 10, in __load >> ImportError: dlopen(/Users/administrator/Desktop/EasySetup.app/Contents/Resources/lib/python2.7/lib-dynload/AppKit/_AppKit.so, 2): Symbol not found: _OBJC_CLASS_$_NSObject >> Referenced from: /Users/administrator/Desktop/EasySetup.app/Contents/Resources/lib/python2.7/lib-dynload/AppKit/_AppKit.so >> Expected in: /usr/lib/libobjc.A.dylib >> in /Users/administrator/Desktop/EasySetup.app/Contents/Resources/lib/python2.7/lib-dynload/AppKit/_AppKit.so >> 2013-05-21 09:19:44.502 EasySetup[393:707] EasySetup Error >> >> The _AppKit.so file referenced is in the location referenced. I've deleted /build and /dist and rebuilt the app. > > It is odd that the problem occurs on all machines without development tools. What's the deployment target of the application? You can check the actual deployment target in binaries (such as _AppKit.so) using "otool -vl FILENAME", look for 'LC_VERSION_MIN_MACOSX'. Having a too high deployment target could explain why the app doesn't work on 10.7, but not why it doesn't work on 10.8 machines without devtools. > > Ronald > >> >> My setup.py: >> >> from setuptools import setup >> >> APP = ['EasySetup.py'] >> DATA_FILES = ['EasySetup/MainMenu.xib', 'loggers.py', 'MacTools.py', 'create_corplocaladministrator-1.0.pkg', 'macepoprodagentinstall.sh', 'corp-logo.png'] >> OPTIONS = {'argv_emulation': False, 'iconfile':'EasySetup.icns'} >> >> setup( >> app=APP, >> data_files=DATA_FILES, >> install_requires=["pyobjc"], >> options={'py2app': OPTIONS}, >> setup_requires=['py2app'], >> ) >> >> >> I'm using virtualenv, where "yolk -list" gives: >> >> python - 2.7.3 - active development (/usr/local/Cellar/python/2.7.3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload) >> altgraph - 0.10.2 - active >> beautifulsoup4 - 4.1.3 - active >> macholib - 1.5.1 - active >> modulegraph - 0.10.4 - active >> pexpect - 2.4 - active >> pip - 1.3.1 - active >> py2app - 0.7.3 - non-active >> pyobjc-core - 2.5.1 - active >> pyobjc-framework-Accounts - 2.5.1 - active >> pyobjc-framework-AddressBook - 2.5.1 - active >> pyobjc-framework-AppleScriptKit - 2.5.1 - active >> pyobjc-framework-AppleScriptObjC - 2.5.1 - active >> pyobjc-framework-Automator - 2.5.1 - active >> pyobjc-framework-CFNetwork - 2.5.1 - active >> pyobjc-framework-CalendarStore - 2.5.1 - active >> pyobjc-framework-Cocoa - 2.5.1 - active >> pyobjc-framework-Collaboration - 2.5.1 - active >> pyobjc-framework-CoreData - 2.5.1 - active >> pyobjc-framework-CoreLocation - 2.5.1 - active >> pyobjc-framework-CoreText - 2.5.1 - active >> pyobjc-framework-DictionaryServices - 2.5.1 - active >> pyobjc-framework-EventKit - 2.5.1 - active >> pyobjc-framework-ExceptionHandling - 2.5.1 - active >> pyobjc-framework-FSEvents - 2.5.1 - active >> pyobjc-framework-InputMethodKit - 2.5.1 - active >> pyobjc-framework-InstallerPlugins - 2.5.1 - active >> pyobjc-framework-InstantMessage - 2.5.1 - active >> pyobjc-framework-LatentSemanticMapping - 2.5.1 - active >> pyobjc-framework-LaunchServices - 2.5.1 - active >> pyobjc-framework-Message - 2.5.1 - active >> pyobjc-framework-PreferencePanes - 2.5.1 - active >> pyobjc-framework-PubSub - 2.5.1 - active >> pyobjc-framework-QTKit - 2.5.1 - active >> pyobjc-framework-Quartz - 2.5.1 - active >> pyobjc-framework-ScreenSaver - 2.5.1 - active >> pyobjc-framework-ScriptingBridge - 2.5.1 - active >> pyobjc-framework-SearchKit - 2.5.1 - active >> pyobjc-framework-ServerNotification - 2.5.1 - active >> pyobjc-framework-ServiceManagement - 2.5.1 - active >> pyobjc-framework-Social - 2.5.1 - active >> pyobjc-framework-SyncServices - 2.5.1 - active >> pyobjc-framework-SystemConfiguration - 2.5.1 - active >> pyobjc-framework-WebKit - 2.5.1 - active >> pyobjc - 2.5.1 - active >> requests - 1.2.0 - active >> setuptools - 0.6c11 - active >> wsgiref - 0.1.2 - active development (/usr/local/Cellar/python/2.7.3/Frameworks/Python.framework/Versions/2.7/lib/python2.7) >> yolk - 0.4.3 - active >> >> There are so many threads in play, I'm not sure which to yank on first. Does anybody see anything that rings any alarm bells? Any suggestions on further investigation? >> >> Thanks! >> Frank >> _______________________________________________ >> Pythonmac-SIG maillist - Pythonmac-SIG at python.org >> http://mail.python.org/mailman/listinfo/pythonmac-sig >> unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG From chris.barker at noaa.gov Wed May 22 19:30:15 2013 From: chris.barker at noaa.gov (Chris Barker - NOAA Federal) Date: Wed, 22 May 2013 10:30:15 -0700 Subject: [Pythonmac-SIG] Advice wanted on dependency building... Message-ID: Hey folks, I'm looking for advice, and maybe even some consensus among the MacPython community, on how to build and distribute packages with non-python dependencies. As we all know, a number of Python packages require libs that are used outside of python itself. These libs fall into (sort of) what I would call two catagories; 1) general purpose libs used by multiple python packages: libpng, freetype, etc. (I'm still confused on why Apple doesn't provide all these -- particularly libpng -- what's up with that?) 2) More specific libs, likely only used by a single python package -- netcdf, proj.4, etc. Users also fall into two categories: 1) Folks that do Python development on OS-X much like Linux, etc -- these folks are likely to use macports or homebrew, or are used to the .configure, make, make install dance. We don't need to do anything to support these folks -- "pip install" generally works for them. 2) folks that want to use a Mac like a Mac, and people that develop for those folks -- these people need binary installers, and may want to be able to use and deploy either packages or applications (Py2app) that will run on systems older than the one developed on, or want universal builds, or ??? - These are the folks I'd like to support, but I'm still unsure as to how best to do that. Way back when Bob Ippolito maintained a repository of binary packages for the mac -- it was a great resource, but he's long since moved on to other things. We kind of get away with it because a number of major package maintainers have done a good job of providing binaries themselves (wxPython, numpy/scipy/matplotlib), but others fail to do so (PIL). Plus some of us have minor packages that we want to distribute. I'd like to put together an archive, much like Bob's was, or like Christoph Gohlke's one for Windows (By the way -- that one is HUGE -- I have no idea how he keeps it up! http://www.lfd.uci.edu/~gohlke/pythonlibs/) But with or without that archive, I still need to build the darn things. So now on to the question: How should the dependencies be distributed? 1) They should be built to match the Python binary being targeted (honestly, I think that's now only the Intel 32-64 bit ones -- PPC machines, and pre 10.6, are getting really rare...) 2) Static or dynamic? IIUC, most successful binary packages for the Mac have relied on statically linking the dependencies -- this works, and is pretty robust. However, it can be kind of a pain to do (though I've finally figure how to do it more reliably!). Also, it seems like a waste to me for packages that use common dependencies -- how many copies of libpng do I really want linked into my single instance of Python at run time? But if dynamic, where do you put them? We'll still want to ship them with the binary, so people have a one-click install. I don't think we want to install them into a standard location, like /usr/local, as that could stomp on something else the user is doing. So: - Do we put the in the Python Framework, say in: /Library/Frameworks/Python.framework/Versions/2.7/lib - This make some sense, but then you couldn't share them between, say, python 2.7 and 3.3 (and however many other versions... - Do we create a new Framework, say: /Library/Frameworks/PythonDeps.framework and put them all there? But this may confuse things for different deployment targets. If we go one of these routes, would we have a separate installer for the libs, and all the other installers would depend on that? Or would each installer put a copy of the libs it needed into the common location, maybe writing over one that's already there (which should be OK -- it should be compatible, or have a different version number, etc.) Note that I've used the term "we" here ;-) I'm hoping that others will join me in following a convention and getting stuff out there, but even if not, I'd love feedback on how best to do it. By the way, the other goal is to build scripts that do the builds the way we need for various libs, packages, etc, so that it's easy to do it all when new builds are required... (maybe use gattai? -- http://sourceforge.net/projects/gattai/) Feedback please!! -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From ronaldoussoren at mac.com Wed May 22 23:53:20 2013 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Wed, 22 May 2013 23:53:20 +0200 Subject: [Pythonmac-SIG] Advice wanted on dependency building... In-Reply-To: References: Message-ID: On 22 May, 2013, at 19:30, Chris Barker - NOAA Federal wrote: > Hey folks, > > I'm looking for advice, and maybe even some consensus among the > MacPython community, on how to build and distribute packages with > non-python dependencies. > > As we all know, a number of Python packages require libs that are used > outside of python itself. These libs fall into (sort of) what I would > call two catagories; > > 1) general purpose libs used by multiple python packages: libpng, freetype, etc. > (I'm still confused on why Apple doesn't provide all these -- > particularly libpng -- what's up with that?) In general Apple doesn't ship libraries that it doesn't use itself, and for image format support they have their own libraries (in particular the ImageIO framework). To move back onto topic, not relying on unix-level libraries in OSX is in a good thing as it makes it easier to support multiple OSX versions with a single set of binaries. > > 2) More specific libs, likely only used by a single python package -- > netcdf, proj.4, etc. > > Users also fall into two categories: > > 1) Folks that do Python development on OS-X much like Linux, etc -- > these folks are likely to use macports or homebrew, or are used to the > .configure, make, make install dance. We don't need to do anything to > support these folks -- "pip install" generally works for them. Except for a number of more complicated libraries (such as PIL/Pillow) when using universal binaries (when using 'pip install', homebrew/macports/... have their own mechanisms for building). > > 2) folks that want to use a Mac like a Mac, and people that develop > for those folks -- these people need binary installers, and may want > to be able to use and deploy either packages or applications (Py2app) > that will run on systems older than the one developed on, or want > universal builds, or ??? > - These are the folks I'd like to support, but I'm still unsure as > to how best to do that. It would be nice to have a set of binary "packages", based on a reproducable build system. > > Way back when Bob Ippolito maintained a repository of binary packages > for the mac -- it was a great resource, but he's long since moved on > to other things. The binary packages that Bob maintained had IMHO two major problems: 1) The largest problem is that the packages were AFAIK created ad-hoc (Bob or some other contributor did the magic incantations to build library dependencies) 2) The packages were Installer.app packages. The current state of the art for development/project environments is to use virtualenv or buildout to create separated python installations and install all project depedencies there instead of the global site-packages directory. That's not something that's easily supported with Installer.app packages. > > We kind of get away with it because a number of major package > maintainers have done a good job of providing binaries themselves > (wxPython, numpy/scipy/matplotlib), but others fail to do so (PIL). > Plus some of us have minor packages that we want to distribute. > > I'd like to put together an archive, much like Bob's was, or like > Christoph Gohlke's one for Windows > (By the way -- that one is HUGE -- I have no idea how he keeps it up! > http://www.lfd.uci.edu/~gohlke/pythonlibs/) > > But with or without that archive, I still need to build the darn > things. So now on to the question: > > How should the dependencies be distributed? > > 1) They should be built to match the Python binary being targeted > (honestly, I think that's now only the Intel 32-64 bit ones -- PPC > machines, and pre 10.6, are getting really rare...) No objections there. Supporting PPC is getting way to hard now that the Xcode version that you can install on recent machines cannot generate PPC code. I have VMs with older OSX releases for running the compiler, but that's barely usable. > > 2) Static or dynamic? > > IIUC, most successful binary packages for the Mac have relied on > statically linking the dependencies -- this works, and is pretty > robust. However, it can be kind of a pain to do (though I've finally > figure how to do it more reliably!). Also, it seems like a waste to me > for packages that use common dependencies -- how many copies of libpng > do I really want linked into my single instance of Python at run time? As long as the libpng state isn't shared static linking isn't really a problem. It does get a problem when two extensions use the same external library and share state, for example the curses and curses_panel extensions in the stdlib. Dynamic linking has at least two disadvantages: 1) Relocation of the installation prefix is harder due to the way the dynamic linker on OSX looks for libraries: when extension foo.so uses library libfoo.dylib the absolute path of libfoo.dylib is included in the MachO header for foo.so. The header is easily updated using macholib, but that makes installation harder and isn't supported by the standard packaging tools (easy_install and pip) 2) The primary use case for dynamic linking is to share dylibs between extensions, and when those extensions are in different PyPI packages the packaging story gets more complicated. The easiest workaround is to ignore sharing dylibs and still bundle multipe copies of libpng if two different PyPI packages both link with libpng. > > But if dynamic, where do you put them? We'll still want to ship them > with the binary, so people have a one-click install. I don't think we > want to install them into a standard location, like /usr/local, as > that could stomp on something else the user is doing. So: > - Do we put the in the Python Framework, say in: > /Library/Frameworks/Python.framework/Versions/2.7/lib > - This make some sense, but then you couldn't share them between, > say, python 2.7 and 3.3 (and however many other versions... > - Do we create a new Framework, say: > /Library/Frameworks/PythonDeps.framework and put them all there? But > this may confuse things for different deployment targets. A new framework isn't necessary. There are three locations that could easily be used: 1) A directory in Python.framework, for example /Library/Frameworks/Python.framework/Frameworks 2) A directory in /Library/Python, for example /Library/Python/Externals 3) As 2), but in the users home directory (~/Library/Python/Externals) The latter is the only one where you can install without admin privileges. > > If we go one of these routes, would we have a separate installer for > the libs, and all the other installers would depend on that? Or would > each installer put a copy of the libs it needed into the common > location, maybe writing over one that's already there (which should be > OK -- it should be compatible, or have a different version number, > etc.) The folks over on distutils-sig are working towards support for wheels (PEP 427, ) at least in pip and distribute/setuptools and possibly in the stdlib as well (for 3.4). It would be nice if the OSX package collection would be in wheel format, that would make it relatively easy to install the packages using the defacto standard tools. What I haven't looked into yet is how easy it would be to configure pip to look for packages on PyPI and then look for binaries (wheels) in some other location. > > Note that I've used the term "we" here ;-) I'm hoping that others > will join me in following a convention and getting stuff out there, > but even if not, I'd love feedback on how best to do it. Good luck :-). This is fairly boring low-level packaging work, and that tends to put off people. At least it is a lot easier than trying to fix or replace distutils, that has burned out at least 3 generations of developers ;-/ > > By the way, the other goal is to build scripts that do the builds the > way we need for various libs, packages, etc, so that it's easy to do > it all when new builds are required... > (maybe use gattai? -- http://sourceforge.net/projects/gattai/) I haven't used gattai before, but at least it is Python code. Building tools for this from scratch would also not be very hard, I already done so a number of times (such as the build-installer.py script in the CPython repository). The hard part should be setting up the build infrastructure and build scripts, once couple of relatively hard packages like PIL or wx have been processed adding more packages and new versions of packages should be easy. Ronald > > Feedback please!! > > -Chris > > -- > > Christopher Barker, Ph.D. > Oceanographer > > Emergency Response Division > NOAA/NOS/OR&R (206) 526-6959 voice > 7600 Sand Point Way NE (206) 526-6329 fax > Seattle, WA 98115 (206) 526-6317 main reception > > Chris.Barker at noaa.gov > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG From chris.barker at noaa.gov Thu May 23 00:46:11 2013 From: chris.barker at noaa.gov (Chris Barker - NOAA Federal) Date: Wed, 22 May 2013 15:46:11 -0700 Subject: [Pythonmac-SIG] Advice wanted on dependency building... In-Reply-To: References: Message-ID: Thanks Ronald, On Wed, May 22, 2013 at 2:53 PM, Ronald Oussoren wrote: > To move back onto topic, not relying on unix-level libraries in OSX is in a good thing as it makes it easier to support multiple OSX versions with a single set of binaries. hmm -- I figured if it was a system lib, it should work on whatever system It's running on. For example, I'm working right now on the netcdf4 lib -- it required hdr5, which requires zlib. I"m using the system zlib -- is that a bad idea? Should I build it too, to make sure it matches the rest of it? (I do want the binaries to run anywhere the binary Python I'm using runs) > Except for a number of more complicated libraries (such as PIL/Pillow) when using universal binaries (when using 'pip install', homebrew/macports/... have their own mechanisms for building). right -- Universal libs are not well supported by those systems -- but that's the power users problem! >> 2) folks that want to use a Mac like a Mac, and people that develop >> for those folks -- these people need binary installers, and may want >> to be able to use and deploy either packages or applications (Py2app) >> that will run on systems older than the one developed on, or want >> universal builds, or ??? >> - These are the folks I'd like to support, but I'm still unsure as >> to how best to do that. > > It would be nice to have a set of binary "packages", based on a reproducable build system. Exactly what I'd like to build! >> Way back when Bob Ippolito maintained a repository of binary packages >> for the mac -- it was a great resource, but he's long since moved on >> to other things. > > The binary packages that Bob maintained had IMHO two major problems: > > 1) The largest problem is that the packages were AFAIK created ad-hoc (Bob or some other contributor did the magic incantations to build library dependencies) Yeah, and he never gave anyone else permission to push to it... > 2) The packages were Installer.app packages. The current state of the art for development/project environments is to use virtualenv or buildout to create separated python installations and install all project depedencies there instead of the global site-packages directory. That's not something that's easily supported with Installer.app packages. It was the way to go at the time, but I agree a binary format that supports virtualenv would be great. >> do I really want linked into my single instance of Python at run time? > > As long as the libpng state isn't shared static linking isn't really a > problem. good to know, but somehow it still offends my sensibilities > Dynamic linking has at least two disadvantages: > > 1) Relocation of the installation prefix is harder due to the way the dynamic linker on OSX looks for libraries: yeah -- that is a pain. > The header is easily updated using macholib, but that makes installation > harder and isn't supported by the standard packaging tools (easy_install > and pip) But if we put the shared libs in amore central location, then all your virtual-ens could use the same ones, yes? > 2) The primary use case for dynamic linking is to share dylibs between extensions, and when those extensions are in different PyPI packages the packaging story gets more complicated. The easiest workaround is to ignore sharing dylibs and still bundle multipe copies of libpng if two different PyPI packages both link with libpng. when you say bundle, do you mean static link? Or just package up the dylib with the bundle, which is what i was thinking -- each package installs the libs it needs, which may or may not already have been installed by another package -- but so what? And I expect the number of folks building packages will be fairly small, so one builder would one have to build one set of dylibs. >> But if dynamic, where do you put them? We'll still want to ship them > A new framework isn't necessary. There are three locations that could easily be used: > > 1) A directory in Python.framework, for example /Library/Frameworks/Python.framework/Frameworks That makes sense to me. > 2) A directory in /Library/Python, for example /Library/Python/Externals that feels a bit lke Apple's turf, but what do I know? > 3) As 2), but in the users home directory (~/Library/Python/Externals) > The latter is the only one where you can install without admin privileges. But we put the python binaries in /LIbrary/Frameworks -- it seems we should do the same with libs... > The folks over on distutils-sig are working towards support for wheels (PEP 427, ) at least in pip and distribute/setuptools and possibly in the stdlib as well (for 3.4). It would be nice if the OSX package collection would be in wheel format, that would make it relatively easy to install the packages using the defacto standard tools. Any idea what the time scale is on this? > What I haven't looked into yet is how easy it would be to configure pip to look for packages on PyPI and then look for binaries (wheels) in some other location. Have the pip folks made any commitment at all to supporting binary installs? That's a big missing feature. >> Note that I've used the term "we" here ;-) I'm hoping that others >> will join me in following a convention and getting stuff out there, >> but even if not, I'd love feedback on how best to do it. > > Good luck :-). This is fairly boring low-level packaging work, and that tends to put off people. At least it is a lot easier than trying to fix or replace distutils, that has burned out at least 3 generations of developers ;-/ Well, I'm an optimist -- and recently at least you and Ned and Russel Owen have bee known to contribute. >> By the way, the other goal is to build scripts that do the builds the >> way we need for various libs, packages, etc, so that it's easy to do >> it all when new builds are required... >> (maybe use gattai? -- http://sourceforge.net/projects/gattai/) > > I haven't used gattai before, but at least it is Python code. Building tools for this from scratch would also not be very hard, I already done so a number of times (such as the build-installer.py script in the CPython repository). yup -- me too, though I find myself wanting to add various make-like features, and it dawns on me that I am re-inventing the wheel! So I want to give Gattai a shot. Also Kevin is likely to be helpful. > The hard part should be setting up the build infrastructure and build scripts, once couple of relatively hard packages like PIL or wx have been processed adding more packages and new versions of packages should be easy. Exactly. But I don't know about wx -- that is a bear, and Robin's been doing a fine job! Thanks for you ideas, -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From chris.barker at noaa.gov Thu May 23 07:38:07 2013 From: chris.barker at noaa.gov (Chris Barker - NOAA Federal) Date: Wed, 22 May 2013 22:38:07 -0700 Subject: [Pythonmac-SIG] Advice wanted on dependency building... In-Reply-To: References: Message-ID: I just poked a bit into the Anaconda Python distribution. their packages are simple tarballs, but I think they have a dependency management system of some sort. They deliver the dependencies as separate packages (tarballs), one for each lib. It looksl ike it all gets unpacked inot a sinlgle dir (in /opt), and an example python extension is built like this: $ otool -L netCDF4.so netCDF4.so: @loader_path/../../libnetcdf.7.dylib (compatibility version 10.0.0, current version 10.0.0) @loader_path/../../libhdf5_hl.7.dylib (compatibility version 8.0.0, current version 8.3.0) @loader_path/../../libhdf5.7.dylib (compatibility version 8.0.0, current version 8.3.0) @loader_path/../../libz.1.dylib (compatibility version 1.0.0, current version 1.2.7) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.0.0) I don't know how to get that @loader_path thing in there, but this seems like a reasonable way to do it (though I guess it wouldn't support virtualenv...) -Chris On Wed, May 22, 2013 at 3:46 PM, Chris Barker - NOAA Federal wrote: > Thanks Ronald, > > On Wed, May 22, 2013 at 2:53 PM, Ronald Oussoren wrote: > >> To move back onto topic, not relying on unix-level libraries in OSX is in a good thing as it makes it easier to support multiple OSX versions with a single set of binaries. > > hmm -- I figured if it was a system lib, it should work on whatever > system It's running on. For example, I'm working right now on the > netcdf4 lib -- it required hdr5, which requires zlib. I"m using the > system zlib -- is that a bad idea? Should I build it too, to make sure > it matches the rest of it? > > (I do want the binaries to run anywhere the binary Python I'm using runs) > > >> Except for a number of more complicated libraries (such as PIL/Pillow) when using universal binaries (when using 'pip install', homebrew/macports/... have their own mechanisms for building). > > right -- Universal libs are not well supported by those systems -- but > that's the power users problem! > >>> 2) folks that want to use a Mac like a Mac, and people that develop >>> for those folks -- these people need binary installers, and may want >>> to be able to use and deploy either packages or applications (Py2app) >>> that will run on systems older than the one developed on, or want >>> universal builds, or ??? >>> - These are the folks I'd like to support, but I'm still unsure as >>> to how best to do that. >> >> It would be nice to have a set of binary "packages", based on a reproducable build system. > > Exactly what I'd like to build! > >>> Way back when Bob Ippolito maintained a repository of binary packages >>> for the mac -- it was a great resource, but he's long since moved on >>> to other things. >> >> The binary packages that Bob maintained had IMHO two major problems: >> >> 1) The largest problem is that the packages were AFAIK created ad-hoc (Bob or some other contributor did the magic incantations to build library dependencies) > > Yeah, and he never gave anyone else permission to push to it... > >> 2) The packages were Installer.app packages. The current state of the art for development/project environments is to use virtualenv or buildout to create separated python installations and install all project depedencies there instead of the global site-packages directory. That's not something that's easily supported with Installer.app packages. > > It was the way to go at the time, but I agree a binary format that > supports virtualenv would be great. > >>> do I really want linked into my single instance of Python at run time? >> >> As long as the libpng state isn't shared static linking isn't really a >> problem. > > good to know, but somehow it still offends my sensibilities > >> Dynamic linking has at least two disadvantages: >> >> 1) Relocation of the installation prefix is harder due to the way the dynamic linker on OSX looks for libraries: > > yeah -- that is a pain. > >> The header is easily updated using macholib, but that makes installation >> harder and isn't supported by the standard packaging tools (easy_install >> and pip) > > But if we put the shared libs in amore central location, then all your > virtual-ens could use the same ones, yes? > >> 2) The primary use case for dynamic linking is to share dylibs between extensions, and when those extensions are in different PyPI packages the packaging story gets more complicated. The easiest workaround is to ignore sharing dylibs and still bundle multipe copies of libpng if two different PyPI packages both link with libpng. > > when you say bundle, do you mean static link? Or just package up the > dylib with the bundle, which is what i was thinking -- each package > installs the libs it needs, which may or may not already have been > installed by another package -- but so what? > > And I expect the number of folks building packages will be fairly > small, so one builder would one have to build one set of dylibs. > >>> But if dynamic, where do you put them? We'll still want to ship them >> A new framework isn't necessary. There are three locations that could easily be used: >> >> 1) A directory in Python.framework, for example /Library/Frameworks/Python.framework/Frameworks > > That makes sense to me. > >> 2) A directory in /Library/Python, for example /Library/Python/Externals > > that feels a bit lke Apple's turf, but what do I know? > >> 3) As 2), but in the users home directory (~/Library/Python/Externals) >> The latter is the only one where you can install without admin privileges. > > But we put the python binaries in /LIbrary/Frameworks -- it seems we > should do the same with libs... > > >> The folks over on distutils-sig are working towards support for wheels (PEP 427, ) at least in pip and distribute/setuptools and possibly in the stdlib as well (for 3.4). It would be nice if the OSX package collection would be in wheel format, that would make it relatively easy to install the packages using the defacto standard tools. > > Any idea what the time scale is on this? > >> What I haven't looked into yet is how easy it would be to configure pip to look for packages on PyPI and then look for binaries (wheels) in some other location. > > Have the pip folks made any commitment at all to supporting binary > installs? That's a big missing feature. > >>> Note that I've used the term "we" here ;-) I'm hoping that others >>> will join me in following a convention and getting stuff out there, >>> but even if not, I'd love feedback on how best to do it. >> >> Good luck :-). This is fairly boring low-level packaging work, and that tends to put off people. At least it is a lot easier than trying to fix or replace distutils, that has burned out at least 3 generations of developers ;-/ > > Well, I'm an optimist -- and recently at least you and Ned and Russel > Owen have bee known to contribute. > >>> By the way, the other goal is to build scripts that do the builds the >>> way we need for various libs, packages, etc, so that it's easy to do >>> it all when new builds are required... >>> (maybe use gattai? -- http://sourceforge.net/projects/gattai/) >> >> I haven't used gattai before, but at least it is Python code. Building tools for this from scratch would also not be very hard, I already done so a number of times (such as the build-installer.py script in the CPython repository). > > yup -- me too, though I find myself wanting to add various make-like > features, and it dawns on me that I am re-inventing the wheel! So I > want to give Gattai a shot. Also Kevin is likely to be helpful. > >> The hard part should be setting up the build infrastructure and build scripts, once couple of relatively hard packages like PIL or wx have been processed adding more packages and new versions of packages should be easy. > > Exactly. But I don't know about wx -- that is a bear, and Robin's been > doing a fine job! > > Thanks for you ideas, > > -Chris > > > -- > > Christopher Barker, Ph.D. > Oceanographer > > Emergency Response Division > NOAA/NOS/OR&R (206) 526-6959 voice > 7600 Sand Point Way NE (206) 526-6329 fax > Seattle, WA 98115 (206) 526-6317 main reception > > Chris.Barker at noaa.gov -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From ronaldoussoren at mac.com Thu May 23 08:08:43 2013 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Thu, 23 May 2013 08:08:43 +0200 Subject: [Pythonmac-SIG] Advice wanted on dependency building... In-Reply-To: References: Message-ID: On 23 May, 2013, at 7:38, Chris Barker - NOAA Federal wrote: > I just poked a bit into the Anaconda Python distribution. their > packages are simple tarballs, but I think they have a dependency > management system of some sort. > > They deliver the dependencies as separate packages (tarballs), one for > each lib. It looksl ike it all gets unpacked inot a sinlgle dir (in > /opt), and an example python extension is built like this: > > $ otool -L netCDF4.so > netCDF4.so: > @loader_path/../../libnetcdf.7.dylib (compatibility version 10.0.0, > current version 10.0.0) > @loader_path/../../libhdf5_hl.7.dylib (compatibility version 8.0.0, > current version 8.3.0) > @loader_path/../../libhdf5.7.dylib (compatibility version 8.0.0, > current version 8.3.0) > @loader_path/../../libz.1.dylib (compatibility version 1.0.0, current > version 1.2.7) > /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current > version 111.0.0) > > > I don't know how to get that @loader_path thing in there, but this > seems like a reasonable way to do it (though I guess it wouldn't > support virtualenv...) Interesting... @loader_path could work, it expands into the path of MachO binary that links to the library (in your example to os.path.abspath(netCDF4.so). That can be used to point to a fixed location in the sys.prefix tree, the relative path for every extension could be different but would be known at build time. It might require a macholib step when building installers, but that shouldn't be a problem. @rpath could also work for installs outside of virtualenv-s, but would require changes to the Python build. Ronald P.S. I need to check if macholib (and hence py2app) supports @loader_path, but adding such support shouldn't be hard as the semantics are pretty easy. From vip at avatar.com.au Thu May 23 08:49:07 2013 From: vip at avatar.com.au (DavidWorrall) Date: Thu, 23 May 2013 16:49:07 +1000 Subject: [Pythonmac-SIG] [OT] advice on distributing for different OSs In-Reply-To: References: Message-ID: <7C930016-B201-41B4-9A08-8474CBE052A7@avatar.com.au> Hi All, Chris and Ronald's posting: Advice wanted on dependency building... prompts me to ask this group for some assistance, if you are able. I've been developing in Python on Mac's since b4 OSX and I have to give a workshop on the other side of the world in a (networked) non-OSX university lab (Windows, I think). Now I know dependencies are one of python's strengths, but my own working environment is such a rat's nest hotch-potch of different tools it got me to wondering if there are some angels out there who support a downloadable collection of useful tools for various versions that python on OSX, Linux and Windows OSs that members of this group would recommend. 2.7.x seems the most viable Python. My orientation is scientific with an added emphasis on sound. I've looked at Enthought's offerings, for example. They seem pretty slick, but don't know what corporate "dependencies" I might be inadvertently "buying" into in adopting their builds. Any thoughts/recommendations- or suggestions of a more appropriate forum to ask this - would be much appreciated. thanks, David _____________________________________________ Dr David Worrall Experimental Composer, Polymedia Adjunct Senior Research Fellow, Australian National University David.Worrall at anu.edu.au Board Member, International Community for Auditory Display Regional Editor, Organised Sound (CUP) worrall.avatar.com.au sonification.com.au -------------- next part -------------- An HTML attachment was scrubbed... URL: From ronaldoussoren at mac.com Thu May 23 08:53:14 2013 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Thu, 23 May 2013 08:53:14 +0200 Subject: [Pythonmac-SIG] Advice wanted on dependency building... In-Reply-To: References: Message-ID: <8F3EF2BE-EC8F-4EEF-B4D4-CDC1A2343706@mac.com> On 23 May, 2013, at 0:46, Chris Barker - NOAA Federal wrote: > Thanks Ronald, > > On Wed, May 22, 2013 at 2:53 PM, Ronald Oussoren wrote: > >> To move back onto topic, not relying on unix-level libraries in OSX is in a good thing as it makes it easier to support multiple OSX versions with a single set of binaries. > > hmm -- I figured if it was a system lib, it should work on whatever > system It's running on. For example, I'm working right now on the > netcdf4 lib -- it required hdr5, which requires zlib. I"m using the > system zlib -- is that a bad idea? Should I build it too, to make sure > it matches the rest of it? > > (I do want the binaries to run anywhere the binary Python I'm using runs) It depends on the library. Zlib should be fine, that library doesn't change very often and mostly in backward compatible ways. An example of a problematic library is OpenSSL, that doesn't a stable ABI and hence there are now two copies of libcrypto.dylib on OSX 10.8 and the one you'll link to by default is not available on all older versions of OSX (not sure how recently that was changed, but that's not important). > > >> Except for a number of more complicated libraries (such as PIL/Pillow) when using universal binaries (when using 'pip install', homebrew/macports/... have their own mechanisms for building). > > right -- Universal libs are not well supported by those systems -- but > that's the power users problem! I agree w.r.t. homebrew and macports, but it would be nice if 'pip install' would work with your system with minimal changes to the pip configuration (e.g. "just add ... to your piprc and then 'pip install foo' will install a binary from the repo instead of building the binaries itself"). > >>> 2) folks that want to use a Mac like a Mac, and people that develop >>> for those folks -- these people need binary installers, and may want >>> to be able to use and deploy either packages or applications (Py2app) >>> that will run on systems older than the one developed on, or want >>> universal builds, or ??? >>> - These are the folks I'd like to support, but I'm still unsure as >>> to how best to do that. >> >> It would be nice to have a set of binary "packages", based on a reproducable build system. > > Exactly what I'd like to build! > >>> Way back when Bob Ippolito maintained a repository of binary packages >>> for the mac -- it was a great resource, but he's long since moved on >>> to other things. >> >> The binary packages that Bob maintained had IMHO two major problems: >> >> 1) The largest problem is that the packages were AFAIK created ad-hoc (Bob or some other contributor did the magic incantations to build library dependencies) > > Yeah, and he never gave anyone else permission to push to it... I wouldn't have done that either until the someone else has a proven trackrecord (both in providing usable binaries and in being known in the community). > >> 2) The packages were Installer.app packages. The current s > >> The header is easily updated using macholib, but that makes installation >> harder and isn't supported by the standard packaging tools (easy_install >> and pip) > > But if we put the shared libs in amore central location, then all your > virtual-ens could use the same ones, yes? Yes. It would make it harder to switch library versions, but not by much. > >> 2) The primary use case for dynamic linking is to share dylibs between extensions, and when those extensions are in different PyPI packages the packaging story gets more complicated. The easiest workaround is to ignore sharing dylibs and still bundle multipe copies of libpng if two different PyPI packages both link with libpng. > > when you say bundle, do you mean static link? Or just package up the > dylib with the bundle, which is what i was thinking -- each package > installs the libs it needs, which may or may not already have been > installed by another package -- but so what? Uninstall can be a problem with that, you'd have to refcount installed files to ensure that libraries are only removed when the last user is uninstalled. I don't know if the installation format used by pip supports having two packages that install the same file. This can be worked around with fake PyPI packages that only install the shared libraries and have the real packages depend on that (that is a "macbins-libpng" package with libpng.dylib and have the Imaging package depend on that). > And I expect the number of folks building packages will be fairly > small, so one builder would one have to build one set of dylibs. > >>> But if dynamic, where do you put them? We'll still want to ship them >> A new framework isn't necessary. There are three locations that could easily be used: >> >> 1) A directory in Python.framework, for example /Library/Frameworks/Python.framework/Frameworks > > That makes sense to me. > >> 2) A directory in /Library/Python, for example /Library/Python/Externals > > that feels a bit lke Apple's turf, but what do I know? /Library can be used, we'd just have to pick a name that Apple is unlikely to use. > >> 3) As 2), but in the users home directory (~/Library/Python/Externals) >> The latter is the only one where you can install without admin privileges. > > But we put the python binaries in /LIbrary/Frameworks -- it seems we > should do the same with libs... I'm probably atypical, but my main account doesn't have admin privileges. It would suck if I'd have to use sudo to install. The @loader_path option you mentioned in a followup e-mail could help there. That way the shared libraries can be installed in a fixed location relative to sys.prefix, while still supporting virtualenvs. You wouldn't be able to share shared libraries between python versions or virtualenvs, but that's not really a problem (disk space is cheap). > > >> The folks over on distutils-sig are working towards support for wheels (PEP 427, ) at least in pip and distribute/setuptools and possibly in the stdlib as well (for 3.4). It would be nice if the OSX package collection would be in wheel format, that would make it relatively easy to install the packages using the defacto standard tools. > > Any idea what the time scale is on this? Before Python 3.4 is out, which means sometime this summer. The code is mostly there (see ), and there's also distlib () with distil () as an example pip-like tool. IIRC distlib was intended to go in the stdlib for 3.4, after it became clear that the packaging/distutils2 effort wouldn't be ready anytime soon. I don't know if distlib is still targetting the stdlib, but the pip folks are looking into using it (which was an explicit goal: distlib contains the shared functionality that any packaging tool for Python needs to have and that is backed by a specification (PEP)). > >> What I haven't looked into yet is how easy it would be to configure pip to look for packages on PyPI and then look for binaries (wheels) in some other location. > > Have the pip folks made any commitment at all to supporting binary > installs? That's a big missing feature. Yes, through wheels. The development branch in pips repo () contains support for wheels (both creating and installing), although AFAIK installation of pips requires a command-line argument at the moment because wheel support is experimental at this point. > >>> Note that I've used the term "we" here ;-) I'm hoping that others >>> will join me in following a convention and getting stuff out there, >>> but even if not, I'd love feedback on how best to do it. >> >> Good luck :-). This is fairly boring low-level packaging work, and that tends to put off people. At least it is a lot easier than trying to fix or replace distutils, that has burned out at least 3 generations of developers ;-/ > > Well, I'm an optimist -- and recently at least you and Ned and Russel > Owen have bee known to contribute. I'll provide mental support at the least, and hope to do more than that but don't know if I can do that time-wise. > >>> By the way, the other goal is to build scripts that do the builds the >>> way we need for various libs, packages, etc, so that it's easy to do >>> it all when new builds are required... >>> (maybe use gattai? -- http://sourceforge.net/projects/gattai/) >> >> I haven't used gattai before, but at least it is Python code. Building tools for this from scratch would also not be very hard, I already done so a number of times (such as the build-installer.py script in the CPython repository). > > yup -- me too, though I find myself wanting to add various make-like > features, and it dawns on me that I am re-inventing the wheel! So I > want to give Gattai a shot. Also Kevin is likely to be helpful. > >> The hard part should be setting up the build infrastructure and build scripts, once couple of relatively hard packages like PIL or wx have been processed adding more packages and new versions of packages should be easy. > > Exactly. But I don't know about wx -- that is a bear, and Robin's been > doing a fine job! If wx is hard to package it would be a good stress test of the tools, even if you'd end up not distributing the binaries :-) Ronald From python at samueljohn.de Thu May 23 09:45:14 2013 From: python at samueljohn.de (Samuel John) Date: Thu, 23 May 2013 09:45:14 +0200 Subject: [Pythonmac-SIG] Advice wanted on dependency building... In-Reply-To: <8F3EF2BE-EC8F-4EEF-B4D4-CDC1A2343706@mac.com> References: <8F3EF2BE-EC8F-4EEF-B4D4-CDC1A2343706@mac.com> Message-ID: Hi, I am from the homebrew team and passionate python lover. I can almost feel your pain :-) Some things install nice with pip, but others don't. That is why I started to maintain a separate "tap" for additional homebrew python formulae like pillow, numpy, scipy, matplotlib, pygame ... (one can get these with `brew tap samueljohn/python` but in the future I want to move them to homebrew/science or so). These formulae re-use and depend on other software built with homebrew (for example suite-sparse from homebrew/science, libpng). See https://github.com/samueljohn/homebrew-python if you like. With our recent kickstarter supported Mac Minis, we plan to build and provide binary "bottles" for all our packages. Perhaps that is a good starting point? Basically one could make an installer that takes one or more bottles and installes them. Perhaps even automate to create these installers. Perhaps it's possible to transform our bottles into the wheel format (I have not looked into that). Homebrew works bests if installed at `/usr/local` because of the paths to other libs. Often rpath is enough to change that but some software has other means to "remember" and hard-code paths, so in general, we build the bottles in /usr/local and deploy them there, too. I'd love to team up and join forces. I am currently making Python 2.x and 3.x support in homebrew possible and simplifying how to install python software that provides a setup.py. bests, Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.barker at noaa.gov Thu May 23 20:00:02 2013 From: chris.barker at noaa.gov (Chris Barker - NOAA Federal) Date: Thu, 23 May 2013 11:00:02 -0700 Subject: [Pythonmac-SIG] Advice wanted on dependency building... In-Reply-To: References: <8F3EF2BE-EC8F-4EEF-B4D4-CDC1A2343706@mac.com> Message-ID: On Thu, May 23, 2013 at 12:45 AM, Samuel John wrote: > I am from the homebrew team and passionate python lover. I can almost feel > your pain :-) Thanks for joining the discussion -- really great to have a homebrew-familiar person to discuss with. However, and please to correct me if I'm wrong, but my understanding of the goal of homebrew (and macports, and fink [anyone still use fink?] ) is to make it easy to build and run stuff on your system, and indeed, in a way that is optimized for your system (macports, at least has a bunch of use flags you can set that will customize the build the way you like it). On the other hand, what I'm talking about here is supporting people that want to: Distribute binary packages that support: - installing on older OS versions (and maybe different architectures) machines than the developer is running. - using those packages with Py2app, to distribute apps that will run on older machines and OSs. I _think_ that homebrew's goals don't support that. I know homebrew supports an option to build "universal" (i386+x86_64) binaries, but: a) not all formulae support that -- in general, it's not well tested b) I don't think it will build with an older sdk, which you'd need to support the above. In fact, on my machine (64 bit, OS-X 10.7), I'm sort-of-running homebrew, but it only partially works because I've got XCode 3 installed -- and it keeps telling me I should upgrade. I haven't upgraded XCode, because I haven't figured out how to get XCode 4 to build the binaries I need (Or needed, it may be the PPC support that I've lost, and I guess I can dump that now...) Anyway, if homebrew could support the goals above, it may be a good way to go to solve the problems at hand. > Some things install nice with pip, but others don't. That is why I started > to maintain a separate "tap" for additional homebrew python formulae ... > These formulae re-use and depend on other software > built with homebrew (for example suite-sparse from homebrew/science, > libpng). > See https://github.com/samueljohn/homebrew-python if you like. cool -- very nice! > With our recent kickstarter supported Mac Minis, we plan to build and > provide binary "bottles" for all our packages. > Perhaps that is a good starting point? If those binary bottles support older OS versions (more or less, the oldest one that Apple is currently supporting -- I think that's 10.6 now), then yes, that could be a way to go. > Homebrew works bests if installed at `/usr/local` because of the paths to > other libs. yup -- I can imagine! And I'm fine with homebrew in usr/local, but I don't want something someone installs specifically for MacPython (outside of homebrew) stomping on it. > I am currently making Python 2.x and 3.x support in homebrew possible and > simplifying how to install python software that provides a setup.py. Question: Does homebrew put Python in usr/local? and give you a regular old unix-style install? Or do you get a "proper" Mac Framework install (wherever it puts it). I guess the key question is can you use it to develop proper desktop apps, and use py2app to make re-distributable app bundles? If so, and if it can support older machines with binaries, then maybe we could build MacPyton on top of it (or with it). But the key issue is if the goals of the homebrew project align with the goals I outlined above. Thoughts? -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From chris.barker at noaa.gov Thu May 23 19:35:14 2013 From: chris.barker at noaa.gov (Chris Barker - NOAA Federal) Date: Thu, 23 May 2013 10:35:14 -0700 Subject: [Pythonmac-SIG] [OT] advice on distributing for different OSs In-Reply-To: <7C930016-B201-41B4-9A08-8474CBE052A7@avatar.com.au> References: <7C930016-B201-41B4-9A08-8474CBE052A7@avatar.com.au> Message-ID: On Wed, May 22, 2013 at 11:49 PM, DavidWorrall wrote: > I've been developing in Python on Mac's since b4 OSX and I have to give a > workshop on the other side of the world in a (networked) non-OSX university > lab (Windows, I think). > > Now I know dependencies are one of python's strengths, no, it's not! I think dependencies are still kind of a nightmare with Python. pip and pypi do a pretty good job with pure-python packages, and an OK job with compiled-with-no-other-dependencies packages, but packages that have other dependencies are a pain - python provides no support whatsoever for that. > it got me to wondering if there are some angels out there > who support a downloadable collection of useful tools for various versions > that python on OSX, Linux and Windows OSs that members of this group would > recommend. Christoph Golke is one such angel for Windows, and Pyton(x,y) and PyWin (or something like that) are other all-in-0ne free distributions for Windows. Nothing that I know of (free and open) for the Mac -- hence my note -- maybe you'd like to help build one? > 2.7.x seems the most viable Python. My orientation is scientific with an > added emphasis on sound. > > I've looked at Enthought's offerings, for example. They seem pretty slick, > but don't know what corporate "dependencies" I might be inadvertently > "buying" into in adopting their builds. Enthought or Anaconda are the two commercial offerings I know of. And they are pretty good options, actually. I don't know the downsides. For y part, I dn't use them, but maybe I should. A few years back I tried Enthought when I needed to get some Windows boxes up and running quickly. IN that case, I found that EPD installs and is configured for MinGW, rather than the MS compiler -- and, it turns out, didn't work for compiling some custom extensions I needed. Honestly, when it barfed on me, I dropped it and moved on, without hardly any debugging time -- so it may have been a trivail fix. So the only issue I know if is that EPD used MinGW, rather than the MS compiler -- don't know if that's a problem, though. I suspect Anaconda os the same. > Any thoughts/recommendations- or suggestions of a more appropriate forum to > ask this - would be much appreciated. with your science focus, you may try the scipy list, or the scientific python LinedIn discussion group. But for Mac-focuses questions, this is a good one. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From matthias.baas at gmail.com Thu May 23 23:29:05 2013 From: matthias.baas at gmail.com (Matthias Baas) Date: Thu, 23 May 2013 22:29:05 +0100 Subject: [Pythonmac-SIG] Advice wanted on dependency building... In-Reply-To: References: Message-ID: <519E8A21.4080703@gmail.com> On 22.05.13 18:30, Chris Barker - NOAA Federal wrote: > Users also fall into two categories: > > 1) Folks that do Python development on OS-X much like Linux, etc -- > these folks are likely to use macports or homebrew, or are used to the > .configure, make, make install dance. We don't need to do anything to > support these folks -- "pip install" generally works for them. > > 2) folks that want to use a Mac like a Mac, and people that develop > for those folks -- these people need binary installers, and may want > to be able to use and deploy either packages or applications (Py2app) > that will run on systems older than the one developed on, or want > universal builds, or ??? > - These are the folks I'd like to support, but I'm still unsure as > to how best to do that. I agree, it would be a nice thing to have such a binary repository again. Thanks for trying to tackle this! >From a user's point of view, I find that Windows installers as generated by bdist_wininst still provide the nicest user experience with OSX packages being a close second. From your user category description it also sounds like this would be the type of user experience that would be suitable for type 2 users. You even mention pip as a solution to type 1 users and again, I do agree with this. That's why I find it a bit surprising that in the remainder of this thread, a lot of the discussion is about pip and virtualenv (as far as I can tell, all the solutions that were mentioned were command line solutions), even though you actually didn't want to target this category of users. > How should the dependencies be distributed? > > 1) They should be built to match the Python binary being targeted > (honestly, I think that's now only the Intel 32-64 bit ones -- PPC > machines, and pre 10.6, are getting really rare...) Sounds all right to me (it wasn't actually too long ago that I was still on 10.4 and I can confirm, it's no fun anymore :) ) > 2) Static or dynamic? > > IIUC, most successful binary packages for the Mac have relied on > statically linking the dependencies -- this works, and is pretty > robust. However, it can be kind of a pain to do (though I've finally > figure how to do it more reliably!). Also, it seems like a waste to me > for packages that use common dependencies -- how many copies of libpng > do I really want linked into my single instance of Python at run time? Personally, that doesn't really bother me too much, at least not in the context of Python development. It's not that all the packages I'm using are linked against libpng and that I need all those packages in the same program. > But if dynamic, where do you put them? We'll still want to ship them > with the binary, so people have a one-click install. If static linking is not an option and you need to ship a dynamic library, I would favor a self-contained solution where the dynamic library is just stored in the same directory where the Python extensions are that are actually using the library. It seems that with the @loader_path mechanism you were mentioning in another email, it shouldn't be a problem to implement this. I wouldn't bother trying to share libraries across packages (or Python installations) for the following reasons: - By moving the dynamic library outside the "domain" of the package, it has become an external dependency and the package provider cannot guarantee anymore that the package will really work on the user's machine throughout its lifetime. Essentially, the responsibility of ensuring compatibility has been moved from the package provider to the user. - A build of a library may differ from another build of the same library, even when they are built from the same version of the source files. This is because it's not uncommon that libraries can be configured at compile time (e.g. wide character support, single-threaded vs multi-threaded, float vs double as fundamental number type, optional support for any SSE variant, AVX, OpenGL, OpenCL, networking, internationalization, etc.). So it could happen that I install package A and everything is fine until at some point I install package B which overwrites a shared dynamic library and suddenly package A doesn't work anymore. - Uninstalling is more straightforward as I can just remove the main directory where the package is in and I don't have to worry about orphan libs in some other directories of which I don't even know why they are on my system. - If the entire package is self-contained, moving the package or changing the install location at install-time is not an issue anymore. - It makes life easier for the package provider as well as you don't have to worry how to manage shared libraries. Cheers, - Matthias - From chris.barker at noaa.gov Fri May 24 00:41:15 2013 From: chris.barker at noaa.gov (Chris Barker - NOAA Federal) Date: Thu, 23 May 2013 15:41:15 -0700 Subject: [Pythonmac-SIG] Advice wanted on dependency building... In-Reply-To: <519E8A21.4080703@gmail.com> References: <519E8A21.4080703@gmail.com> Message-ID: On Thu, May 23, 2013 at 2:29 PM, Matthias Baas wrote: > From a user's point of view, I find that Windows installers as generated > by bdist_wininst still provide the nicest user experience with OSX > packages being a close second. second? Aren't they essentially the same experience? But anyway.. > You even mention pip as a solution to type 1 users and again, I do agree > with this. That's why I find it a bit surprising that in the remainder > of this thread, a lot of the discussion is about pip and virtualenv (as > far as I can tell, all the solutions that were mentioned were command > line solutions), even though you actually didn't want to target this > category of users. I don't agree -- I'm not opposed to requiring a command-line command or two -- really you can't get far as any kind of programmer if you can't type: pip install the_package_I_want. Plus, all sorts of sources will tell people that that's how you install a package - it would be great if it "just worked" on the Mac, even for complex packages That's a whole lot less than expecting people to do the whole ".configure; make; make install" dance. And if someone wants to make a point_and_click wrapper around pip -- great! The advantage of pip and friends is that it handles dependencies -- simple binary installer don't do that for you. Also virtualenv is not just an advanced-user problem. It is THE solution to the python equivalent of DLL Hell. I'm teaching an intro to Python class, and another instructor (who teaches the web development art) considers it such an essential tool that we are considering introducing it very early in the class. I've always thought that teaching newbies a simpler way to do things was a bad approach, if it's not the way they should be doing it for "real work". And if we don't support virtual env, then someone gets rolling eveything is fine and dandy, then it comes time to deploy, and the need a virtualenv to keep their dev environment and deployment environment separate, and WHAM -- they'g got to figure out a whole new, and much more difficult way to install packages. If we can make it easy for newbies, but still be usuable for proper work, we're much better off. Finally -- we can have one way that packages are built and installed, and more than one way to distribute and install them -- i.e. a mpkg, and also a wheel, when that is properly supported. >> 2) Static or dynamic? > Also, it seems like a waste to me >> for packages that use common dependencies -- how many copies of libpng >> do I really want linked into my single instance of Python at run time? > > Personally, that doesn't really bother me too much, at least not in the > context of Python development. It's not that all the packages I'm using > are linked against libpng and that I need all those packages in the same > program. I could easily have three copies of libpng at once: wxPython, matplotlib, PIL. maybe more! But maybe I don't care -- memory is pretty cheap these days... > If static linking is not an option and you need to ship a dynamic > library, I would favor a self-contained solution where the dynamic > library is just stored in the same directory where the Python extensions > are that are actually using the library. It seems that with the > @loader_path mechanism you were mentioning in another email, it > shouldn't be a problem to implement this. I think that's the way to go if what we really want is static linking, but can't do that for some reason with a particular lib...but it otherwise kills all the advantages of a dynamic lib, so what's the point? > I wouldn't bother trying to share libraries across packages (or Python > installations) for the following reasons: > > - By moving the dynamic library outside the "domain" of the package, it > has become an external dependency and the package provider cannot > guarantee anymore that the package will really work on the user's > machine throughout its lifetime. Essentially, the responsibility of > ensuring compatibility has been moved from the package provider to the user. not quite if the package provider is also the dependency provider, but you are right, it's harder to control. > So it could happen that I install package A > and everything is fine until at some point I install package B which > overwrites a shared dynamic library and suddenly package A doesn't work > anymore. That's exactly why we really don't want to use a standard system location, like /usr/local... However, my vision is that building these things will be something of a coordinated effort, so everything dumped in to our lib location would have been designed to work together -- maybe that's a fantasy. As I think about it, I guess I'm proposing something like EPD or Anaconda, but free and community-developed. Or even Chris Gohlke's repository of Windows binaries -- they are all built to work together. > - Uninstalling is more straightforward as I can just remove the main > directory where the package is in and I don't have to worry about orphan > libs in some other directories of which I don't even know why they are > on my system. yup - that is an issue -- though I think we're talking putting them in the main Python install dir, so at least if you wipe out that version of Python, you won't have cruft left.... And Ronald suggested a way to use pip to track that and allow uninstall to work. > - It makes life easier for the package provider as well as you don't > have to worry how to manage shared libraries. yup -- static libs are a lot easier! I think my plan is now: The step to building and distributing a package: 1) build the deps 2) build the package 3) build the package installer 4) put the package installer up somewhere people can find it. Im going to work on a system for (1) and (2) first -- still not sure about the dynamic linking part.... For now, probably use bdist_mpkg for (3) -- when wheels are generally supported, maybe use them. If/when I get a few packages built, I'll think about where to put them up. Anyone have an idea for a host? I understand gitHub no longer really support binary distribution... -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From chris.barker at noaa.gov Fri May 24 01:28:02 2013 From: chris.barker at noaa.gov (Chris Barker - NOAA Federal) Date: Thu, 23 May 2013 16:28:02 -0700 Subject: [Pythonmac-SIG] Advice wanted on dependency building... In-Reply-To: <8F3EF2BE-EC8F-4EEF-B4D4-CDC1A2343706@mac.com> References: <8F3EF2BE-EC8F-4EEF-B4D4-CDC1A2343706@mac.com> Message-ID: On Wed, May 22, 2013 at 11:53 PM, Ronald Oussoren wrote: >> I'm using the >> system zlib -- is that a bad idea? Should I build it too, to make sure >> it matches the rest of it? >> >> (I do want the binaries to run anywhere the binary Python I'm using runs) > > It depends on the library. OK -- it would be nice to have rule to follow, but I guess that decision should be made for each particular lib. > I agree w.r.t. homebrew and macports, but it would be nice if 'pip install' would work with your system with minimal changes to the pip configuration (e.g. "just add ... to your piprc and then 'pip install foo' will install a binary from the repo instead of building the binaries itself"). yes -- it sure would -- though this is enough to do without trying to hack on pip as well.... >> Yeah, and he never gave anyone else permission to push to it... > > I wouldn't have done that either until the someone else has a proven trackrecord (both in providing usable binaries and in being known in the community). well, when I say anyone else, I mean anyone else -- I, and a few others regularly contributed, but it involved sending it to him, and hoping he'd find the time to put it up...So if I do this, I'd like to have at least the option of a handful of folks contributing directly. >> But if we put the shared libs in amore central location, then all your >> virtual-ens could use the same ones, yes? > > Yes. It would make it harder to switch library versions, but not by much. hmm -- this is getting tricky for me to wrap my head around -- could we make it so a pip install inside a virtual env would install a dependency in the main python? Or would you have people install the libs outside of the virtualenv first, if they didn't want multiple copies ? > Uninstall can be a problem with that, you'd have to refcount installed files to ensure that libraries are only removed when the last user is uninstalled. I don't know if the installation format used by pip supports having two packages that install the same file. and I don't want to write that code anyway ;-) > This can be worked around with fake PyPI packages that only install the shared libraries and have the real packages depend on that (that is a "macbins-libpng" package with libpng.dylib and have the Imaging package depend on that). I like that idea -- and It looks like that's how Anaconda deals with it. > /Library can be used, we'd just have to pick a name that Apple is unlikely to use. I think it should go in /Library/Frameworks/Python somewhere, helps the uninstall issue -- if folks clear that out, they won't have anything left behind. > I'm probably atypical, but my main account doesn't have admin privileges. It would suck if I'd have to use sudo to install. How do you install the python from Python.org? I"m just thinking we should match that... > The @loader_path option you mentioned in a followup e-mail could help there. That way the shared libraries can be installed in a fixed location relative to sys.prefix, while still supporting virtualenvs. You wouldn't be able to share shared libraries between python versions or virtualenvs, but that's not really a problem (disk space is cheap). That may be the way to go. >> Any idea what the time scale is on this? > > Before Python 3.4 is out, which means sometime this summer. OK -- I figure I"ll wait until it's there, and then try it out. >> Have the pip folks made any commitment at all to supporting binary >> installs? That's a big missing feature. > > Yes, through wheels. The development branch in pips repo () contains support for wheels (both creating and installing), although AFAIK installation of pips requires a command-line argument at the moment because wheel support is experimental at this point. fair enough -- have you looked into the universal binary issue at all? easy_install was always getting confused by universal binaries... > I'll provide mental support at the least, and hope to do more than that but don't know if I can do that time-wise. You've provided an enormous amount already! > If wx is hard to package it would be a good stress test of the tools, even if you'd end up not distributing the binaries :-) yup -- but I'm still not sure if I want to deal with it! -- we'll see. Maybe Robin would be interested in supporting this shared lib system if we do get to that. I'm thinking of setting up a gitHub project for this..I'll let you all know if/when I do. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From chris.barker at noaa.gov Fri May 24 01:41:35 2013 From: chris.barker at noaa.gov (Chris Barker - NOAA Federal) Date: Thu, 23 May 2013 16:41:35 -0700 Subject: [Pythonmac-SIG] Static Linking... Message-ID: As a side note to the main thread about dependencies: How can I static link? I"ve struggled for literally years to get gcc to statically link, but it tries really hard to dynamically link instead. I have written way too many scripts that move or re-name dynamic libs temporarily while building, then put them back after. Then a colleague of mine showed me the really neat trick -- pass the paths to the libs themselves through to gcc with "extra_objects" keyword in the Extension object, like so: extra_objects = ["libhdf5.a", "libhdf5_hl.a", "libnetcdf.a"] extensions = [Extension("netCDF4", sources, libraries=libs, include_dirs=inc_dirs, extra_objects=extra_objects, )] very nifty -- works like a charm. However, when I do this, I had to re-write part of the setup.py -- actually, making it far more simple -- in this case, there was a lot of machinations finding the libs... But Ideally, I"d ;like to build a semi-arbitrary extension with static linking while using the existing setup.py. Is there a way to minkey-path the setup, so I can use the existing one, but re-shuffle it some in place before the actual build occurs? -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From ronaldoussoren at mac.com Fri May 24 09:26:15 2013 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Fri, 24 May 2013 09:26:15 +0200 Subject: [Pythonmac-SIG] Static Linking... In-Reply-To: References: Message-ID: <8821B840-5AF5-4128-B180-4E6FF24D7F86@mac.com> On 24 May, 2013, at 1:41, Chris Barker - NOAA Federal wrote: > As a side note to the main thread about dependencies: > > How can I static link? It is a lot easier when there is only a static archive in a directory and no dylib (that is build libpng with --enable-static --disable-shared). In recent version of the devtools that should be good enough. When building with older Xcodes (before 4.0) you have to add '-Wl,-search_paths_first' to the link flags to ensure that the .a file will be used even when there is a .dylib futher on in the search path used by the linker (this must be used when static linking ncurses because there is a dylib for ncurses in the default search path). I haven't found a way yet to make the linker prefer static libraries ("cc -static" does something different than it does on Linux and cannot be used to build normal binaries), at least not beyond the trick you mention later on. > > I"ve struggled for literally years to get gcc to statically link, but > it tries really hard to dynamically link instead. I have written way > too many scripts that move or re-name dynamic libs temporarily while > building, then put them back after. > > Then a colleague of mine showed me the really neat trick -- pass the > paths to the libs themselves through to gcc with "extra_objects" > keyword in the Extension object, like so: > > extra_objects = ["libhdf5.a", "libhdf5_hl.a", "libnetcdf.a"] > > extensions = [Extension("netCDF4", > sources, > libraries=libs, > include_dirs=inc_dirs, > extra_objects=extra_objects, > )] > > very nifty -- works like a charm. > > However, when I do this, I had to re-write part of the setup.py -- > actually, making it far more simple -- in this case, there was a lot > of machinations finding the libs... > > But Ideally, I"d ;like to build a semi-arbitrary extension with static > linking while using the existing setup.py. Is there a way to > minkey-path the setup, so I can use the existing one, but re-shuffle > it some in place before the actual build occurs? Not that I know, beyond assuring that static libraries are in a different directory than dylibs. That's not very hard to arrange, but it annoying work that shouldn't be necessary... Ronald From matthias.baas at gmail.com Fri May 24 15:35:19 2013 From: matthias.baas at gmail.com (Matthias Baas) Date: Fri, 24 May 2013 14:35:19 +0100 Subject: [Pythonmac-SIG] Advice wanted on dependency building... In-Reply-To: References: <519E8A21.4080703@gmail.com> Message-ID: On Thu, May 23, 2013 at 11:41 PM, Chris Barker - NOAA Federal < chris.barker at noaa.gov> wrote: > On Thu, May 23, 2013 at 2:29 PM, Matthias Baas > wrote: > > > From a user's point of view, I find that Windows installers as generated > > by bdist_wininst still provide the nicest user experience with OSX > > packages being a close second. > > second? Aren't they essentially the same experience? But anyway.. > I may be wrong, but I thought pure Python packages that are distributed as an OSX package are still targeted at one particular version of Python. On Windows, the installer would provide a list of all the installed Python versions and ask for which version you want to install the package. Another difference is that on Windows, I can uninstall the package again. > > You even mention pip as a solution to type 1 users and again, I do agree > > with this. That's why I find it a bit surprising that in the remainder > > of this thread, a lot of the discussion is about pip and virtualenv (as > > far as I can tell, all the solutions that were mentioned were command > > line solutions), even though you actually didn't want to target this > > category of users. > > I don't agree -- I'm not opposed to requiring a command-line command > or two -- really you can't get far as any kind of programmer if you > can't type: > I see. I have seen people that only used Python by launching IDLE and doing everything from there, they never got into contact with a terminal window. Telling them to first install pip, then install some other packages, would complicate things for them quite a bit. But I'm not saying we have to support those people, it was just that your categorization of users reminded me of those people. If pip is more and more becoming the standard way of installing things, then, of course, it definitely makes sense to follow its way of handling packages. I suppose sooner or later, a GUI frontend for it will pop up so that it becomes easier to install packages. > The advantage of pip and friends is that it handles dependencies -- > simple binary installer don't do that for you. > I'm aware of that. From my personal experience, this has never been an issue for me though. I'm only using a handful of third-party packages on a more or less regular basis (such as PyQt, Sphinx, numpy, PIL, PyOpenGL, pygame) and only occasionally install some other packages to try stuff out, so for me, there hasn't really been a compelling reason why I should use pip instead. (Maybe it's also that it reminds me too much to systems like MacPorts and I have just seen MacPort fail too many times to put much trust in such a system. But then, this always had to do with building packages locally, whereas you are planning on providing binaries, so this won't be an issue. Sorry for my rant!) > I think my plan is now: > > The step to building and distributing a package: > > 1) build the deps > 2) build the package > 3) build the package installer > 4) put the package installer up somewhere people can find it. > > Im going to work on a system for (1) and (2) first -- still not sure > about the dynamic linking part.... > > For now, probably use bdist_mpkg for (3) -- when wheels are generally > supported, maybe use them. > > If/when I get a few packages built, I'll think about where to put them up. > > Anyone have an idea for a host? I understand gitHub no longer really > support binary distribution... > Sounds all good and promising! As for web space, a lot of people don't seem to like SourceForge anymore, but at least they do provide some web space and infrastructure where you could put your stuff. Cheers, - Matthias - -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.barker at noaa.gov Fri May 24 17:28:53 2013 From: chris.barker at noaa.gov (Chris Barker - NOAA Federal) Date: Fri, 24 May 2013 08:28:53 -0700 Subject: [Pythonmac-SIG] [OT] advice on distributing for different OSs In-Reply-To: <2B3798FE-0538-4811-BDE5-5F9C071B0CD1@avatar.com.au> References: <7C930016-B201-41B4-9A08-8474CBE052A7@avatar.com.au> <2B3798FE-0538-4811-BDE5-5F9C071B0CD1@avatar.com.au> Message-ID: On Fri, May 24, 2013 at 2:10 AM, DavidWorrall wrote: > maybe you'd like to help build one? > > mmm tempting. I'm moving continents ATM so it will have to wait a bit. Who knows how much time I'll find for this, but my goal is to set up a system (probably a gitHub project), and then others will be able to contribute build scripts for particular packages. I'll certainly annouce that effort when there is something to see... If I can get this in place, I'm hoping that it will, in fact, be easier to build new package by using this system that doing it from scratch by hand, and once you've done it, why not contribute it back? -Chris > Enthought's offerings, for example. They seem pretty slick, > When one installs their Canopy on the Mac, for example, they impose > themselves on the Terminal prompt: > > (Canopy 32bit) drwIntel-6:~ drw$ you're kidding! Their installer messes with the prompt settings in .bash_profile or somewhere? that really is too much! (I agree it's not fatal, but WTF?) > It's got the feel like Apple's own approach: take complete control of > customer's computer/phone/etc > Perhaps after years of this I'm ready to move to Linux. I know the feeling... -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From ronaldoussoren at mac.com Mon May 27 10:23:06 2013 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Mon, 27 May 2013 10:23:06 +0200 Subject: [Pythonmac-SIG] [OT] advice on distributing for different OSs In-Reply-To: References: <7C930016-B201-41B4-9A08-8474CBE052A7@avatar.com.au> Message-ID: On 23 May, 2013, at 19:35, Chris Barker - NOAA Federal wrote: > On Wed, May 22, 2013 at 11:49 PM, DavidWorrall wrote: > >> I've been developing in Python on Mac's since b4 OSX and I have to give a >> workshop on the other side of the world in a (networked) non-OSX university >> lab (Windows, I think). >> >> Now I know dependencies are one of python's strengths, > > no, it's not! I think dependencies are still kind of a nightmare with > Python. pip and pypi do a pretty good job with pure-python packages, > and an OK job with compiled-with-no-other-dependencies packages, but > packages that have other dependencies are a pain - python provides no > support whatsoever for that. It's unlikely that support for external dependencies will improve a lot in the near future unless someone does the work and provides a clear and usable specification, preferably with an implementation. A major problem for this is that external dependencies aren't much of a problem on Linux, most OSS C/C++ libraries are available from the repositories of the major Linux distribution (or add-on repositories). Because of this a major group of Python users doesn't notice the problem, and hence is less likely to work on a solution. IMHO the best way forward is to build a solution for OSX, and only then try to generalize that with support for Windows and Linux. BTW. There is a tool that does have decent support for external dependencies: buildout. This is used by a number of organizations, such as the Zope ecosphere, to build and deploy complex applications and buildout projects can specify the entire build, including stuff like database servers. That said, I've never used buildout in anger. I have tried to debug a py2app problem for which someone provided a buildout configuration but ended up reproducing the problem without buildout because I couldn't get a working setup with buildout (without reading the documentation). Ronald From cohar at conncoll.edu Mon May 27 17:26:04 2013 From: cohar at conncoll.edu (Charles Hartman) Date: Mon, 27 May 2013 11:26:04 -0400 Subject: [Pythonmac-SIG] app won't quit? Message-ID: I'm coming back to all of this after years away, so I'm sure I'm missing something simple. I've brought an old app into the current world: Python 2.7.5 OS 10.8.3 wxPython 2.9.4.0 py2app 0.7.3 and I rebuilt my setup.py to current specifications. The resulting app works fine (though it's enormous!), but it won't respond to a Quit command (keyboard or menu). The menu-bar header (with my app's name) flashes, but nothing else happens. Thanks for any help. -- Charles O. Hartman Poet in Residence Lucy Marsh Haskell '19 Professor of Literatures in English oak.conncoll.edu/cohar -------------- next part -------------- An HTML attachment was scrubbed... URL: From ronaldoussoren at mac.com Mon May 27 18:38:46 2013 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Mon, 27 May 2013 18:38:46 +0200 Subject: [Pythonmac-SIG] app won't quit? In-Reply-To: References: Message-ID: <2DBC54B1-DB85-4045-B665-C93EF82FB8FC@mac.com> On 27 May, 2013, at 17:26, Charles Hartman wrote: > I'm coming back to all of this after years away, so I'm sure I'm missing something simple. I've brought an old app into the current world: > > Python 2.7.5 > OS 10.8.3 > wxPython 2.9.4.0 > py2app 0.7.3 > > and I rebuilt my setup.py to current specifications. The resulting app works fine (though it's enormous!), but it won't respond to a Quit command (keyboard or menu). The menu-bar header (with my app's name) flashes, but nothing else happens. This might be caused by an unhandled exception. Have you tried running the app from the command-line (yourapp.app/Contents/MacOS/yourapp)? Ronald > > Thanks for any help. > > > -- > > Charles O. Hartman > Poet in Residence > Lucy Marsh Haskell '19 Professor of Literatures in English > oak.conncoll.edu/cohar > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG From kw at codebykevin.com Mon May 27 18:52:17 2013 From: kw at codebykevin.com (Kevin Walzer) Date: Mon, 27 May 2013 12:52:17 -0400 Subject: [Pythonmac-SIG] app won't quit? In-Reply-To: References: Message-ID: I've observed this with the wxPy demo...may be a ex bug. Sent from my iPhone On May 27, 2013, at 11:26 AM, Charles Hartman wrote: > I'm coming back to all of this after years away, so I'm sure I'm missing something simple. I've brought an old app into the current world: > > Python 2.7.5 > OS 10.8.3 > wxPython 2.9.4.0 > py2app 0.7.3 > > and I rebuilt my setup.py to current specifications. The resulting app works fine (though it's enormous!), but it won't respond to a Quit command (keyboard or menu). The menu-bar header (with my app's name) flashes, but nothing else happens. > > Thanks for any help. > > > -- > > Charles O. Hartman > Poet in Residence > Lucy Marsh Haskell '19 Professor of Literatures in English > oak.conncoll.edu/cohar > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG -------------- next part -------------- An HTML attachment was scrubbed... URL: From kw at codebykevin.com Mon May 27 18:52:52 2013 From: kw at codebykevin.com (Kevin Walzer) Date: Mon, 27 May 2013 12:52:52 -0400 Subject: [Pythonmac-SIG] app won't quit? In-Reply-To: References: Message-ID: <7944EC1A-E4D8-4DA0-B6B4-94CFC55D4790@codebykevin.com> Wxpython bug, that is. Sent from my iPhone On May 27, 2013, at 11:26 AM, Charles Hartman wrote: > I'm coming back to all of this after years away, so I'm sure I'm missing something simple. I've brought an old app into the current world: > > Python 2.7.5 > OS 10.8.3 > wxPython 2.9.4.0 > py2app 0.7.3 > > and I rebuilt my setup.py to current specifications. The resulting app works fine (though it's enormous!), but it won't respond to a Quit command (keyboard or menu). The menu-bar header (with my app's name) flashes, but nothing else happens. > > Thanks for any help. > > > -- > > Charles O. Hartman > Poet in Residence > Lucy Marsh Haskell '19 Professor of Literatures in English > oak.conncoll.edu/cohar > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG -------------- next part -------------- An HTML attachment was scrubbed... URL: From cohar at conncoll.edu Mon May 27 19:22:02 2013 From: cohar at conncoll.edu (Charles Hartman) Date: Mon, 27 May 2013 13:22:02 -0400 Subject: [Pythonmac-SIG] app won't quit? In-Reply-To: <2DBC54B1-DB85-4045-B665-C93EF82FB8FC@mac.com> References: <2DBC54B1-DB85-4045-B665-C93EF82FB8FC@mac.com> Message-ID: Running it from the command line doesn't change anything; nothing shows up in Terminal except a message saying that PySimpleApp is now deprecated in wxPython. But when I changed to the standard App instead, nothing changed. Nothing shows up in Console either. Following Kevin's suggestion, I'm posting the problem on the wxPython list. On Mon, May 27, 2013 at 12:38 PM, Ronald Oussoren wrote: > > On 27 May, 2013, at 17:26, Charles Hartman wrote: > > > I'm coming back to all of this after years away, so I'm sure I'm missing > something simple. I've brought an old app into the current world: > > > > Python 2.7.5 > > OS 10.8.3 > > wxPython 2.9.4.0 > > py2app 0.7.3 > > > > and I rebuilt my setup.py to current specifications. The resulting app > works fine (though it's enormous!), but it won't respond to a Quit command > (keyboard or menu). The menu-bar header (with my app's name) flashes, but > nothing else happens. > > This might be caused by an unhandled exception. Have you tried running the > app from the command-line (yourapp.app/Contents/MacOS/yourapp)? > > Ronald > > > > Thanks for any help. > > > > > > -- > > > > Charles O. Hartman > > Poet in Residence > > Lucy Marsh Haskell '19 Professor of Literatures in English > > oak.conncoll.edu/cohar > > _______________________________________________ > > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > > http://mail.python.org/mailman/listinfo/pythonmac-sig > > unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG > > -- Charles O. Hartman Poet in Residence Lucy Marsh Haskell '19 Professor of Literatures in English oak.conncoll.edu/cohar -------------- next part -------------- An HTML attachment was scrubbed... URL: From werner.bruhin at free.fr Mon May 27 19:39:12 2013 From: werner.bruhin at free.fr (Werner F. Bruhin) Date: Mon, 27 May 2013 19:39:12 +0200 Subject: [Pythonmac-SIG] app won't quit? In-Reply-To: References: <2DBC54B1-DB85-4045-B665-C93EF82FB8FC@mac.com> Message-ID: <51A39A40.3090704@free.fr> Hi, On 27/05/2013 19:22, Charles Hartman wrote: > Running it from the command line doesn't change anything; nothing > shows up in Terminal except a message saying that PySimpleApp is now > deprecated in wxPython. But when I changed to the standard App > instead, nothing changed. Nothing shows up in Console either. > > Following Kevin's suggestion, I'm posting the problem on the wxPython > list. Could it be that you have any top level windows still open, or a timer not stopped or a tray icon which is still around? Werner From cohar at conncoll.edu Mon May 27 19:54:05 2013 From: cohar at conncoll.edu (Charles Hartman) Date: Mon, 27 May 2013 13:54:05 -0400 Subject: [Pythonmac-SIG] app won't quit? In-Reply-To: <51A39A40.3090704@free.fr> References: <2DBC54B1-DB85-4045-B665-C93EF82FB8FC@mac.com> <51A39A40.3090704@free.fr> Message-ID: You have pointed me to something bizarre. This is on a Mac. On Mac, though quitting the app closes all top-level windows, closing all top-level windos doesn't quit the app. So your question looks irrelevant?but it isn't! If I close my app's only window, I see that the app has quit! Have I somehow discovered the secret to making a Mac behave like a Windows machine? (Am I happy?) On Mon, May 27, 2013 at 1:39 PM, Werner F. Bruhin wrote: > Hi, > > > On 27/05/2013 19:22, Charles Hartman wrote: > >> Running it from the command line doesn't change anything; nothing shows >> up in Terminal except a message saying that PySimpleApp is now deprecated >> in wxPython. But when I changed to the standard App instead, nothing >> changed. Nothing shows up in Console either. >> >> Following Kevin's suggestion, I'm posting the problem on the wxPython >> list. >> > Could it be that you have any top level windows still open, or a timer not > stopped or a tray icon which is still around? > > Werner > > ______________________________**_________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/**mailman/listinfo/pythonmac-sig > unsubscribe: http://mail.python.org/**mailman/options/Pythonmac-SIG > -- Charles O. Hartman Poet in Residence Lucy Marsh Haskell '19 Professor of Literatures in English oak.conncoll.edu/cohar -------------- next part -------------- An HTML attachment was scrubbed... URL: From poalman at gmail.com Tue May 28 13:34:54 2013 From: poalman at gmail.com (Paul Wiseman) Date: Tue, 28 May 2013 12:34:54 +0100 Subject: [Pythonmac-SIG] app won't quit? In-Reply-To: References: Message-ID: On 27 May 2013 16:26, Charles Hartman wrote: > I'm coming back to all of this after years away, so I'm sure I'm missing > something simple. I've brought an old app into the current world: > > Python 2.7.5 > OS 10.8.3 > wxPython 2.9.4.0 > py2app 0.7.3 > > and I rebuilt my setup.py to current specifications. The resulting app > works fine (though it's enormous!), but it won't respond to a Quit command > (keyboard or menu). The menu-bar header (with my app's name) flashes, but > nothing else happens. > > Thanks for any help. > > In wx the app will close if all top level frames are closed, so if some are left open it wont, did you override some close event handlers possibly by binding to EVT_CLOSE? Also the app will stay running as long as any non-daemon threads are running- are you using any threading in the app? > > -- > > Charles O. Hartman > Poet in Residence > Lucy Marsh Haskell '19 Professor of Literatures in English > oak.conncoll.edu/cohar > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cohar at conncoll.edu Tue May 28 13:43:03 2013 From: cohar at conncoll.edu (Charles Hartman) Date: Tue, 28 May 2013 07:43:03 -0400 Subject: [Pythonmac-SIG] app won't quit? In-Reply-To: References: Message-ID: Thanks, but no. My app never touches EV_CLOSE, and it doesn't do threading at all. On Tue, May 28, 2013 at 7:34 AM, Paul Wiseman wrote: > On 27 May 2013 16:26, Charles Hartman wrote: > >> I'm coming back to all of this after years away, so I'm sure I'm missing >> something simple. I've brought an old app into the current world: >> >> Python 2.7.5 >> OS 10.8.3 >> wxPython 2.9.4.0 >> py2app 0.7.3 >> >> and I rebuilt my setup.py to current specifications. The resulting app >> works fine (though it's enormous!), but it won't respond to a Quit command >> (keyboard or menu). The menu-bar header (with my app's name) flashes, but >> nothing else happens. >> >> Thanks for any help. >> >> > In wx the app will close if all top level frames are closed, so if some > are left open it wont, did you override some close event handlers possibly > by binding to EVT_CLOSE? > > Also the app will stay running as long as any non-daemon threads are > running- are you using any threading in the app? > > >> >> -- >> >> Charles O. Hartman >> Poet in Residence >> Lucy Marsh Haskell '19 Professor of Literatures in English >> oak.conncoll.edu/cohar >> >> >> _______________________________________________ >> Pythonmac-SIG maillist - Pythonmac-SIG at python.org >> http://mail.python.org/mailman/listinfo/pythonmac-sig >> unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG >> >> > -- Charles O. Hartman Poet in Residence Lucy Marsh Haskell '19 Professor of Literatures in English oak.conncoll.edu/cohar -------------- next part -------------- An HTML attachment was scrubbed... URL: From cohar at conncoll.edu Tue May 28 14:33:17 2013 From: cohar at conncoll.edu (Charles Hartman) Date: Tue, 28 May 2013 08:33:17 -0400 Subject: [Pythonmac-SIG] app won't quit? In-Reply-To: References: <2DBC54B1-DB85-4045-B665-C93EF82FB8FC@mac.com> <51A39A40.3090704@free.fr> Message-ID: When I updated my app, I switched from the deprecated wx.PySimpleApp, which had the right default behavior on Mac, to wx.App, which apparently doesn't. (The docs say "You should normally exit the main loop (and the application) by deleting the top window." What's "normal" for a Windows user would baffle my Mac users, and vice versa?but never mind.) I see I can call wxGetApp().ExitMainLoop. But in response to what? What is the event sent by the Mac keyboard or menu Quit command? Binding to wx.EVT_CLOSE doesn't seem to do anything. On Tue, May 28, 2013 at 1:07 AM, Chris Barker - NOAA Federal < chris.barker at noaa.gov> wrote: > On Mon, May 27, 2013 at 10:54 AM, Charles Hartman > wrote: > > You have pointed me to something bizarre. This is on a Mac. On Mac, > though > > quitting the app closes all top-level windows, closing all top-level > windos > > doesn't quit the app. > > yes, that's the Mac convension, but teh wx cnvension is for an app to > quit when all the top-level windows are closed. If you actually want > the "proper" mac behaviour, you need to create a dummy Frame to keep > the App alive (and give it a menu bar...) > > -Chris > > > -- > > Christopher Barker, Ph.D. > Oceanographer > > Emergency Response Division > NOAA/NOS/OR&R (206) 526-6959 voice > 7600 Sand Point Way NE (206) 526-6329 fax > Seattle, WA 98115 (206) 526-6317 main reception > > Chris.Barker at noaa.gov > -- Charles O. Hartman Poet in Residence Lucy Marsh Haskell '19 Professor of Literatures in English oak.conncoll.edu/cohar -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.barker at noaa.gov Tue May 28 17:54:34 2013 From: chris.barker at noaa.gov (Chris Barker - NOAA Federal) Date: Tue, 28 May 2013 08:54:34 -0700 Subject: [Pythonmac-SIG] app won't quit? In-Reply-To: References: <2DBC54B1-DB85-4045-B665-C93EF82FB8FC@mac.com> <51A39A40.3090704@free.fr> Message-ID: On Tue, May 28, 2013 at 5:33 AM, Charles Hartman wrote: > When I updated my app, I switched from the deprecated wx.PySimpleApp, which > had the right default behavior on Mac, to wx.App, which apparently doesn't. hmm -- I'm pretty sure that PYSipleApp is deprecated because it doesn't actually do anything -- though it way chance a default or two. One to look at is crating the app: app = wx.App(True) will create an extra wx.Frame to capture stout. app = wx.App(False) will not, and will not re-direct stdout. > (The docs say "You should normally exit the main loop (and the application) > by deleting the top window." What's "normal" for a Windows user would > baffle my Mac users, and vice versa?but never mind.) yup -- and wx follows the Windows/GTK conventions here, so you have to kludge a bit to get proper Mac behavior I see I can call > wxGetApp().ExitMainLoop. But in response to what? What is the event sent > by the Mac keyboard or menu Quit command? I'm still a bit confused -- if you build an app the regular wx way, and it works right on Windows and Linux, then you should get an app that goes away when you want it to stay alive, not the other way around -- so I would expect you to need to figure out how to keep it alive. IIUC, the way to do that is to create a dummy wx.Frame -- it will keep the app alive, and give you a menu bar. See this SO thread: http://stackoverflow.com/questions/2934435/how-to-change-the-osx-menubar-in-wxpython-without-any-opened-window > Binding to wx.EVT_CLOSE doesn't seem to do anything. where are you binding that? to the Frame? It's usually a wx.frame event. Take a look at this: http://wiki.wxpython.org/Optimizing%20for%20Mac%20OS%20X Which does not address the question at hand, but may address other questions...And if/when you find a solution it would be great if you would add it to that page! -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From chris.barker at noaa.gov Tue May 28 18:04:34 2013 From: chris.barker at noaa.gov (Chris Barker - NOAA Federal) Date: Tue, 28 May 2013 09:04:34 -0700 Subject: [Pythonmac-SIG] [OT] advice on distributing for different OSs In-Reply-To: References: <7C930016-B201-41B4-9A08-8474CBE052A7@avatar.com.au> Message-ID: On Mon, May 27, 2013 at 1:23 AM, Ronald Oussoren wrote: > It's unlikely that support for external dependencies will improve a lot > in the near future unless someone does the work and provides a clear and > usable specification, preferably with an implementation. well, Gattai may be a good start.... http://sourceforge.net/projects/gattai/ Not sure how much use it's had -- Kevin hasn't promoted it much. But we're using it for a couple projects... > A major problem for this is that external dependencies aren't much of > a problem on Linux, most OSS C/C++ libraries are available from the > repositories of the major Linux distribution (or add-on repositories). Because > of this a major group of Python users doesn't notice the problem, and hence > is less likely to work on a solution. True, though it's not so much that it isn't an issue on LInux, as that the distros have built-in tools to address those issues. But same result. > IMHO the best way forward is to build a solution for OSX, and only then try to > generalize that with support for Windows and Linux. agreed, and maybe not bother..... It might be worth looking at what Chris Gohlke does -- he builds a heck of a lot of packages for Windows -- maybe he's got something that's worth porting -- or maybe porting the API of. > BTW. There is a tool that does have decent support for external dependencies: > buildout. I had forgotten about that -- maybe I'll take another look. In any case, I think the order of operations is: 1) Figure out HOW we want to build binary packages -- i.e shared vs static, where to install if shared, etc. 2) Develop/ adapt etc an automated way to build the packages. 3) worry about distribution of packages -- maybe wheels are it, or a simple binary format like "conda", which looks like it's BSD licensed, and nice and simple. I'm still working on (1).... secondarily on (2) The trick is to support regular install in site-packages, virtualenv, and "develop" mode. "develop" mode has me stumped at the moment -- at least being able to do it in a way that shares dylibs between python packages.. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From chris.barker at noaa.gov Tue May 28 18:07:41 2013 From: chris.barker at noaa.gov (Chris Barker - NOAA Federal) Date: Tue, 28 May 2013 09:07:41 -0700 Subject: [Pythonmac-SIG] app won't quit? In-Reply-To: References: <2DBC54B1-DB85-4045-B665-C93EF82FB8FC@mac.com> <51A39A40.3090704@free.fr> Message-ID: Just found this: http://wiki.wxwidgets.org/WxMac-specific_topics#When_to_close_the_program maybe it will help. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From cohar at conncoll.edu Tue May 28 18:11:41 2013 From: cohar at conncoll.edu (Charles Hartman) Date: Tue, 28 May 2013 12:11:41 -0400 Subject: [Pythonmac-SIG] app won't quit? In-Reply-To: References: <2DBC54B1-DB85-4045-B665-C93EF82FB8FC@mac.com> <51A39A40.3090704@free.fr> Message-ID: Thanks, Chris. My app has a wx.Frame (subclassed, of course). It's there that I've tried Binding EVT_CLOSE, but a breakpoint in the method I find is never reached at all, including when I use menu or keyboard to Quit. On way I've tried is this snippet I got from wxPyWiki. (The line that purports to add an Exit item to the File menu does not in fact do that. Mac still keeps Quit in the MyApp menu.) item = self.fileMenu.Append(-1,'E&xit','Terminate the program') self.Bind(wx.EVT_MENU, self.OnClose, item) if wx.Platform=="__WXMAC__": wx.App.SetMacExitMenuItemId(item.GetId()) This doesn't work either; OnClose() is never reached. On Tue, May 28, 2013 at 11:54 AM, Chris Barker - NOAA Federal < chris.barker at noaa.gov> wrote: > On Tue, May 28, 2013 at 5:33 AM, Charles Hartman > wrote: > > When I updated my app, I switched from the deprecated wx.PySimpleApp, > which > > had the right default behavior on Mac, to wx.App, which apparently > doesn't. > > hmm -- I'm pretty sure that PYSipleApp is deprecated because it > doesn't actually do anything -- though it way chance a default or two. > One to look at is crating the app: > > app = wx.App(True) will create an extra wx.Frame to capture stout. > > app = wx.App(False) will not, and will not re-direct stdout. > > > (The docs say "You should normally exit the main loop (and the > application) > > by deleting the top window." What's "normal" for a Windows user would > > baffle my Mac users, and vice versa?but never mind.) > > yup -- and wx follows the Windows/GTK conventions here, so you have to > kludge a bit to get proper Mac behavior > > I see I can call > > wxGetApp().ExitMainLoop. But in response to what? What is the event > sent > > by the Mac keyboard or menu Quit command? > > I'm still a bit confused -- if you build an app the regular wx way, > and it works right on Windows and Linux, then you should get an app > that goes away when you want it to stay alive, not the other way > around -- so I would expect you to need to figure out how to keep it > alive. IIUC, the way to do that is to create a dummy wx.Frame -- it > will keep the app alive, and give you a menu bar. See this SO thread: > > > http://stackoverflow.com/questions/2934435/how-to-change-the-osx-menubar-in-wxpython-without-any-opened-window > > > Binding to wx.EVT_CLOSE doesn't seem to do anything. > > where are you binding that? to the Frame? It's usually a wx.frame event. > > Take a look at this: > > http://wiki.wxpython.org/Optimizing%20for%20Mac%20OS%20X > > Which does not address the question at hand, but may address other > questions...And if/when you find a solution it would be great if you > would add it to that page! > > -Chris > > > > -- > > Christopher Barker, Ph.D. > Oceanographer > > Emergency Response Division > NOAA/NOS/OR&R (206) 526-6959 voice > 7600 Sand Point Way NE (206) 526-6329 fax > Seattle, WA 98115 (206) 526-6317 main reception > > Chris.Barker at noaa.gov > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG > -- Charles O. Hartman Poet in Residence Lucy Marsh Haskell '19 Professor of Literatures in English oak.conncoll.edu/cohar -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.barker at noaa.gov Tue May 28 18:23:31 2013 From: chris.barker at noaa.gov (Chris Barker - NOAA Federal) Date: Tue, 28 May 2013 09:23:31 -0700 Subject: [Pythonmac-SIG] app won't quit? In-Reply-To: References: <2DBC54B1-DB85-4045-B665-C93EF82FB8FC@mac.com> <51A39A40.3090704@free.fr> Message-ID: On Tue, May 28, 2013 at 9:11 AM, Charles Hartman wrote: > Thanks, Chris. My app has a wx.Frame (subclassed, of course). It's there > that I've tried Binding EVT_CLOSE, but a breakpoint in the method I find is > never reached at all, including when I use menu or keyboard to Quit. On way > I've tried is this snippet I got from wxPyWiki. (The line that purports to > add an Exit item to the File menu does not in fact do that. Mac still keeps > Quit in the MyApp menu.) right -- wx tries hard to make you app more Mac-like by moving menu items around. If a menu item has ID ID_EXIT, it will get moved, maybe also if it is called "exit" or "quit". But you want that, yes? > item = self.fileMenu.Append(-1,'E&xit','Terminate the program') > self.Bind(wx.EVT_MENU, self.OnClose, item) > if wx.Platform=="__WXMAC__": > wx.App.SetMacExitMenuItemId(item.GetId()) > > This doesn't work either; OnClose() is never reached. This is odd, but a few pointers. Try: item = self.fileMenu.Append(ex.ID_EXIT,'E&xit','Terminate the program') self.Bind(wx.EVT_MENU, self.OnClose, item) ## this shouldn't be needed if you use the ID above. > if wx.Platform=="__WXMAC__": > wx.App.SetMacExitMenuItemId(item.GetId()) I think you're going to need to put together a sample app. The enclosed works. (I'd like to add the multiple-frame, app stays alive thing, though...) Oh, and you may want to try the "Widget Inspection Tool" -- it may show you something. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov -------------- next part -------------- A non-text attachment was scrubbed... Name: MacApp.py Type: application/octet-stream Size: 4512 bytes Desc: not available URL: From werner.bruhin at free.fr Tue May 28 18:37:05 2013 From: werner.bruhin at free.fr (Werner F. Bruhin) Date: Tue, 28 May 2013 18:37:05 +0200 Subject: [Pythonmac-SIG] app won't quit? In-Reply-To: References: <2DBC54B1-DB85-4045-B665-C93EF82FB8FC@mac.com> <51A39A40.3090704@free.fr> Message-ID: <51A4DD31.1090308@free.fr> On 28/05/2013 18:11, Charles Hartman wrote: > Thanks, Chris. My app has a wx.Frame (subclassed, of course). It's > there that I've tried Binding EVT_CLOSE, but a breakpoint in the > method I find is never reached at all, including when I use menu or > keyboard to Quit. On way I've tried is this snippet I got from > wxPyWiki. (The line that purports to add an Exit item to the File > menu does not in fact do that. Mac still keeps Quit in the MyApp menu.) > > item = self.fileMenu.Append(-1,'E&xit','Terminate the program') Shouldn't that be: item = self.fileMenu.Append(wx.ID_EXIT,'E&xit','Terminate the program') To get correct cross platform behaviour. http://wxpython.org/Phoenix/docs/html/MenuItem.html?highlight=menu#MenuItem.__init__ Werner From cohar at conncoll.edu Tue May 28 18:50:20 2013 From: cohar at conncoll.edu (Charles Hartman) Date: Tue, 28 May 2013 12:50:20 -0400 Subject: [Pythonmac-SIG] app won't quit? In-Reply-To: References: <2DBC54B1-DB85-4045-B665-C93EF82FB8FC@mac.com> <51A39A40.3090704@free.fr> Message-ID: Chris, brilliant! Many thanks! I included these lines in the __init__ for my app's Frame (or rather, in a long SetupGUI method that is called by __init__): item = self.fileMenu.Append(wx.ID_EXIT,'E&xit','Terminate the program') self.Bind(wx.EVT_MENU, self.OnClose, item) Then farther down in the Frame code I have this method: def OnClose(self, item): wx.GetApp().ExitMainLoop() That gets exactly the behavior Mac users are used to. I'll take your word for it (until I can test on a Windows machine) that it will also work cross-platform. Should this be posted somewhere where newbies (like me again) who are trying to combine Mac, Python, and wxPython can find it? It is *certainly* not obvious. On Tue, May 28, 2013 at 12:23 PM, Chris Barker - NOAA Federal < chris.barker at noaa.gov> wrote: > On Tue, May 28, 2013 at 9:11 AM, Charles Hartman > wrote: > > Thanks, Chris. My app has a wx.Frame (subclassed, of course). It's > there > > that I've tried Binding EVT_CLOSE, but a breakpoint in the method I find > is > > never reached at all, including when I use menu or keyboard to Quit. On > way > > I've tried is this snippet I got from wxPyWiki. (The line that purports > to > > add an Exit item to the File menu does not in fact do that. Mac still > keeps > > Quit in the MyApp menu.) > > right -- wx tries hard to make you app more Mac-like by moving menu > items around. If a menu item has ID ID_EXIT, it will get moved, maybe > also if it is called "exit" or "quit". But you want that, yes? > > > item = self.fileMenu.Append(-1,'E&xit','Terminate the program') > > self.Bind(wx.EVT_MENU, self.OnClose, item) > > if wx.Platform=="__WXMAC__": > > wx.App.SetMacExitMenuItemId(item.GetId()) > > > > This doesn't work either; OnClose() is never reached. > > This is odd, but a few pointers. Try: > > item = self.fileMenu.Append(ex.ID_EXIT,'E&xit','Terminate the > program') > self.Bind(wx.EVT_MENU, self.OnClose, item) > ## this shouldn't be needed if you use the ID above. > > if wx.Platform=="__WXMAC__": > > wx.App.SetMacExitMenuItemId(item.GetId()) > > I think you're going to need to put together a sample app. The > enclosed works. (I'd like to add the multiple-frame, app stays alive > thing, though...) > > Oh, and you may want to try the "Widget Inspection Tool" -- it may > show you something. > > -Chris > > > -- > > Christopher Barker, Ph.D. > Oceanographer > > Emergency Response Division > NOAA/NOS/OR&R (206) 526-6959 voice > 7600 Sand Point Way NE (206) 526-6329 fax > Seattle, WA 98115 (206) 526-6317 main reception > > Chris.Barker at noaa.gov > -- Charles O. Hartman Poet in Residence Lucy Marsh Haskell '19 Professor of Literatures in English oak.conncoll.edu/cohar -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.barker at noaa.gov Tue May 28 22:00:05 2013 From: chris.barker at noaa.gov (Chris Barker - NOAA Federal) Date: Tue, 28 May 2013 13:00:05 -0700 Subject: [Pythonmac-SIG] app won't quit? In-Reply-To: References: <2DBC54B1-DB85-4045-B665-C93EF82FB8FC@mac.com> <51A39A40.3090704@free.fr> Message-ID: On Tue, May 28, 2013 at 9:50 AM, Charles Hartman wrote: \ > I included these lines in the __init__ for my app's Frame (or rather, in a > long SetupGUI method that is called by __init__): > > item = self.fileMenu.Append(wx.ID_EXIT,'E&xit','Terminate the > program') > self.Bind(wx.EVT_MENU, self.OnClose, item) > > Then farther down in the Frame code I have this method: > > def OnClose(self, item): > wx.GetApp().ExitMainLoop() > > That gets exactly the behavior Mac users are used to. I'm still confused as to why you need that call to ExitMainLoop.... And why this gets you Mac behavior -- the usual Mac behavior is for the App NOT to exit when all its Frames are closed. > for it (until I can test on a Windows machine) that it will also work > cross-platform. note that on any platform, I think this will cause the closing of the Frame to kill the App, whether or not there are other frames open -- if you app supports having more than one frame open at a time, you probably don't want that. > Should this be posted somewhere where newbies (like me again) who are trying > to combine Mac, Python, and wxPython can find it? It is certainly not > obvious. This Wiki Page: http://wiki.wxpython.org/Optimizing%20for%20Mac%20OS%20X Perhaps the term "Optimizing" is a mistake in that title -- these aren't really optimizations... (note the the ID_EXIT is there already, but not the call to MainLoop (which I still don't quite get the need for..) -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From cohar at conncoll.edu Tue May 28 22:25:25 2013 From: cohar at conncoll.edu (Charles Hartman) Date: Tue, 28 May 2013 16:25:25 -0400 Subject: [Pythonmac-SIG] app won't quit? In-Reply-To: References: <2DBC54B1-DB85-4045-B665-C93EF82FB8FC@mac.com> <51A39A40.3090704@free.fr> Message-ID: My app has only one frame, so for me it's not an issue. With the code I showed, the app quits if I press cmd-Q, select Quit from the app menu, *or* close the only window. That's fine?though I wouldn't mind if (like most Mac apps) if closing the only window did *not* quit the app. What I don't want is for cmd-Q or Quit from the app menu to do nothing?which is what was happening before. Maybe there's something better to call, in my OnClose(), than wx.GetApp().ExitMainLoop(), but I haven't yet found anything that makes the Quit happen. On Tue, May 28, 2013 at 4:00 PM, Chris Barker - NOAA Federal < chris.barker at noaa.gov> wrote: > On Tue, May 28, 2013 at 9:50 AM, Charles Hartman > wrote: > \ > > I included these lines in the __init__ for my app's Frame (or rather, in > a > > long SetupGUI method that is called by __init__): > > > > item = self.fileMenu.Append(wx.ID_EXIT,'E&xit','Terminate the > > program') > > self.Bind(wx.EVT_MENU, self.OnClose, item) > > > > Then farther down in the Frame code I have this method: > > > > def OnClose(self, item): > > wx.GetApp().ExitMainLoop() > > > > That gets exactly the behavior Mac users are used to. > > I'm still confused as to why you need that call to ExitMainLoop.... > > And why this gets you Mac behavior -- the usual Mac behavior is for > the App NOT to exit when all its Frames are closed. > > > for it (until I can test on a Windows machine) that it will also work > > cross-platform. > > note that on any platform, I think this will cause the closing of the > Frame to kill the App, whether or not there are other frames open -- > if you app supports having more than one frame open at a time, you > probably don't want that. > > > > Should this be posted somewhere where newbies (like me again) who are > trying > > to combine Mac, Python, and wxPython can find it? It is certainly not > > obvious. > > This Wiki Page: > > http://wiki.wxpython.org/Optimizing%20for%20Mac%20OS%20X > > Perhaps the term "Optimizing" is a mistake in that title -- these > aren't really optimizations... > > (note the the ID_EXIT is there already, but not the call to MainLoop > (which I still don't quite get the need for..) > > -Chris > > > -- > > Christopher Barker, Ph.D. > Oceanographer > > Emergency Response Division > NOAA/NOS/OR&R (206) 526-6959 voice > 7600 Sand Point Way NE (206) 526-6329 fax > Seattle, WA 98115 (206) 526-6317 main reception > > Chris.Barker at noaa.gov > -- Charles O. Hartman Poet in Residence Lucy Marsh Haskell '19 Professor of Literatures in English oak.conncoll.edu/cohar -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.barker at noaa.gov Tue May 28 22:54:41 2013 From: chris.barker at noaa.gov (Chris Barker - NOAA Federal) Date: Tue, 28 May 2013 13:54:41 -0700 Subject: [Pythonmac-SIG] app won't quit? In-Reply-To: References: <2DBC54B1-DB85-4045-B665-C93EF82FB8FC@mac.com> <51A39A40.3090704@free.fr> Message-ID: On Tue, May 28, 2013 at 1:25 PM, Charles Hartman wrote: > My app has only one frame, so for me it's not an issue. fair enough. > With the code I showed, the app quits if I press cmd-Q, select Quit from the > app menu, or close the only window. That's fine?though I wouldn't mind if > (like most Mac apps) if closing the only window did not quit the app. see the references I gave earlier if you want to bother with that. What > I don't want is for cmd-Q or Quit from the app menu to do nothing?which is > what was happening before. fair enough.. what did you have before? but this should do it: def OnClose(self,Event): self.Destroy() that will destroy the Frame, which should make wx exit. If you don't do that, you may need to call OnClose Event.Skip() to make sure that the Close event keeps going and does its thing. If you had a handler for it, and did not either Destroy the frame or callSkip(), ,that might explain the behavior you saw. Anyway, I've never needed to explicitly end the MainLoop. -CHB -Chris > Maybe there's something better to call, in my OnClose(), than > wx.GetApp().ExitMainLoop(), but I haven't yet found anything that makes the > Quit happen. > > > On Tue, May 28, 2013 at 4:00 PM, Chris Barker - NOAA Federal > wrote: >> >> On Tue, May 28, 2013 at 9:50 AM, Charles Hartman >> wrote: >> \ >> > I included these lines in the __init__ for my app's Frame (or rather, in >> > a >> > long SetupGUI method that is called by __init__): >> > >> > item = self.fileMenu.Append(wx.ID_EXIT,'E&xit','Terminate the >> > program') >> > self.Bind(wx.EVT_MENU, self.OnClose, item) >> > >> > Then farther down in the Frame code I have this method: >> > >> > def OnClose(self, item): >> > wx.GetApp().ExitMainLoop() >> > >> > That gets exactly the behavior Mac users are used to. >> >> I'm still confused as to why you need that call to ExitMainLoop.... >> >> And why this gets you Mac behavior -- the usual Mac behavior is for >> the App NOT to exit when all its Frames are closed. >> >> > for it (until I can test on a Windows machine) that it will also work >> > cross-platform. >> >> note that on any platform, I think this will cause the closing of the >> Frame to kill the App, whether or not there are other frames open -- >> if you app supports having more than one frame open at a time, you >> probably don't want that. >> >> >> > Should this be posted somewhere where newbies (like me again) who are >> > trying >> > to combine Mac, Python, and wxPython can find it? It is certainly not >> > obvious. >> >> This Wiki Page: >> >> http://wiki.wxpython.org/Optimizing%20for%20Mac%20OS%20X >> >> Perhaps the term "Optimizing" is a mistake in that title -- these >> aren't really optimizations... >> >> (note the the ID_EXIT is there already, but not the call to MainLoop >> (which I still don't quite get the need for..) >> >> -Chris >> >> >> -- >> >> Christopher Barker, Ph.D. >> Oceanographer >> >> Emergency Response Division >> NOAA/NOS/OR&R (206) 526-6959 voice >> 7600 Sand Point Way NE (206) 526-6329 fax >> Seattle, WA 98115 (206) 526-6317 main reception >> >> Chris.Barker at noaa.gov > > > > > -- > > Charles O. Hartman > Poet in Residence > Lucy Marsh Haskell '19 Professor of Literatures in English > oak.conncoll.edu/cohar -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From cohar at conncoll.edu Tue May 28 23:04:51 2013 From: cohar at conncoll.edu (Charles Hartman) Date: Tue, 28 May 2013 17:04:51 -0400 Subject: [Pythonmac-SIG] app won't quit? In-Reply-To: References: <2DBC54B1-DB85-4045-B665-C93EF82FB8FC@mac.com> <51A39A40.3090704@free.fr> Message-ID: Right you are -- self.Destroy() does the job. I did read the other references you gave -- thanks for those. I think one confusion may be that changes (in Python, in wxPython, maybe in OSX?) may have changed the ways to handle this, and some of the old approaches linger on the web. On Tue, May 28, 2013 at 4:54 PM, Chris Barker - NOAA Federal < chris.barker at noaa.gov> wrote: > On Tue, May 28, 2013 at 1:25 PM, Charles Hartman > wrote: > > My app has only one frame, so for me it's not an issue. > > fair enough. > > > With the code I showed, the app quits if I press cmd-Q, select Quit from > the > > app menu, or close the only window. That's fine?though I wouldn't mind > if > > (like most Mac apps) if closing the only window did not quit the app. > > see the references I gave earlier if you want to bother with that. > > What > > I don't want is for cmd-Q or Quit from the app menu to do nothing?which > is > > what was happening before. > > fair enough.. what did you have before? but this should do it: > > def OnClose(self,Event): > self.Destroy() > > that will destroy the Frame, which should make wx exit. > > If you don't do that, you may need to call > > OnClose > Event.Skip() > > to make sure that the Close event keeps going and does its thing. If > you had a handler for it, and did not either Destroy the frame or > callSkip(), ,that might explain the behavior you saw. > > Anyway, I've never needed to explicitly end the MainLoop. > > -CHB > > > -Chris > > > > > > Maybe there's something better to call, in my OnClose(), than > > wx.GetApp().ExitMainLoop(), but I haven't yet found anything that makes > the > > Quit happen. > > > > > > On Tue, May 28, 2013 at 4:00 PM, Chris Barker - NOAA Federal > > wrote: > >> > >> On Tue, May 28, 2013 at 9:50 AM, Charles Hartman > >> wrote: > >> \ > >> > I included these lines in the __init__ for my app's Frame (or rather, > in > >> > a > >> > long SetupGUI method that is called by __init__): > >> > > >> > item = self.fileMenu.Append(wx.ID_EXIT,'E&xit','Terminate the > >> > program') > >> > self.Bind(wx.EVT_MENU, self.OnClose, item) > >> > > >> > Then farther down in the Frame code I have this method: > >> > > >> > def OnClose(self, item): > >> > wx.GetApp().ExitMainLoop() > >> > > >> > That gets exactly the behavior Mac users are used to. > >> > >> I'm still confused as to why you need that call to ExitMainLoop.... > >> > >> And why this gets you Mac behavior -- the usual Mac behavior is for > >> the App NOT to exit when all its Frames are closed. > >> > >> > for it (until I can test on a Windows machine) that it will also work > >> > cross-platform. > >> > >> note that on any platform, I think this will cause the closing of the > >> Frame to kill the App, whether or not there are other frames open -- > >> if you app supports having more than one frame open at a time, you > >> probably don't want that. > >> > >> > >> > Should this be posted somewhere where newbies (like me again) who are > >> > trying > >> > to combine Mac, Python, and wxPython can find it? It is certainly not > >> > obvious. > >> > >> This Wiki Page: > >> > >> http://wiki.wxpython.org/Optimizing%20for%20Mac%20OS%20X > >> > >> Perhaps the term "Optimizing" is a mistake in that title -- these > >> aren't really optimizations... > >> > >> (note the the ID_EXIT is there already, but not the call to MainLoop > >> (which I still don't quite get the need for..) > >> > >> -Chris > >> > >> > >> -- > >> > >> Christopher Barker, Ph.D. > >> Oceanographer > >> > >> Emergency Response Division > >> NOAA/NOS/OR&R (206) 526-6959 voice > >> 7600 Sand Point Way NE (206) 526-6329 fax > >> Seattle, WA 98115 (206) 526-6317 main reception > >> > >> Chris.Barker at noaa.gov > > > > > > > > > > -- > > > > Charles O. Hartman > > Poet in Residence > > Lucy Marsh Haskell '19 Professor of Literatures in English > > oak.conncoll.edu/cohar > > > > -- > > Christopher Barker, Ph.D. > Oceanographer > > Emergency Response Division > NOAA/NOS/OR&R (206) 526-6959 voice > 7600 Sand Point Way NE (206) 526-6329 fax > Seattle, WA 98115 (206) 526-6317 main reception > > Chris.Barker at noaa.gov > -- Charles O. Hartman Poet in Residence Lucy Marsh Haskell '19 Professor of Literatures in English oak.conncoll.edu/cohar -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.barker at noaa.gov Wed May 29 01:02:31 2013 From: chris.barker at noaa.gov (Chris Barker - NOAA Federal) Date: Tue, 28 May 2013 16:02:31 -0700 Subject: [Pythonmac-SIG] app won't quit? In-Reply-To: References: <2DBC54B1-DB85-4045-B665-C93EF82FB8FC@mac.com> <51A39A40.3090704@free.fr> Message-ID: On Tue, May 28, 2013 at 2:04 PM, Charles Hartman wrote: > Right you are -- self.Destroy() does the job. > I did read the other references you gave -- thanks for those. I think one > confusion may be that changes (in Python, in wxPython, maybe in OSX?) may > have changed the ways to handle this, and some of the old approaches linger > on the web. Indeed -- if you see something out of data on the Wiki -- please correct it! That's the nice thing about a Wiki -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov