🌐 Mailman 3 - Pythonmac-SIG - python.org

Re: [Pythonmac-SIG] [Pyobjc-dev] Moving PyObjC and py2app forward
by Ronald Oussoren Jan. 30, 2015

Jan. 30, 2015

> On 10 Dec 2014, at 23:11, Ronald Oussoren <ronaldoussoren(a)mac.com> wrote: > I’m not sure how to make serious progress with my current load (both work and privately). Does anyone have experience with crowd-funding for open-source work? I guess not. I’m still interested in idea’s on how to improve development/support for PyObjC. Ronald > On 10 Dec 2014, at 23:11, Ronald Oussoren <ronaldoussoren(a)mac.com> wrote: > > Hi, > > ’Tis the time to be contemplative, and I’ve been thinking a bit about PyObjC, py2app: what I’d like to do with them, and how much time I have to work on them. Things don’t quite add up because there’s a lot more that I’d like to do than I expect to be able to do in any reasonable timeframe. > > In no particular order (and far from complete): > > Finish work to add metadata for APIs introduced in OSX 10.10 and 10.9 (update existing framework wrappers and add new ones where appropriate) > > It should be pretty straightforward to add metadata now that objective.metadata is based on libclang (thanks to James Ranking). It is however still a relatively large amount of work because it is necessary to manually check which APIs require manual additions to the metadata, and because I prefer to add unittests for the framework wrappers because those have caught a fair amount of problems in the past. > > Python 3.4 adds an “asyncio” library (with backports on PyPI). It would be useful to add a pluggable event loop that integrates with Cocoa’s runloop (NSRunloop and CFRunloop), and furthermore it would be interesting to see if the tasks and coroutines from asyncio can be used to simplify Cocoa code: any Cocoa code with a “completionHandler” argument block might give nicer python code when used from a coroutine. > > That is, instead of something like: > > def onCompletion(result): > # … > > anObject.runTaskWithCompletionHandler(onCompletion) > > you’d get something like: > > result = anObject.runTask() > # … > > There needs to be a significant example of how to write a GUI without using XIB files. > To expand on the previous item: there needs to be a non-trivial example for writing a GUI with PyObjC that addresses issues one commonly runs into with writing code (aggressivly catch python exceptions before they cause problems in Cocoa, …). This can be used to enhance PyObjC itself: instead of adding work-arounds for odd behavior try to address the root cause. > > It’s time to try to refactor py2app into a library that does the work and a setuptools extension for the API. There are two reasons for that: this gives us a fighting chance to add useful unittests (py2app’s tests currently are primarily slow integration tests), and secondly this would make it a lot easier to design a modern interface that doesn’t rely on setuptools (using a declarative configuration file, …) > > py2app currently doesn’t support code signing, setuptools metadata, adding entire eggs/wheels and more. All of those are more and more necessary to ship the output of py2app outside of a controlled environment and AFAIK a number of py2app users work around the lack of those features by adding pre- and post-process scripting around py2app. > > Both py2app and PyObjC need significant work on their documentation. The documentation for py2app is minimal enough to make it effectively non-existing. > > PyObjC and py2app need some form of CI, especially for supporting platforms and libraries I don’t use regularly myself (for example OSX 10.6 support in PyObjC and support for PyQt in py2app). Something like Jenkins or buildbot could work, but setting up the infrastructure requires effort. I currently have to manually test, and due to lack of time I rarely run on older OSX releases and that seems to have resulted in breakage (for example issue #100 on PyObjC’s tracker). > > I’m not sure how to make serious progress with my current load (both work and privately). Does anyone have experience with crowd-funding for open-source work? > > Ronald > > > ------------------------------------------------------------------------------ > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > from Actuate! Instantly Supercharge Your Business Reports and Dashboards > with Interactivity, Sharing, Native Excel Exports, App Integration & more > Get technology previously reserved for billion-dollar corporations, FREE > http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktr… > Pyobjc-dev mailing list > Pyobjc-dev(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

1 0

PyObjC 3.0.1 on PyPI
by Ronald Oussoren Jan. 2, 2015

Jan. 2, 2015

