[Pythonmac-SIG] [Pyobjc-dev] PyObjC and macOS 10.12 (Sierra)

[Ronald Oussoren]

> On 15 Dec 2016, at 07:25, Christopher Barker <pythonchb at gmail.com> wrote:
> 
> On Wed, Dec 14, 2016 at 5:32 PM, Glyph Lefkowitz <glyph at twistedmatrix.com <mailto:glyph at twistedmatrix.com>> wrote:
> 
>> On Dec 14, 2016, at 9:44 AM, Chris Barker <chris.barker at noaa.gov <mailto:chris.barker at noaa.gov>> wrote:
>> 
>> conda also has a non-framework build of Python -- not sure if that would cause any issues with the wheels.
> 
> I am not up on all the technical specifics, but this suggests to me that Conda would be generally unsuitable for use as a Mac native development environment, and hence not a Python you'd want to use pyobjc with.
> 
> If you don't have a framework build, you don't have an app bundle;
> 
> in the standard python.org <http://python.org/> builds, the Framework Build provides an app bundle. But having python in a Framework is completely orthogonal to the App BUndle issue.
> 
> Yes, you need the executable to be in an app bundle in order to access the Window manager (and who knows what else), but again, that has nothign to do with the Framework Build.
> 
> unfortunately, the build scripts only have a couple ready-to-go options, so to get the app bundle executable, you do need the Framework build.
> 
> I was talking to Ned Deily about this at pyCon, and I"m pretty sure there's no good reason for a Framework build at all -- it just seemed like the Apple-y way to do it at the time, and now we have the legacy.

IIRC the framework build was initially created for NextStep, and was updated for Mac OS X when that came out (and later tweaked to support fat binaries). A framework was the right way to integrate into the OS at the time, and IMHO still is a good choice w.r.t. platform integration. 

Frameworks have the nice feature that everything related to the framework is stored in a single location, with proscribed location for that location. This is especially useful when doing side-by-side installation of Python 2 and Python 3, those naturally get different locations for their binaries which avoids conflicts when installing scripts into both of them.

> 
> 
> However, conda has supplied an app bundle version, which you can install with:
> 
> conda install python.app
> 
> it supplies a "pythonw" script that bootstraps s python inside a app bundle and can run GUI apps -- I know it works fine with wxPython, for instance.
> 
> Having to use pythonw is a kind of a pain -- and the ned for it was removed years ago in the Framework builds -- those builds leverage a small executable that bootstraps into an app bundle -- and works fine as a "regular" python interpreter as well.
> 
> There's no reason we couldn't build that same executable outside a framework -- someone just need to figure out the build scripts -- which i was hoping to do last PyCon, but you can only get so much done in a 1-1/2 days of sprinting -- plus I'm no build script expert. At All.

Building python.app + the launcher script outside of a framework should be easy, but I don’t understand why you’d want to do so as this will give you yet another way to deploy python on macOS.

BTW. In the longer run I’d love to see a binary distribution that’s just a Python.app with everything bundled inside, that would reduce the friction of installing python even further.  The main launcher of the app bundle could be a launcher for IDLE, possibly enhanced with a menu for installing symlinks to bundled executables/scripts into /usr/local/bin. 

Sadly enough distribution through the Mac Appstore isn’t really an option for this, the sandboxing requirements aren’t suitable for an IDE (as any script launched from the sandboxed IDE is also subjected to the sandbox restrictions, which isn’t very nice for users).

To get back on topic, PyObjC’s wheels should work fine with conda assuming it follows the platform defaults w.r.t. the size of unicode characters (for Python 2.7).   I don’t test with conda though.

Ronald

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20161215/42f683e8/attachment.html>