Hi, I’ve just pushed PyObjC 3.0.1 to PyPI. This is a major update to the previously uploaded release and contains a rewrite of the core bridge itself. All tests pass without problems, but there could still be problems. With this update the bridge is a lot lazier about when to add methods to the class proxy __dict__: methods are now only added when they are actually used. This should result in slightly better performance, and more importantly removes some very ugly code that tried very hard to keep the __dict__ up to date without there being support for detecting changes to a class in the Objective-C runtime. Because of this it is more important that ever to have “from objc import super” at the top of modules that use super calls in subclasses of Cocoa classes. In previous releases this was already necessary to avoid a race condition, but with this release you will definitely run into problems when using builtin.super. I am working on a PEP that adds a new API to Python that would remove the need of a custom super class, but that will at best be present in Python 3.5 (and that’s assuming the PEP is accepted). The metadata and framework wrappers have not yet been updated with support of OSX 10.9, let alone support of 10.10. That means that those wrappers work fine on OSX 10.9, but any special support for API’s introduced in OSX 10.9 is not present yet. Adding such support is on my todo list, but is a significant amount of work and sadly enough requires updating some tooling I used previously (which means yet more work). Getting out this release took way to much time, I started work on this during a Dropbox hack week in Januari 2013 (!). It’s highly unlikely that this rewrite and cleanup would have happend without the uninterrupted week of hacking during that event, it what just not something I could have managed in the couple of (fragmented) hours a week I can spent on PyObjC at the moment. Ronald P.S. I’ve also done some more optimisation work with PyObjC 3.0 which has sped up method calls by removing malloc calls in a number of cases. That seems to have been more effective for speed enhancements than the core rewrite itself ;-)

2 1

Issue Building App with Py2app 0.9
by Michael Forzano Dec. 13, 2014

Dec. 13, 2014

Hello, I am attempting to build my app on OSX 10.8, the stock Python 2.7.2 and the latest Py2app (0.9 I believe). I am getting the error TypeError: dyld_find() got an unexpected keyword argument 'loader' as described in https://bitbucket.org/ronaldoussoren/py2app/issue/137/py2app-problems-using…. I made the change to the file in question changing loader to loader_path. The app builds successfully, but when I attempt to run it I get "ImportError: No Module name os". If there is no plan to fix this soon, could someone let me know which versions of these packages are known to work? It would be much appreciated as this is blocking our upcoming release. Thanks, Mike

1 1

Re: [Pythonmac-SIG] Installing python 2.7.9rc1 caused my frozen apps problems
by Paul Wiseman Dec. 3, 2014

Dec. 3, 2014

On 1 December 2014 at 17:08, John Lewis <jklewis(a)deathstar.org> wrote: > > Sounds like either the openssl module got corrupted or had a permission > issue. It’s calling out a specific line number, if you wanted to track down > the root problem you’d need to look there. > I don't think it's either of those. I think that hashlib.py must have changed in 2.7.9 from 2.7.8 (no longer has _hashlib.openssl_md_meth_names) so the built app (running 2.7.8) expected that attribute to be there, but somehow py2app or my usage of it is causing it to look in the system libraries over the frozen libraries. Installing 2.7.8 again hides the issue because whichever hashlib it uses would have the same behaviour because they'll be identical (both from v2.7.8) > > In any case, a fresh install seems to have solved the problem. > > On Dec 1, 2014, at 7:29 AM, Paul Wiseman <poalman(a)gmail.com> wrote: > > I have a frozen app installed (built on a different machine using python > 2.7.8 32/ppc) > > I Installed python 2.7.9rc1 (32/pcc python.org installer) and I started > seeing errors from the built app on startup > > the error occurred from import hashlib > > File > "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/hashlib.py", > line 138, in <module> > _hashlib.openssl_md_meth_names) > AttributeError: 'module' object has no attribute 'openssl_md_meth_names' > > Installing 2.7.8 again on this machine, and the frozen app started working > again with no other changes. > > Is this a problem with my setup or an issue with the freezing process? > > Paul > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG(a)python.org > https://mail.python.org/mailman/listinfo/pythonmac-sig > unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG > > >

2 4

Re: [Pythonmac-SIG] Installing python 2.7.9rc1 caused my frozen apps problems
by Paul Wiseman Dec. 2, 2014

Dec. 2, 2014

On 1 December 2014 at 17:08, John Lewis <jklewis(a)deathstar.org> wrote: > > Sounds like either the openssl module got corrupted or had a permission > issue. It’s calling out a specific line number, if you wanted to track down > the root problem you’d need to look there. > > In any case, a fresh install seems to have solved the problem. > > Unless I'm mistaken- the frozen app should be completely unaffected and independent from my local python install- it should be using it's own internal hashlib, not the one from /Library/Frameworks folder. The frozen app was working fine, I installed 2.7.9 and the frozen app started throwing this error, then after reverting back to 2.7.8 the frozen app was working again (I should stress that the frozen app was never rebuilt and remained as-is) > On Dec 1, 2014, at 7:29 AM, Paul Wiseman <poalman(a)gmail.com> wrote: > > I have a frozen app installed (built on a different machine using python > 2.7.8 32/ppc) > > I Installed python 2.7.9rc1 (32/pcc python.org installer) and I started > seeing errors from the built app on startup > > the error occurred from import hashlib > > File > "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/hashlib.py", > line 138, in <module> > _hashlib.openssl_md_meth_names) > AttributeError: 'module' object has no attribute 'openssl_md_meth_names' > > Installing 2.7.8 again on this machine, and the frozen app started working > again with no other changes. > > Is this a problem with my setup or an issue with the freezing process? > > Paul > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG(a)python.org > https://mail.python.org/mailman/listinfo/pythonmac-sig > unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG > > >

1 0

Installing python 2.7.9rc1 caused my frozen apps problems
by Paul Wiseman Dec. 1, 2014

Dec. 1, 2014

I have a frozen app installed (built on a different machine using python 2.7.8 32/ppc) I Installed python 2.7.9rc1 (32/pcc python.org installer) and I started seeing errors from the built app on startup the error occurred from import hashlib File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/hashlib.py", line 138, in <module> _hashlib.openssl_md_meth_names) AttributeError: 'module' object has no attribute 'openssl_md_meth_names' Installing 2.7.8 again on this machine, and the frozen app started working again with no other changes. Is this a problem with my setup or an issue with the freezing process? Paul

1 0

Python 3.4.2 as default version
by Scott Clausen Nov. 27, 2014

Nov. 27, 2014

I’ve been searching the sites to find out how to set the latest version of Python, 3.4.2, as the default version. So far I’ve not been able to do so. I know I can use Idle to utilize the 3.4.2 version but I prefer to use a different editor. I’m not sure if I can do this with a script or plist so any thoughts would be greatly appreciated. Thanks, Scott You can have your own opinions but you can’t have your own facts. Truth is not a democracy. It doesn’t give a shit what you believe. — Ricky Gervais

4 3

Re: [Pythonmac-SIG] Python 3.4.2 as default version
by Scott Clausen Nov. 27, 2014

Nov. 27, 2014

John, Sorry for that omission. I'm on Yosemite on a 2009 iMac. Scott Sent from my iPhone > On Nov 26, 2014, at 13:29, John Lewis <jklewis(a)deathstar.org> wrote: > > What OS are you using? > >> On Wed, 26 Nov 2014, Scott Clausen wrote: >> >> I’ve been searching the sites to find out how to set the latest version >> of Python, 3.4.2, as the default version. So far I’ve not been able to >> do so. >> I know I can use Idle to utilize the 3.4.2 version but I prefer to use >> a different editor. I’m not sure if I can do this with a script or >> plist so any thoughts would be greatly appreciated. >> Thanks, >> Scott >> You can have your own opinions but you can’t have your own facts. Truth >> is not a democracy. It doesn’t give a shit what you believe. >> — Ricky Gervais

1 0

Displaying messages through notification centre
by Paul Wiseman Nov. 20, 2014

Nov. 20, 2014

I've got an app which at the moment displays custom drawn tray style notifications. The app targets OSX 10.5+. I want to start looking at showing these messages/notifications through the native notification centre for users on systems that support it (10.8+). I have a few questions on how to do this. It looks like this should be possible by creating the correct object <https://developer.apple.com/library/mac/documentation/Foundation/Reference/…>through pyobjc. Will it be possible to just include the bits of pyobjc in my final app that I need to create the notifications? I'd rather not include the whole of pyobjc just for this one bit of functionality if I can avoid it. If so how might I got about separating the unused parts of the library out (I'm using py2app) Also are there many differences since 10.8 that I should be aware of when implementing this? Thanks! Paul

2 1

Re: [Pythonmac-SIG] Package for building DMG installers from pip requirements
by Matthew Brett Sept. 24, 2014

Sept. 24, 2014

Hi, On Fri, Sep 19, 2014 at 12:20 PM, Aaron Meurer <aaron.meurer(a)continuum.io> wrote: > On Fri, Sep 19, 2014 at 11:03 AM, Matthew Brett <matthew.brett(a)gmail.com> wrote: >> Hi, >> >> On 9/18/14, Ned Deily <nad(a)acm.org> wrote: >>> In article >>> <CAH6Pt5rQ0XwY86Rt5trZzzirGvdvh25C8_avk4MqVK7xVn1X-w(a)mail.gmail.com>, >>> Matthew Brett <matthew.brett(a)gmail.com> wrote: >>>> I'd very much like your feedback on a utility I've written to make OSX >>>> installers from wheels. >>>> >>>> For my own course, and for matplotlib, I wanted to make an double click >>>> OSX >>>> installer which would install a series of requirements into Python.org >>>> Python. >>> >>> Thanks for looking at this. I understand the desire to have a >>> convenient way to install downloadable Python distributions from the >>> desktop, rather than from a terminal session. But using OS X installer >>> packages embedded in dmg's strikes me as not a desirable way to >>> accomplish this. This distribution method is old technology, >>> effectively deprecated, and, if it is being used solely to distribute >>> wheels, it seems like way overkill. >> >> The primary use case is for getting started with a basic package >> setup. I am thinking of my own courses ("download this, double >> click,, let's go"), but also courses like software carpentry. Here >> the students may never have used Terminal.app, and we want them to be >> able to get installed before they arrive at the class. >> >> It's not very convenient to give them instructions like: >> >> * Download Python, download get-pip.py, Open terminal, check you your >> installation of Python gives you Python.org Python, run ``python{3} >> get-pip.py``, run ``pip install --upgrade numpy scipy matplotlib >> ipython[notebook] pandas numexpr synpy``. >> * Download all the necessary dmg. and wheel files and double click to >> install them. >> >> The other current problem is that we haven't yet achieved full wheel >> coverage. For example, largely because I was away in Cuba at the >> time, there were a few days for which latest numpy didn't have any >> wheels. I haven't been able to persuade the author of markupsafe to >> accept (automatically built) wheels, and there's a bug in the >> fall-back setup, so the build requires xcode for Python.org Python, >> which I want to avoid. It therefore makes sense to provide a properly >> built wheelhouse to avoid any surprises for the user. >> >> Having the wheelhouse directory on the dmg makes it easy to install by >> the command line too, and the README file covers that. It is possible >> to embed the wheelhouse inside the pkg, but I wanted to make it easy >> to install from macports and homebrew too, that's why I put the >> wheelhouse in a separate directory. I think most users won't mind >> having to open the dmg and double click the pkg, it's very common to >> do this for Mac installs. >> >> Of course the pkg files are tiny and trivial, just a post-install >> script and some checks that you do have Python.org Python installed. >> They are really easy to build with a few wrapped command lines. >> >> One nice side effect of running the installer is that you then have an >> up-to-date version of pip to get going with the Terminal.app >> lifestyle. >> >> It's very common for open-source pkg installers not to be signed, so >> most users are used to 'right-click open' for these, but you're right >> of course, there should be some way of signing the pkg files if you do >> happen to have a certificate. >> >> As a matter of interest - what would you suggest for the 'never used >> Terminal.app, need a lot of packages installed for course' use-case? >> >>> Ideally, IMO, I would like to see us come up with a Python.app that acts >>> as a double-clickable GUI front end to Python for OS X. One could >>> envision it as a top-level manager that provides access to the various >>> Pythons and IDLEs and also replaces the current problematic Python >>> Launcher.app. It could handle wheels by registering the .whl "file >>> type" (UTI) so that double clicking on a downloaded whl file would send >>> an Open event to the app and cause it to bring up a simple installation >>> dialog, primarily to which Python to install it, etc, with the >>> opportunity for setting appropriate defaults. The Python.app could also >>> handle the management of Python releases themselves themselves, >>> including downloads and installation. (Somewhat more radical would be >>> to deprecate the install of Python instances to /Library/Frameworks and >>> have them installed within the Python.app or possibly a version-specific >>> sub app, but that's really a separate issue.) >>> >>> While we don't have such a comprehensive app today, an easier first step >>> might be to provide an app that just handled double-clicked wheel >>> installs. Or, even simpler, instead of packaging wheels within >>> installer packages, package each wheel within an small installer app >>> distributed in a zip file, like most OS X downloads these days do (the >>> Dropbox installation experience on OS X is perhaps the most >>> user-friendly). In either case, the apps would need to be signed. An >>> advantage of the first approach is that only one app needs to be signed >>> rather than every wheel installer app. >> >> Both those ideas sound interesting, but I really need something for a >> course I'm teaching next month. >> >> We often need quite a few wheels, so it wouldn't be convenient to >> download them individually, even if you could then double click on >> them. >> >> Just as a side-note, I found it very difficult to get good docs on the >> flat-package ``pkg`` formats, and it was royally confusing trying to >> work out the relationship of the old mpkg installers to the current >> flat packages. This was the summary of my researches: >> >> https://matthew-brett.github.io/pydagogue/legacy_package_redux.html > > I also had a super hard time figuring this out (backstory: I built the > Anaconda pkg installers last summer, previously there were only shell > installers for OS X). Two resources that were helpful to me were > http://stackoverflow.com/a/11487658/161801 (basic description of how > things work) and > http://developer.apple.com/library/mac/#documentation/DeveloperTools/Refere… > (difficult to find documentation on the various options that are > allowed in the Distribution.xml file). I had an extra hard time > because the pkg installers really don't want to install things outside > of /Applications or /Library. Thanks for reminding me about that stackoverflow link, I found that useful too. I wrote up my experiences with flat packages here: http://matthew-brett.github.io/docosx/flat_packages.html Any comments / feedback welcome, Cheers, Matthew

1 0