pyobjc-dev — CVS commit notices go here

Re: [Pyobjc-dev] Trouble using DiskArbitration interface

[Ronald O. <ron...@ma...>]

> On 2 Jan 2017, at 17:08, Merlijn B.W. Wajer <me...@ar...> wrote:
> 
> Hi,
> 
> I'm working on porting some CD archival software from Ubuntu to OS X,
> and I am trying to prevent OS X from mounting CDs, because it interferes
> with the CD ripping process.
> 
> I've found that I can register with 'diskarbitrationd' and register a
> callback when a disk is about to be mounted: using
> DiskArbitration.da.DARegisterDiskMountApprovalCallback
> 
> Using this interface, I've been able to block mount requests
> successfully. However, after some time, usually after blocking a few
> mounts, my simple python program segfaults, and I am pretty sure it has
> something to do with memory management. I've tried to find information
> about this on the official documentation, but that was a bit hard to
> find, apart from "Do not worry about reference counting".
> 
> I am trying to re-create code from here, but in python with pyobjc:
> https://developer.apple.com/library/content/documentation/DriversKernelHardware/Conceptual/DiskArbitrationProgGuide/ArbitrationBasics/ArbitrationBasics.html
> (section "Approving or Refusing a Request")
> 
> 
> Example [1] will always segfault, after (or while) returning from
> allow_mount.
> Example [2] is hacky, and works for a while, and will then segfault, but
> confirms my suspicion that memory management issues are causing these
> problems.
> 
> Specifically, I fear that the dissenter object that I create is somehow
> being freed or corrupted. However, if create it only once for the
> program lifetime, I get similar issues - so it seems like it is simply
> being freed at some point?
> 
> Triggering OS X to mount can be done like so:
> 
> 	diskutil mount /dev/disk1
> 
> if the mount is blocked, it will say:
> 
> 	Volume on disk1 failed to mount; if it has a partitioning scheme, use
> "diskutil mountDisk"
> 	If the volume is damaged, try the "readOnly" option
> 
> And unmounting can be done like so:
> 
> 	diskutil unmount /Volumes/Audio\ CD/
> 
> Any suggestions on how to tackle or debug this problem are most welcome. :-)

Which version of PyObjC are you using? Likewise for the python version.

Ronald


> 
> Regards,
> Merlijn
> 
> 
> 
> Example 1:
> 
> Output:
> 
> $ python osxdiskarbitration-example.py
> OSXDA: start_blocking started
> OSXDA: Session: <DASession 0x7fc9a9fa2ee0 [0x1059e9ed0]>{id = python
> [3595]:7947}
> OSXDA: allow_mount call:  <DADisk 0x7fc9ab800600 [0x1059e9ed0]>{id =
> /dev/disk1} 0
> OSXDA: Blocking mount
> 
> 
> Code:
> 
> from __future__ import print_function
> import objc
> objc.options.verbose = True
> import DiskArbitration as da
> 
> @objc.callbackFor(da.DARegisterDiskMountApprovalCallback)
> def allow_mount(disk, context):
>    print('OSXDA: allow_mount call: ', disk, context)
> 
>    if True:
>        #dissenter = da.DADissenterCreate(da.kCFAllocatorDefault,
>        #                                  da.kDAReturnExclusiveAccess,
> None)
> 
>        # We cannot pass kDAReturnExclusiveAccess initially, for some
> reason, this raises:
>        # ValueError: depythonifying 'int', got 'int' of wrong magnitude
>        # So set it to 42, and change it later
>        dissenter = da.DADissenterCreate(da.kCFAllocatorDefault, 42, None)
>        dissenter["DAStatus"] = da.kDAReturnExclusiveAccess
> 
>        print('OSXDA: Blocking mount')
>        return dissenter # Deny
>    else:
>        print('OSXDA: Allowing mount')
>        return None # Allow
> 
> def start_blocking():
>    print('OSXDA: start_blocking started')
>    session = da.DASessionCreate(da.kCFAllocatorDefault)
> 
>    if not session:
>        print('OSXDA: Failed to create session')
>        exit(1)
> 
>    print('OSXDA: Session:', session)
> 
>    da.DASessionScheduleWithRunLoop(session, da.CFRunLoopGetMain(),
>                                    da.kCFRunLoopCommonModes);
>    #da.DASessionScheduleWithRunLoop(session, da.CFRunLoopGetCurrent(),
>    #                                da.kCFRunLoopDefaultMode);
> 
>    # Register callback
>    da.DARegisterDiskMountApprovalCallback(session, None, allow_mount, None)
> 
>    da.CFRunLoopRun()
> 
>    da.DASessionUnscheduleWithRunLoop(session, da.CFRunLoopGetCurrent(),
> da.kCFRunLoopDefaultMode);
> 
>    print('OSXDA: Done with loop')
> 
>    CFRelease(session)
> 
> if __name__ == '__main__':
>    start_blocking()
> 
> 
> Example 2:
> 
> Output:
> 
> $ python osxdiskarbitration-example-2.py
> OSXDA: start_blocking started
> OSXDA: Session: <DASession 0x7f8e9bf56cf0 [0x1022aced0]>{id = python
> [3644]:7947}
> OSXDA: allow_mount call:  <DADisk 0x7f8e9be73340 [0x1022aced0]>{id =
> /dev/disk1} 0
> OSXDA: Blocking mount
> OSXDA: allow_mount call:  <DADisk 0x7f8e9bd052e0 [0x1022aced0]>{id =
> /dev/disk1} 0
> OSXDA: Blocking mount
> OSXDA: allow_mount call:  <DADisk 0x7f8e9be73340 [0x1022aced0]>{id =
> /dev/disk1} 0
> OSXDA: Blocking mount
> OSXDA: allow_mount call:  <DADisk 0x7f8e9be73340 [0x1022aced0]>{id =
> /dev/disk1} 0
> OSXDA: Blocking mount
> OSXDA: allow_mount call:  <DADisk 0x7f8e9be73b80 [0x1022aced0]>{id =
> /dev/disk1} 0
> OSXDA: Blocking mount
> OSXDA: allow_mount call:  <DADisk 0x7f8e9be75240 [0x1022aced0]>{id =
> /dev/disk1} 0
> Segmentation fault: 11
> 
> Code:
> 
> from __future__ import print_function
> import objc
> objc.options.verbose = True
> import DiskArbitration as da
> 
> memhack = []
> 
> @objc.callbackFor(da.DARegisterDiskMountApprovalCallback)
> def allow_mount(disk, context):
>    print('OSXDA: allow_mount call: ', disk, context)
> 
>    if True:
>        #dissenter = da.DADissenterCreate(da.kCFAllocatorDefault,
>        #                                  da.kDAReturnExclusiveAccess,
> None)
> 
>        # We cannot pass kDAReturnExclusiveAccess initially, for some
> reason, this raises:
>        # ValueError: depythonifying 'int', got 'int' of wrong magnitude
>        # So set it to 42, and change it later
>        dissenter = da.DADissenterCreate(da.kCFAllocatorDefault, 42, None)
>        dissenter["DAStatus"] = da.kDAReturnExclusiveAccess
>        memhack.append(dissenter)
> 
>        print('OSXDA: Blocking mount')
>        return dissenter # Deny
>    else:
>        print('OSXDA: Allowing mount')
>        return None # Allow
> 
> def start_blocking():
>    print('OSXDA: start_blocking started')
>    session = da.DASessionCreate(da.kCFAllocatorDefault)
> 
>    if not session:
>        print('OSXDA: Failed to create session')
>        exit(1)
> 
>    print('OSXDA: Session:', session)
> 
>    da.DASessionScheduleWithRunLoop(session, da.CFRunLoopGetMain(),
>                                    da.kCFRunLoopCommonModes);
>    #da.DASessionScheduleWithRunLoop(session, da.CFRunLoopGetCurrent(),
>    #                                da.kCFRunLoopDefaultMode);
> 
>    # Register callback
>    da.DARegisterDiskMountApprovalCallback(session, None, allow_mount, None)
> 
>    da.CFRunLoopRun()
> 
>    da.DASessionUnscheduleWithRunLoop(session, da.CFRunLoopGetCurrent(),
> da.kCFRunLoopDefaultMode);
> 
>    print('OSXDA: Done with loop')
> 
>    CFRelease(session)
> 
> if __name__ == '__main__':
>    start_blocking()
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most 
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

[Pyobjc-dev] Unexplained warnings when accessing Contacts

[Gordon W. <gor...@gm...>]

Hi,

Can anyone suggest why... When accessing entries in Contacts I'm getting the following warning messages: 

CoreData: warning: dynamic accessors failed to find @property implementation for 'uniqueId' for entity ABCDRelatedName while resolving selector 'uniqueId' on class 'ABCDOwnedObject'.  Did you remember to declare it @dynamic or @synthesized in the @implementation ?

Or, similarly:

CoreData: warning: dynamic accessors failed to find @property implementation for 'name' for entity ABCDRelatedName while resolving selector 'name' on class 'ABCDOwnedObject'.  Did you remember to declare it @dynamic or @synthesized in the @implementation ?

My code seems to work, though.

macOS 10.12.2
py27-pyobjc 3.0.4
pyobjc-framework-AddressBook 3.2.1

[Pyobjc-dev] Trouble using DiskArbitration interface

[Merlijn B.W. W. <me...@ar...>]

Hi,

I'm working on porting some CD archival software from Ubuntu to OS X,
and I am trying to prevent OS X from mounting CDs, because it interferes
with the CD ripping process.

I've found that I can register with 'diskarbitrationd' and register a
callback when a disk is about to be mounted: using
DiskArbitration.da.DARegisterDiskMountApprovalCallback

Using this interface, I've been able to block mount requests
successfully. However, after some time, usually after blocking a few
mounts, my simple python program segfaults, and I am pretty sure it has
something to do with memory management. I've tried to find information
about this on the official documentation, but that was a bit hard to
find, apart from "Do not worry about reference counting".

I am trying to re-create code from here, but in python with pyobjc:
https://developer.apple.com/library/content/documentation/DriversKernelHardware/Conceptual/DiskArbitrationProgGuide/ArbitrationBasics/ArbitrationBasics.html
(section "Approving or Refusing a Request")


Example [1] will always segfault, after (or while) returning from
allow_mount.
Example [2] is hacky, and works for a while, and will then segfault, but
confirms my suspicion that memory management issues are causing these
problems.

Specifically, I fear that the dissenter object that I create is somehow
being freed or corrupted. However, if create it only once for the
program lifetime, I get similar issues - so it seems like it is simply
being freed at some point?

Triggering OS X to mount can be done like so:

	diskutil mount /dev/disk1

if the mount is blocked, it will say:

	Volume on disk1 failed to mount; if it has a partitioning scheme, use
"diskutil mountDisk"
	If the volume is damaged, try the "readOnly" option

And unmounting can be done like so:

	diskutil unmount /Volumes/Audio\ CD/

Any suggestions on how to tackle or debug this problem are most welcome. :-)

Regards,
Merlijn



Example 1:

Output:

$ python osxdiskarbitration-example.py
OSXDA: start_blocking started
OSXDA: Session: <DASession 0x7fc9a9fa2ee0 [0x1059e9ed0]>{id = python
[3595]:7947}
OSXDA: allow_mount call:  <DADisk 0x7fc9ab800600 [0x1059e9ed0]>{id =
/dev/disk1} 0
OSXDA: Blocking mount


Code:

from __future__ import print_function
import objc
objc.options.verbose = True
import DiskArbitration as da

@objc.callbackFor(da.DARegisterDiskMountApprovalCallback)
def allow_mount(disk, context):
    print('OSXDA: allow_mount call: ', disk, context)

    if True:
        #dissenter = da.DADissenterCreate(da.kCFAllocatorDefault,
        #                                  da.kDAReturnExclusiveAccess,
None)

        # We cannot pass kDAReturnExclusiveAccess initially, for some
reason, this raises:
        # ValueError: depythonifying 'int', got 'int' of wrong magnitude
        # So set it to 42, and change it later
        dissenter = da.DADissenterCreate(da.kCFAllocatorDefault, 42, None)
        dissenter["DAStatus"] = da.kDAReturnExclusiveAccess

        print('OSXDA: Blocking mount')
        return dissenter # Deny
    else:
        print('OSXDA: Allowing mount')
        return None # Allow

def start_blocking():
    print('OSXDA: start_blocking started')
    session = da.DASessionCreate(da.kCFAllocatorDefault)

    if not session:
        print('OSXDA: Failed to create session')
        exit(1)

    print('OSXDA: Session:', session)

    da.DASessionScheduleWithRunLoop(session, da.CFRunLoopGetMain(),
                                    da.kCFRunLoopCommonModes);
    #da.DASessionScheduleWithRunLoop(session, da.CFRunLoopGetCurrent(),
    #                                da.kCFRunLoopDefaultMode);

    # Register callback
    da.DARegisterDiskMountApprovalCallback(session, None, allow_mount, None)

    da.CFRunLoopRun()

    da.DASessionUnscheduleWithRunLoop(session, da.CFRunLoopGetCurrent(),
da.kCFRunLoopDefaultMode);

    print('OSXDA: Done with loop')

    CFRelease(session)

if __name__ == '__main__':
    start_blocking()


Example 2:

Output:

$ python osxdiskarbitration-example-2.py
OSXDA: start_blocking started
OSXDA: Session: <DASession 0x7f8e9bf56cf0 [0x1022aced0]>{id = python
[3644]:7947}
OSXDA: allow_mount call:  <DADisk 0x7f8e9be73340 [0x1022aced0]>{id =
/dev/disk1} 0
OSXDA: Blocking mount
OSXDA: allow_mount call:  <DADisk 0x7f8e9bd052e0 [0x1022aced0]>{id =
/dev/disk1} 0
OSXDA: Blocking mount
OSXDA: allow_mount call:  <DADisk 0x7f8e9be73340 [0x1022aced0]>{id =
/dev/disk1} 0
OSXDA: Blocking mount
OSXDA: allow_mount call:  <DADisk 0x7f8e9be73340 [0x1022aced0]>{id =
/dev/disk1} 0
OSXDA: Blocking mount
OSXDA: allow_mount call:  <DADisk 0x7f8e9be73b80 [0x1022aced0]>{id =
/dev/disk1} 0
OSXDA: Blocking mount
OSXDA: allow_mount call:  <DADisk 0x7f8e9be75240 [0x1022aced0]>{id =
/dev/disk1} 0
Segmentation fault: 11

Code:

from __future__ import print_function
import objc
objc.options.verbose = True
import DiskArbitration as da

memhack = []

@objc.callbackFor(da.DARegisterDiskMountApprovalCallback)
def allow_mount(disk, context):
    print('OSXDA: allow_mount call: ', disk, context)

    if True:
        #dissenter = da.DADissenterCreate(da.kCFAllocatorDefault,
        #                                  da.kDAReturnExclusiveAccess,
None)

        # We cannot pass kDAReturnExclusiveAccess initially, for some
reason, this raises:
        # ValueError: depythonifying 'int', got 'int' of wrong magnitude
        # So set it to 42, and change it later
        dissenter = da.DADissenterCreate(da.kCFAllocatorDefault, 42, None)
        dissenter["DAStatus"] = da.kDAReturnExclusiveAccess
        memhack.append(dissenter)

        print('OSXDA: Blocking mount')
        return dissenter # Deny
    else:
        print('OSXDA: Allowing mount')
        return None # Allow

def start_blocking():
    print('OSXDA: start_blocking started')
    session = da.DASessionCreate(da.kCFAllocatorDefault)

    if not session:
        print('OSXDA: Failed to create session')
        exit(1)

    print('OSXDA: Session:', session)

    da.DASessionScheduleWithRunLoop(session, da.CFRunLoopGetMain(),
                                    da.kCFRunLoopCommonModes);
    #da.DASessionScheduleWithRunLoop(session, da.CFRunLoopGetCurrent(),
    #                                da.kCFRunLoopDefaultMode);

    # Register callback
    da.DARegisterDiskMountApprovalCallback(session, None, allow_mount, None)

    da.CFRunLoopRun()

    da.DASessionUnscheduleWithRunLoop(session, da.CFRunLoopGetCurrent(),
da.kCFRunLoopDefaultMode);

    print('OSXDA: Done with loop')

    CFRelease(session)

if __name__ == '__main__':
    start_blocking()

Re: [Pyobjc-dev] [Pythonmac-SIG] py2app release delayed

[Barry S. <ba...@ba...>]

> On 27 Dec 2016, at 19:36, Ronald Oussoren <ron...@ma...> wrote:
> 
> 
>> On 21 Dec 2016, at 00:02, Barry Scott <ba...@ba... <mailto:ba...@ba...>> wrote:
>> 
>>> 
>>> On 18 Dec 2016, at 20:39, Ronald Oussoren <ron...@ma... <mailto:ron...@ma...>> wrote:
>>> 
>>> Hi,
>>> 
>>> I had hoped to release a new version of py2app today, but didn’t due to problems with macholib that resulted in broken application bundles. The good news is that I found the cause of that breakage and reverted the patch that caused it.
>>> 
>>> I did fix a number of bugs on the tracker last week (the number of open issues decreased from 94 to 72), and implemented a useful new feature: support for “@loader_path” in shared libraries, which is used in wheels processed with delocate <https://github.com/matthew-brett/delocate/blob/master/delocate/delocating.py <https://github.com/matthew-brett/delocate/blob/master/delocate/delocating.py>> such as the wheels for Pillow.
>>> 
>>> Because this is turning into a fairly large release I’d appreciate if people could test the code in the repository with their applications. To install first install altgraph-0.13, then install modulegraph, macholib and py2app from their bitbucket repositories (https://bitbucket.org/ronaldoussoren/modulegraph <https://bitbucket.org/ronaldoussoren/modulegraph>, https://bitbucket.org/ronaldoussoren/macholib <https://bitbucket.org/ronaldoussoren/macholib> and https://bitbucket.org/ronaldoussoren/py2app <https://bitbucket.org/ronaldoussoren/py2app>).
>>> 
>>> There’s still a fairly large number of open issues for py2app, but those will have to wait for a later time (which hopefully be a lot sooner than the time it took me to get from the previous release to this point).
>>> 
>> 
>> Thanks for working on an update. I know you time is limited, however I hope you can comment on these questions about py2app.
>> I was looking at contributing patches but found, as you did that macholib was very broken so gave up patching and hacked workarounds.
>> 
>> I’m using py2app to package a couple of apps that use PyQt and pytz.
>> 
>> I found that the resulting app  has the .dylib files in the python35.zip.
>> Is that correct? I had assumed that .dylib files need to be in the .app
>> as files, is there a trick to run them out of the .zip file?
> 
> That’s not supposed to happen. Are the dylibs part of a python package? If so, are these loaded by C extensions or included as data files (for example because ctypes is used to load the dylib)? 
> 
> A bug report on bitbucket with a sample project that demonstrates the problem would be appraised. I cannot promise that I’ll promptly fix the issue, but a sample project would make fixing this a lot easier.

Will do.

It looks like for PyQt5 you put the .so files you find in to the app ion Contents/Resources/lib/python3.5/lib-dynload/PyQt5/Qt.so etc.
But PyQt5 will not work without a lot of other files from the packager also being files on disk. They are all in the python35.zip.

> 
> As an aside to this: I’m considering to remove the site-packages.zip file from the app bundle and store everything outside off zipfiles. A lot of code works inside zipfiles, but there are too many exceptions and with the transition from eggs to wheels even less packages will care to document whether or not they work with their code in zipfiles. 

If you dropped the ZIP, or a option to not use it, then this bug wold be fixed.
Otherwise I have to tell py2app that PyQt5 must be on disk not in ZIP.

>> 
>> I have been copying in the PyQt .dylib, plugins etc into the .app with
>> a script that adds these in Contents/Frameworks etc after fixing up the RPATHs.
>> 
>> For pytz to work in a py2app .app pkg_resources needs to work and it
>> does not. Is this a known issue? I worked around it with a stub pkg_resources
>> package that reached into the python35.zip and pulled out the zoneinfo files.
> 
> I have an issue about copying enough information into the application to ensure pkg_resources.require works, but haven’t gotten around to doing the work for that because I don’t need the feature myself. 
> 
> AFAIK pkg_resources should work for accessing datafiles though. Could you file a bug for the pytz problem on py2app’s tracker? 
> 

I also see pkg_resources broken and ship a workaround: https://github.com/barry-scott/scm-workbench/blob/master/Source/Common/wb_date.py <https://github.com/barry-scott/scm-workbench/blob/master/Source/Common/wb_date.py>


>> 
>> It seems that py2app will package up all the files in a package, not just the
>> .py files. Is that the algorithm that is used?
> 
> That’s correct. All files in the directory of a python package are assumed to be important. 
> 
> BTW.  None of these fixes will be in the next release of py2app, but I really hope to find a way to do more py2app maintenance next year (instead of basically just doing so during vacations). 

I guess all the py2app related repo’s are working now. (You fixed a show stopper in macho lib recently).
I’ll look to shipping you patches with the bug reports. I have experience with type of python packaging software, but for Linux and windows.

Barry

Re: [Pyobjc-dev] [Pythonmac-SIG] py2app release delayed

[Ronald O. <ron...@ma...>]

<html><head></head><body dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><meta http-equiv="Content-Type" content="text/html charset=utf-8"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 27 Dec 2016, at 22:38, Chris Barker &lt;<a href="mailto:chr...@no..." class="">chr...@no...</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">On Tue, Dec 27, 2016 at 11:36 AM, Ronald Oussoren <span dir="ltr" class="">&lt;<a href="mailto:ron...@ma..." target="_blank" class="">ron...@ma...</a>&gt;</span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class="">As an aside to this: I’m considering to remove the site-packages.zip file from the app bundle and store everything outside off zipfiles. A lot of code works inside zipfiles, but there are too many exceptions and with the transition from eggs to wheels even less packages will care to document whether or not they work with their code in zipfiles.&nbsp;</div></div></blockquote><div class=""><br class=""></div><div class="">I think this is a good idea -- these days, size really only matters when you're shipping the app, not when it's on disk (or SSD) -- so why bother with the zip?</div></div></div></div></div></blockquote><div><br class=""></div>Speed (loading from zipfiles tends to be slightly faster), and slightly fewer opportunities of other tools to mess up. &nbsp;People also tend to like the fact that code is more hidden from users.&nbsp;</div><div><br class=""></div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></div><div class="">&nbsp;&gt; I have an issue about copying enough information into the application to ensure pkg_resources.require works, but haven’t gotten around to doing the work for that because I don’t need the feature myself.&nbsp;</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><br class=""></div><div class="">AFAIK pkg_resources should work for accessing datafiles though. Could you file a bug for the pytz problem on py2app’s tracker?&nbsp;</div></div></blockquote><div class=""><br class=""></div><div class="">pkg_resources is a pain in general, and particularly always has been with py2app and the like.</div></div></div></div></div></blockquote><div><br class=""></div>That’s not my experience, and I’ve tried to ensure that using pkg_resources to access resources in the current python package would work as that solves the problem w.r.t. zipping data files for at least some packages.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></div><div class="">but I've usually gotten it to work OK by explicitly listing the package to be included, so that py2app will bundle the whole thing.</div></div></div></div></div></blockquote><div><br class=""></div>I generally consider the need to explicitly list packages to be included as a bug in py2app, that is I strive to make py2app comprehensive enough to automatically include enough stuff in the app bundles. &nbsp;Py2app obviously isn’t anywhere near that at the moment :-(</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><blockquote type="cite" class=""><div class=""><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><div class=""><br style="font-family:Monaco" class=""><span style="font-family:Monaco" class="">It seems that py2app will package up all the files in a package, not just the</span><br style="font-family:Monaco" class=""><span style="font-family:Monaco" class="">.py files. Is that the algorithm that is used?</span></div></div></div></blockquote><div class=""><br class=""></div>That’s correct. All files in the directory of a python package are assumed to be important.&nbsp;</div></div></blockquote><div class=""><br class=""></div><div class="">which is why it usually works OK for things like pytz. :-(</div></div></div></div></div></blockquote><div><br class=""></div>That’s intentional.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></div><div class="">-CHB</div><div class=""><br class=""></div></div><div class=""><br class=""></div>-- <br class=""><div class="gmail_signature" data-smartmail="gmail_signature"><br class="">Christopher Barker, Ph.D.<br class="">Oceanographer<br class=""><br class="">Emergency Response Division<br class="">NOAA/NOS/OR&amp;R &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;(206) 526-6959&nbsp;&nbsp; voice<br class="">7600 Sand Point Way NE &nbsp;&nbsp;(206) 526-6329&nbsp;&nbsp; fax<br class="">Seattle, WA &nbsp;98115 &nbsp; &nbsp; &nbsp;&nbsp;(206) 526-6317&nbsp;&nbsp; main reception<br class=""><br class=""><a href="mailto:Chr...@no..." target="_blank" class="">Chr...@no...</a></div>
</div></div>
------------------------------------------------------------------------------<br class="">Check out the vibrant tech community on one of the world's most <br class="">engaging tech sites, <a href="http://slashdot.org/" class="">SlashDot.org</a>! <a href="http://sdm.link/slashdot_______________________________________________" class="">http://sdm.link/slashdot_______________________________________________</a><br class="">Pyobjc-dev mailing list<br class=""><a href="mailto:Pyo...@li..." class="">Pyo...@li...</a><br class="">https://lists.sourceforge.net/lists/listinfo/pyobjc-dev<br class=""></div></blockquote></div><br class=""></div></body></html>

Re: [Pyobjc-dev] [Pythonmac-SIG] py2app release delayed

[Chris B. <chr...@no...>]

On Tue, Dec 27, 2016 at 11:36 AM, Ronald Oussoren <ron...@ma...>
wrote:

> As an aside to this: I’m considering to remove the site-packages.zip file
> from the app bundle and store everything outside off zipfiles. A lot of
> code works inside zipfiles, but there are too many exceptions and with the
> transition from eggs to wheels even less packages will care to document
> whether or not they work with their code in zipfiles.
>

I think this is a good idea -- these days, size really only matters when
you're shipping the app, not when it's on disk (or SSD) -- so why bother
with the zip?

 > I have an issue about copying enough information into the application to
ensure pkg_resources.require works, but haven’t gotten around to doing the
work for that because I don’t need the feature myself.

>
> AFAIK pkg_resources should work for accessing datafiles though. Could you
> file a bug for the pytz problem on py2app’s tracker?
>

pkg_resources is a pain in general, and particularly always has been with
py2app and the like.

but I've usually gotten it to work OK by explicitly listing the package to
be included, so that py2app will bundle the whole thing.


> It seems that py2app will package up all the files in a package, not just
> the
> .py files. Is that the algorithm that is used?
>
>
> That’s correct. All files in the directory of a python package are assumed
> to be important.
>

which is why it usually works OK for things like pytz. :-(

-CHB


-- 

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

Chr...@no...

Re: [Pyobjc-dev] [Pythonmac-SIG] py2app release delayed

[Ronald O. <ron...@ma...>]

> On 21 Dec 2016, at 00:02, Barry Scott <ba...@ba...> wrote:
> 
>> 
>> On 18 Dec 2016, at 20:39, Ronald Oussoren <ron...@ma... <mailto:ron...@ma...>> wrote:
>> 
>> Hi,
>> 
>> I had hoped to release a new version of py2app today, but didn’t due to problems with macholib that resulted in broken application bundles. The good news is that I found the cause of that breakage and reverted the patch that caused it.
>> 
>> I did fix a number of bugs on the tracker last week (the number of open issues decreased from 94 to 72), and implemented a useful new feature: support for “@loader_path” in shared libraries, which is used in wheels processed with delocate <https://github.com/matthew-brett/delocate/blob/master/delocate/delocating.py <https://github.com/matthew-brett/delocate/blob/master/delocate/delocating.py>> such as the wheels for Pillow.
>> 
>> Because this is turning into a fairly large release I’d appreciate if people could test the code in the repository with their applications. To install first install altgraph-0.13, then install modulegraph, macholib and py2app from their bitbucket repositories (https://bitbucket.org/ronaldoussoren/modulegraph <https://bitbucket.org/ronaldoussoren/modulegraph>, https://bitbucket.org/ronaldoussoren/macholib <https://bitbucket.org/ronaldoussoren/macholib> and https://bitbucket.org/ronaldoussoren/py2app <https://bitbucket.org/ronaldoussoren/py2app>).
>> 
>> There’s still a fairly large number of open issues for py2app, but those will have to wait for a later time (which hopefully be a lot sooner than the time it took me to get from the previous release to this point).
>> 
> 
> Thanks for working on an update. I know you time is limited, however I hope you can comment on these questions about py2app.
> I was looking at contributing patches but found, as you did that macholib was very broken so gave up patching and hacked workarounds.
> 
> I’m using py2app to package a couple of apps that use PyQt and pytz.
> 
> I found that the resulting app  has the .dylib files in the python35.zip.
> Is that correct? I had assumed that .dylib files need to be in the .app
> as files, is there a trick to run them out of the .zip file?

That’s not supposed to happen. Are the dylibs part of a python package? If so, are these loaded by C extensions or included as data files (for example because ctypes is used to load the dylib)? 

A bug report on bitbucket with a sample project that demonstrates the problem would be appraised. I cannot promise that I’ll promptly fix the issue, but a sample project would make fixing this a lot easier.

As an aside to this: I’m considering to remove the site-packages.zip file from the app bundle and store everything outside off zipfiles. A lot of code works inside zipfiles, but there are too many exceptions and with the transition from eggs to wheels even less packages will care to document whether or not they work with their code in zipfiles. 

> 
> I have been copying in the PyQt .dylib, plugins etc into the .app with
> a script that adds these in Contents/Frameworks etc after fixing up the RPATHs.
> 
> For pytz to work in a py2app .app pkg_resources needs to work and it
> does not. Is this a known issue? I worked around it with a stub pkg_resources
> package that reached into the python35.zip and pulled out the zoneinfo files.

I have an issue about copying enough information into the application to ensure pkg_resources.require works, but haven’t gotten around to doing the work for that because I don’t need the feature myself. 

AFAIK pkg_resources should work for accessing datafiles though. Could you file a bug for the pytz problem on py2app’s tracker? 

> 
> It seems that py2app will package up all the files in a package, not just the
> .py files. Is that the algorithm that is used?

That’s correct. All files in the directory of a python package are assumed to be important. 

BTW.  None of these fixes will be in the next release of py2app, but I really hope to find a way to do more py2app maintenance next year (instead of basically just doing so during vacations). 

Ronald

Re: [Pyobjc-dev] [Pythonmac-SIG] py2app release delayed

[Barry S. <ba...@ba...>]

> On 18 Dec 2016, at 20:39, Ronald Oussoren <ron...@ma...> wrote:
> 
> Hi,
> 
> I had hoped to release a new version of py2app today, but didn’t due to problems with macholib that resulted in broken application bundles. The good news is that I found the cause of that breakage and reverted the patch that caused it.
> 
> I did fix a number of bugs on the tracker last week (the number of open issues decreased from 94 to 72), and implemented a useful new feature: support for “@loader_path” in shared libraries, which is used in wheels processed with delocate <https://github.com/matthew-brett/delocate/blob/master/delocate/delocating.py <https://github.com/matthew-brett/delocate/blob/master/delocate/delocating.py>> such as the wheels for Pillow.
> 
> Because this is turning into a fairly large release I’d appreciate if people could test the code in the repository with their applications. To install first install altgraph-0.13, then install modulegraph, macholib and py2app from their bitbucket repositories (https://bitbucket.org/ronaldoussoren/modulegraph <https://bitbucket.org/ronaldoussoren/modulegraph>, https://bitbucket.org/ronaldoussoren/macholib <https://bitbucket.org/ronaldoussoren/macholib> and https://bitbucket.org/ronaldoussoren/py2app <https://bitbucket.org/ronaldoussoren/py2app>).
> 
> There’s still a fairly large number of open issues for py2app, but those will have to wait for a later time (which hopefully be a lot sooner than the time it took me to get from the previous release to this point).
> 

Thanks for working on an update. I know you time is limited, however I hope you can comment on these questions about py2app.
I was looking at contributing patches but found, as you did that macholib was very broken so gave up patching and hacked workarounds.

I’m using py2app to package a couple of apps that use PyQt and pytz.

I found that the resulting app  has the .dylib files in the python35.zip.
Is that correct? I had assumed that .dylib files need to be in the .app
as files, is there a trick to run them out of the .zip file?

I have been copying in the PyQt .dylib, plugins etc into the .app with
a script that adds these in Contents/Frameworks etc after fixing up the RPATHs.

For pytz to work in a py2app .app pkg_resources needs to work and it
does not. Is this a known issue? I worked around it with a stub pkg_resources
package that reached into the python35.zip and pulled out the zoneinfo files.

It seems that py2app will package up all the files in a package, not just the
.py files. Is that the algorithm that is used?


> Ronald
> _______________________________________________
> Pythonmac-SIG maillist  -  Pyt...@py...
> https://mail.python.org/mailman/listinfo/pythonmac-sig
> unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pyobjc-dev] [Pythonmac-SIG] py2app release delayed

[Glyph L. <gl...@tw...>]

> On Dec 18, 2016, at 12:39 PM, Ronald Oussoren <ron...@ma...> wrote:
> 
> Hi,
> 
> I had hoped to release a new version of py2app today, but didn’t due to problems with macholib that resulted in broken application bundles. The good news is that I found the cause of that breakage and reverted the patch that caused it.
> 
> I did fix a number of bugs on the tracker last week (the number of open issues decreased from 94 to 72), and implemented a useful new feature: support for “@loader_path” in shared libraries, which is used in wheels processed with delocate <https://github.com/matthew-brett/delocate/blob/master/delocate/delocating.py <https://github.com/matthew-brett/delocate/blob/master/delocate/delocating.py>> such as the wheels for Pillow.
> 
> Because this is turning into a fairly large release I’d appreciate if people could test the code in the repository with their applications. To install first install altgraph-0.13, then install modulegraph, macholib and py2app from their bitbucket repositories (https://bitbucket.org/ronaldoussoren/modulegraph <https://bitbucket.org/ronaldoussoren/modulegraph>, https://bitbucket.org/ronaldoussoren/macholib <https://bitbucket.org/ronaldoussoren/macholib> and https://bitbucket.org/ronaldoussoren/py2app <https://bitbucket.org/ronaldoussoren/py2app>).

Can you translate these URLs into (pinned) URLs suitable for a requirements.txt?  I'm not used to doing this with hg or bitbucket.  If so I'd be happy to test with Mimic.

-g

[Pyobjc-dev] py2app release delayed

[Ronald O. <ron...@ma...>]

Hi,

I had hoped to release a new version of py2app today, but didn’t due to problems with macholib that resulted in broken application bundles. The good news is that I found the cause of that breakage and reverted the patch that caused it.

I did fix a number of bugs on the tracker last week (the number of open issues decreased from 94 to 72), and implemented a useful new feature: support for “@loader_path” in shared libraries, which is used in wheels processed with delocate <https://github.com/matthew-brett/delocate/blob/master/delocate/delocating.py <https://github.com/matthew-brett/delocate/blob/master/delocate/delocating.py>> such as the wheels for Pillow.

Because this is turning into a fairly large release I’d appreciate if people could test the code in the repository with their applications. To install first install altgraph-0.13, then install modulegraph, macholib and py2app from their bitbucket repositories (https://bitbucket.org/ronaldoussoren/modulegraph <https://bitbucket.org/ronaldoussoren/modulegraph>, https://bitbucket.org/ronaldoussoren/macholib <https://bitbucket.org/ronaldoussoren/macholib> and https://bitbucket.org/ronaldoussoren/py2app <https://bitbucket.org/ronaldoussoren/py2app>).

There’s still a fairly large number of open issues for py2app, but those will have to wait for a later time (which hopefully be a lot sooner than the time it took me to get from the previous release to this point).

Ronald

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

[Ronald O. <ron...@ma...>]

> On 15 Dec 2016, at 21:41, Cosimo Lupo <cos...@da...> wrote:
> 
> +1 on having the official Python.org distribution be a standalone Python.app that users could just drag-and-drop like with the rest of native non-AppStore apps!

A Python.app from python.org <http://python.org/> should be a long term plan at best, it would be better to start work on this outside of constraints of CPython (e.g. not being able to use libraries outside of the stdlib and only shipping feature updates with major releases). 

> 
> (I wish Apple shipped macOS with Python 3…)

I’ve mixed feelings about that, on the one hand having Python 3 available by default would be cool, but on the other hand you’d have to rely on Apple to keep that software up to date and Apple tends to only ship security updates between major releases. That’s not too bad for Python 2.7, but is less useful for 3.x.

> 
> And thanks a lot Ronald for the PyObjC wheels on PyPi :D

That turned out to be a lot less work than I expected, I should have done the work a long time ago ;-)

Ronald

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

[Cosimo L. <cos...@da...>]

+1 on having the official Python.org distribution be a standalone Python.app that users could just drag-and-drop like with the rest of native non-AppStore apps!

(I wish Apple shipped macOS with Python 3...)

And thanks a lot Ronald for the PyObjC wheels on PyPi :D

Cheers

--
Cosimo Lupo

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

[Ronald O. <ron...@ma...>]

> On 15 Dec 2016, at 07:25, Christopher Barker <pyt...@gm...> wrote:
> 
> On Wed, Dec 14, 2016 at 5:32 PM, Glyph Lefkowitz <gl...@tw... <mailto:gl...@tw...>> wrote:
> 
>> On Dec 14, 2016, at 9:44 AM, Chris Barker <chr...@no... <mailto:chr...@no...>> 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

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

[Christopher B. <pyt...@gm...>]

On Wed, Dec 14, 2016 at 5:32 PM, Glyph Lefkowitz <gl...@tw...>
wrote:

>
> On Dec 14, 2016, at 9:44 AM, Chris Barker <chr...@no...> 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 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.


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.


Anyway, it should be easy to see how well the new wheels work with conda --
and/or make a conda recipe -- maybe I'll get to it soon.

-CHB

-- 
Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython

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

[Glyph L. <gl...@tw...>]

> On Dec 14, 2016, at 9:44 AM, Chris Barker <chr...@no...> 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; if you don't have an app bundle then many frameworks will fail to initialize, or will start behaving in bizarre ways.  APIs like NSUserNotificationCenter will just silently do nothing, CoreLocation won't respond... it's always very confusing and hard to troubleshoot.

That said, I don't think the framework/non-framework-ness of the build is relevant to the ABI; the wheels should work fine just from a "will they link and run" perspective.  And many CoreFoundation APIs definitely work without an app bundle, so, not completely useless :-).

-glyph

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

[Chris B. <chr...@no...>]

On Tue, Dec 13, 2016 at 11:16 AM, Glyph Lefkowitz <gl...@tw...>
wrote:

> If we were to add s PyObjC build to conda-forge, the full stack should
> "just work".
>
> And conda forge has s CI system set up to auto build for various python
> versions....
>
> http://conda-forge.github.io/#add_recipe
>
>
> Why would this be necessary?  Can't conda just install the wheels from
> PyPI?
>

Well, maybe -- conda has grown better support for pip lately, so it may
work OK.

Back in the day, mixing conda and pipi got ugly fast, so I far prefer to
make a native conda package for everything.

conda also has a non-framework build of Python -- not sure if that would
cause any issues with the wheels.

-CHB



-- 

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

Chr...@no...

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

[Glyph L. <gl...@tw...>]

> On Dec 13, 2016, at 8:37 AM, Christopher Barker <pyt...@gm...> wrote:
> 
> Personally, I have avoided all this mess the last couple years by using conda (miniconda install). It does a nice job of keeping entirely separate from the system ( or any other) python, and it can manage non-python libs as well, so you don't need Brew. And it has environments that are like virtualenv, but with the C libs isolated as well.
> 
> Between the default channel, conda-forge, and pip for pure python packages, there is a lot available.
> 
> If we were to add s PyObjC build to conda-forge, the full stack should "just work".
> 
> And conda forge has s CI system set up to auto build for various python versions....
> 
> http://conda-forge.github.io/#add_recipe <http://conda-forge.github.io/#add_recipe>
Why would this be necessary?  Can't conda just install the wheels from PyPI?

-glyph

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

[Christopher B. <pyt...@gm...>]

Personally, I have avoided all this mess the last couple years by using
conda (miniconda install). It does a nice job of keeping entirely separate
from the system ( or any other) python, and it can manage non-python libs
as well, so you don't need Brew. And it has environments that are like
virtualenv, but with the C libs isolated as well.

Between the default channel, conda-forge, and pip for pure python packages,
there is a lot available.

If we were to add s PyObjC build to conda-forge, the full stack should
"just work".

And conda forge has s CI system set up to auto build for various python
versions....

http://conda-forge.github.io/#add_recipe

- CHB





> >>>>>> prediction about setuptools' behavior :)
>
> >>>>>
>
> >>>>> This seems to be Apple's doing.  AFAICT, 10.12 is shipping with this
>
> >>>>> Extras.pth file in /Library/Python/2.7; it's something new.  And,
>
> >>>>> unfortunately, due to https://bugs.python.org/issue4865, the
>
> >>>>> site-packages directory for the system Python 2.7 is included in
>
> >>>>> sys.path along with the non-system framework Python site-packages.
>
> >>>>
>
> >>> So, a little more data:
>
> >>>
>
> >>> If you rename or remove /Library/Python/2.7/site-packages/Extras.pth
>
> >>> then pip2 works.
>
> >>
>
> >> What do you mean by "works"?  Your original error is pip refusing to
>
> >> upgrade pyObjC because to upgrade pyObjC it has to delete the old
>
> >> version, and pyObjC is part of the operating system, and it can't delete
>
> >> the installed version.  This is correct; the error reporting could be
>
> >> nicer, but pip is not broken.  Don't mess with files in /System.
>
> >>
>
> >> The suggestion to use virtualenv isn't really optional.  If you really,
>
> >> really want things to be importable by a bare 'python', not inside a
>
> >> venv, `pip install --user` is another option you might have.
>
> >>
>
> >>> *However*, lots of other stuff breaks -- anything that uses Apple's
>
> >>> python and relies on access to pyobjc and the frameworks (e.g.,
>
> >>> TextMate's latex package).
>
> >>
>
> >> Yep, that's expected behavior.  This is exactly why Apple is making it
>
> >> increasingly difficult to screw up /System.  Apps can, should, and do
>
> >> rely upon the libraries installed on the system.
>
> >>
>
> >>> What I don't understand is: what changed from Yosemite? This file did
>
> >>> not exist before Sierra, but there were no problems with (Apple)
>
> >>> python accessing these packages.
>
> >>
>
> >> Do you mean from El Capitan?
>
> >
>
> > Yes, sorry.
>
> >
>
> >> This file previously existed in a different location, and (while the
>
> >> particulars stubbornly refuse to stick to memory for me, for some
>
> >> reason) this new location is the one generally preferred by the python
>
> >> packaging maintainers.
>
> >>
>
> >>> (Or is there something unique in my setup that is causing this? I kind
>
> >>> of doubt it, but it's possible...)
>
> >>>
>
> >>> Does anyone have any insight?
>
> >>
>
> >> If you really, really, really want to do this in such a way that /System
>
> >> stuff is only present for /System's python and not for python.org
>
> >> <http://python.org>'s, you can take advantage of the 'import' hack
>
> >> <https://docs.python.org/2/library/site.html>, and
>
> >> rewrite /Library/Python/2.7/site-packages/Extras.pth to _conditionally_
>
> >> add those entries to sys.path, checking sys.executable or some other
>
> >> fingerprint.
>
> >>
>
> >> But: don't.  Given that system python and python.org <http://python.org
> >
>
> >> python share /Library and ~/Library, they're not /really/ distinct
>
> >> environments, and things installed into one will show up in the other,
>
> >> so excluding the /System directories on one but not the other will just
>
> >> cause other, more confusing issues.
>
> >>
>
> >> In conclusion: just use virtualenv.  This is not a problem that should
>
> >> be fixed.
>
> >
>
> > I agree that this would solve all of the problems, at the cost of some
> minor startup pain.
>
> >
>
> > But one nice thing about the python.org builds is that, for the last
> few releases, they just worked out of the box, where by "worked" I mean
> that (as far as I can tell) the system Python saw its own packages, and the
> python.org build saw its own packages, and (python.org) pip didn't seem
> to care about the system files.
>
>
>
> Trust me, they didn't just work :).  There were numerous potential
> misconfigurations that dealt with conflicts between system python packages
> and user-installed packages.  Installing stuff into the global environment
> has always been a bad idea.  Some system files would be on the path, some
> wouldn't, and things installed into one environment would bleed over into
> the other.
>
>
>
> > And I suppose I still don't understand exactly why that changed with
> Sierra, and whether the change is actually beneficial in any way whatever!
> (And whether it could only be fixed by Apple, or whether a change in the
> python.org build could do something about it.)
>
>
>
> I'm not sure as to the exact difference, but my basic understanding is
> that rather than failing silently and ignoring system-installed stuff, pip
> now reliably and correctly fails to upgrade system packages that are
> protected by SIP.
>
>
>
> > Sorry to keep harping on about it, but I find it hard to believe this is
> not a fairly widespread problem! (Well, I found at least one other
> complaint:
> https://jasonkratz.com/2016/09/25/python-2-7-on-the-mac-site-package-weirdness/
> )
>
>
>
> The problem is that we're not properly getting the message out about how
> to set up Python for development; venvs are increasingly graduating from
> "best practice" to "necessary to function", but I don't think users are
> getting the message.  (Case in point: this thread is still going :).)
> System packages are for system developers.  If you aren't shipping
> Python.org python itself, or working for apple on OS X, you should not be
> installing things into /Library or even as a user with *permission* to
> install things into /Library.
>
>
>
> -glyph
>
> _______________________________________________
>
> Pythonmac-SIG maillist  -  Pyt...@py...
>
> https://mail.python.org/mailman/listinfo/pythonmac-sig
>
> unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
>
>

Re: [Pyobjc-dev] Pyobjc-dev Digest, Vol 92, Issue 7

[John F. <joh...@ma...>]

Thank you, great news.

> On Dec 13, 2016, at 7:22 AM, pyo...@li... wrote:
> 
> Send Pyobjc-dev mailing list submissions to
> 	pyo...@li...
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
> or, via email, send a message with subject or body 'help' to
> 	pyo...@li...
> 
> You can reach the person managing the list at
> 	pyo...@li...
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Pyobjc-dev digest..."
> 
> 
> Today's Topics:
> 
>   1. Re: PyObjC 3.2.1 released (Andrew Jaffe)
>   2. Re: PyObjC 3.2.1 released (Andrew Jaffe)
>   3. Re: [Pythonmac-SIG] PyObjC 3.2.1 released (Ronald Oussoren)
>   4. Re: [Pythonmac-SIG] PyObjC and macOS 10.12 (Sierra)
>      (Ronald Oussoren)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Mon, 12 Dec 2016 20:06:41 +0000
> From: Andrew Jaffe <a.h...@gm...>
> Subject: Re: [Pyobjc-dev] PyObjC 3.2.1 released
> To: Ronald Oussoren <ron...@ma...>,	pyobjc-dev list
> 	<pyo...@li...>,	pythonmac-sig pythonmac-sig
> 	<pyt...@py...>
> Message-ID: <1e0...@gm...>
> Content-Type: text/plain; charset=windows-1252; format=flowed
> 
> Hi Ronald,
> 
> 
> On 12/12/2016 09:25, Ronald Oussoren wrote:
>> Hi,
>> 
>> I?ve just pushed PyObjC 3.2.1 to PyPI. This fixes a number of small
>> issues in PyObjC 3.2, but the primary new feature is that there are now
>> wheels on PyPI.
>> 
>> I?ve tested the wheels on OSX 10.12 with the Python.org
>> <http://Python.org> ?intel? installers (the default download option for
>> the OSX installers) and Homebrew. The wheels should also work fine with
>> older OSX releases.
>> 
> Thanks. I'll also note that when used with `pip2 install --upgrade 
> --ignore-installed` this solves the problem discussed a few weeks ago 
> regarding clashes with the Apple-installed version on Framework 
> (python.org) builds of Python. (Previously, `--ignore-installed` failed 
> for some of the packages.)
> 
> Yours,
> 
> Andrew
> 
> 
>> Ronald
>> 
>> 
>> ------------------------------------------------------------------------------
>> Developer Access Program for Intel Xeon Phi Processors
>> Access to Intel Xeon Phi processor-based developer platforms.
>> With one year of Intel Parallel Studio XE.
>> Training and support from Colfax.
>> Order your platform today.http://sdm.link/xeonphi
>> 
>> 
>> 
>> _______________________________________________
>> Pyobjc-dev mailing list
>> Pyo...@li...
>> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>> 
> 
> 
> 
> 
> ------------------------------
> 
> Message: 2
> Date: Mon, 12 Dec 2016 20:06:41 +0000
> From: Andrew Jaffe <a.h...@gm...>
> Subject: Re: [Pyobjc-dev] PyObjC 3.2.1 released
> To: pyo...@li...
> Cc: pyt...@py...
> Message-ID: <1e0...@gm...>
> Content-Type: text/plain; charset=windows-1252; format=flowed
> 
> Hi Ronald,
> 
> 
> On 12/12/2016 09:25, Ronald Oussoren wrote:
>> Hi,
>> 
>> I?ve just pushed PyObjC 3.2.1 to PyPI. This fixes a number of small
>> issues in PyObjC 3.2, but the primary new feature is that there are now
>> wheels on PyPI.
>> 
>> I?ve tested the wheels on OSX 10.12 with the Python.org
>> <http://Python.org> ?intel? installers (the default download option for
>> the OSX installers) and Homebrew. The wheels should also work fine with
>> older OSX releases.
>> 
> Thanks. I'll also note that when used with `pip2 install --upgrade 
> --ignore-installed` this solves the problem discussed a few weeks ago 
> regarding clashes with the Apple-installed version on Framework 
> (python.org) builds of Python. (Previously, `--ignore-installed` failed 
> for some of the packages.)
> 
> Yours,
> 
> Andrew
> 
> 
>> Ronald
>> 
>> 
>> ------------------------------------------------------------------------------
>> Developer Access Program for Intel Xeon Phi Processors
>> Access to Intel Xeon Phi processor-based developer platforms.
>> With one year of Intel Parallel Studio XE.
>> Training and support from Colfax.
>> Order your platform today.http://sdm.link/xeonphi
>> 
>> 
>> 
>> _______________________________________________
>> Pyobjc-dev mailing list
>> Pyo...@li...
>> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>> 
> 
> 
> 
> 
> 
> ------------------------------
> 
> Message: 3
> Date: Tue, 13 Dec 2016 09:49:09 +0100
> From: Ronald Oussoren <ron...@ma...>
> Subject: Re: [Pyobjc-dev] [Pythonmac-SIG] PyObjC 3.2.1 released
> To: Glyph Lefkowitz <gl...@tw...>
> Cc: pyobjc-dev list <pyo...@li...>,	pythonmac-sig
> 	pythonmac-sig <pyt...@py...>
> Message-ID: <C8A...@ma...>
> Content-Type: text/plain; charset="utf-8"
> 
> 
>> On 13 Dec 2016, at 04:02, Glyph Lefkowitz <gl...@tw...> wrote:
>> 
>> 
>>> On Dec 12, 2016, at 1:25 AM, Ronald Oussoren <ron...@ma... <mailto:ron...@ma...>> wrote:
>>> 
>>> Hi,
>>> 
>>> I?ve just pushed PyObjC 3.2.1 to PyPI. This fixes a number of small issues in PyObjC 3.2, but the primary new feature is that there are now wheels on PyPI. 
>>> 
>>> I?ve tested the wheels on OSX 10.12 with the Python.org <http://python.org/> ?intel? installers (the default download option for the OSX installers) and Homebrew. The wheels should also work fine with older OSX releases. 
>> 
>> Thank you *so* much, Ronald :D.  I installed pyobjc onto my laptop just now and didn't even have to go get an icepack out of the freezer first :-).  In under ten seconds, no less, for both python 3.5 and python 2.7.  A glorious day, to be sure.
> Great to hear that.
> 
>> 
>> One minor note - I do notice that the 'pyobjc' package itself has no wheel, even though all its dependents do.  Any chance you could upload 2.7/3.5 wheels for that as well?  It would just complete the set :-).
> 
> That is intentional. The setup.py for the package pyobjc calculates the ?install_requires? list at runtime to ensure it will only install framework wrappers for frameworks that are actually present.  It might be possible to use conditional dependencies for that (see [1]), but I haven?t checked yet if those compare version numbers as structured data or strings.  PEP 426 seems to indicate they are just strings, and that would be less useful.   
> 
> I guess a wheel for the ?pyobjc? package could just depend on all framework wrappers, that would install some code that isn?t relevant for the current machine but wouldn?t result in install failures (which could happen when installing all framework wrappers from source).  
> 
> Ronald
> 
> [1]: http://wheel.readthedocs.io/en/latest/#defining-conditional-dependencies
>> 
>> Thanks again; this is fabulous,
>> 
>> -glyph
>> 
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most 
>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot_______________________________________________
>> Pyobjc-dev mailing list
>> Pyo...@li...
>> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
> 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> 
> ------------------------------
> 
> Message: 4
> Date: Tue, 13 Dec 2016 12:20:09 +0100
> From: Ronald Oussoren <ron...@me...>
> Subject: Re: [Pyobjc-dev] [Pythonmac-SIG] PyObjC and macOS 10.12
> 	(Sierra)
> To: Glyph Lefkowitz <gl...@tw...>
> Cc: Andrew Jaffe <a.h...@gm...>,
> 	"pyo...@li..." <pyo...@li...>,
> 	Jack Jansen <jac...@cw...>,	"pyt...@py..."
> 	<pyt...@py...>
> Message-ID: <DC6...@me...>
> Content-Type: text/plain; charset="utf-8"
> 
> 
>> On 14 Sep 2016, at 00:28, Glyph Lefkowitz <gl...@tw...> wrote:
>> 
>> 
>>> On Sep 13, 2016, at 3:05 PM, Andrew Jaffe <a.h...@gm... <mailto:a.h...@gm...>> wrote:
>>> 
>>> But this is the framework (non-apple!) build!?
>> 
>> "framework build" refers to the way that Python is built.  Apple's python, Python.org <http://python.org/>'s python, and Homebrew's python are all framework builds.  So, to be clear: this is python.org <http://python.org/> python?
>> 
>>> And, again: why isn?t everyone seeing this all the time? (And why didn?t I see it before?)
>> 
>> There's probably a .pth file somewhere that is stuffing Extras on your sys.path.  easy_install (especially older versions) is notorious for creating such things in ways that are hard to inspect for.  My usual recommendation at this point is to blow away _everything_ in /Library/Python, ~/Library/Python, ~/.local/lib/python*, and /Library/Frameworks/Python.framework and then reinstall from scratch.  (Thanks to SIP you don't need to blow away anything in /System anymore; hooray!)
> 
> It should be enough to remove ?/Library/Python? from the list of site packages in the non-system install of Python, it is added at the end of setsitepackages() in site.py. This should be done before running any code (particularly the ensurepip tool).  That would remove the directory containing the Extras.pth on 10.12, and hence remove the conflict between Apple stuff and user provided stuff.   Doing this with the python.org installer requires some care, as it will by default run ensurepip during the installation (but this can be turned off).
> 
> According to issue 28440 /Library/Python/2.7/site-packages will no longer be treated as a site-packages directory in a future release of 2.7.
> 
> Ronald
> 
>> -glyph
>> _______________________________________________
>> Pythonmac-SIG maillist  -  Pyt...@py...
>> https://mail.python.org/mailman/listinfo/pythonmac-sig
>> unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
> 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> 
> ------------------------------
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most 
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> 
> ------------------------------
> 
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
> 
> 
> End of Pyobjc-dev Digest, Vol 92, Issue 7
> *****************************************

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

[Ronald O. <ron...@me...>]

> On 14 Sep 2016, at 00:28, Glyph Lefkowitz <gl...@tw...> wrote:
> 
> 
>> On Sep 13, 2016, at 3:05 PM, Andrew Jaffe <a.h...@gm... <mailto:a.h...@gm...>> wrote:
>> 
>> But this is the framework (non-apple!) build!…
> 
> "framework build" refers to the way that Python is built.  Apple's python, Python.org <http://python.org/>'s python, and Homebrew's python are all framework builds.  So, to be clear: this is python.org <http://python.org/> python?
> 
>> And, again: why isn’t everyone seeing this all the time? (And why didn’t I see it before?)
> 
> There's probably a .pth file somewhere that is stuffing Extras on your sys.path.  easy_install (especially older versions) is notorious for creating such things in ways that are hard to inspect for.  My usual recommendation at this point is to blow away _everything_ in /Library/Python, ~/Library/Python, ~/.local/lib/python*, and /Library/Frameworks/Python.framework and then reinstall from scratch.  (Thanks to SIP you don't need to blow away anything in /System anymore; hooray!)

It should be enough to remove “/Library/Python” from the list of site packages in the non-system install of Python, it is added at the end of setsitepackages() in site.py. This should be done before running any code (particularly the ensurepip tool).  That would remove the directory containing the Extras.pth on 10.12, and hence remove the conflict between Apple stuff and user provided stuff.   Doing this with the python.org installer requires some care, as it will by default run ensurepip during the installation (but this can be turned off).

According to issue 28440 /Library/Python/2.7/site-packages will no longer be treated as a site-packages directory in a future release of 2.7.

Ronald

> -glyph
> _______________________________________________
> Pythonmac-SIG maillist  -  Pyt...@py...
> https://mail.python.org/mailman/listinfo/pythonmac-sig
> unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pyobjc-dev] [Pythonmac-SIG] PyObjC 3.2.1 released

[Ronald O. <ron...@ma...>]

> On 13 Dec 2016, at 04:02, Glyph Lefkowitz <gl...@tw...> wrote:
> 
> 
>> On Dec 12, 2016, at 1:25 AM, Ronald Oussoren <ron...@ma... <mailto:ron...@ma...>> wrote:
>> 
>> Hi,
>> 
>> I’ve just pushed PyObjC 3.2.1 to PyPI. This fixes a number of small issues in PyObjC 3.2, but the primary new feature is that there are now wheels on PyPI. 
>> 
>> I’ve tested the wheels on OSX 10.12 with the Python.org <http://python.org/> “intel” installers (the default download option for the OSX installers) and Homebrew. The wheels should also work fine with older OSX releases. 
> 
> Thank you *so* much, Ronald :D.  I installed pyobjc onto my laptop just now and didn't even have to go get an icepack out of the freezer first :-).  In under ten seconds, no less, for both python 3.5 and python 2.7.  A glorious day, to be sure.
Great to hear that.

> 
> One minor note - I do notice that the 'pyobjc' package itself has no wheel, even though all its dependents do.  Any chance you could upload 2.7/3.5 wheels for that as well?  It would just complete the set :-).

That is intentional. The setup.py for the package pyobjc calculates the “install_requires” list at runtime to ensure it will only install framework wrappers for frameworks that are actually present.  It might be possible to use conditional dependencies for that (see [1]), but I haven’t checked yet if those compare version numbers as structured data or strings.  PEP 426 seems to indicate they are just strings, and that would be less useful.   

I guess a wheel for the “pyobjc” package could just depend on all framework wrappers, that would install some code that isn’t relevant for the current machine but wouldn’t result in install failures (which could happen when installing all framework wrappers from source).  

Ronald

[1]: http://wheel.readthedocs.io/en/latest/#defining-conditional-dependencies
> 
> Thanks again; this is fabulous,
> 
> -glyph
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most 
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot_______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

Re: [Pyobjc-dev] [Pythonmac-SIG] PyObjC 3.2.1 released

[Glyph L. <gl...@tw...>]

> On Dec 12, 2016, at 1:25 AM, Ronald Oussoren <ron...@ma...> wrote:
> 
> Hi,
> 
> I’ve just pushed PyObjC 3.2.1 to PyPI. This fixes a number of small issues in PyObjC 3.2, but the primary new feature is that there are now wheels on PyPI. 
> 
> I’ve tested the wheels on OSX 10.12 with the Python.org <http://python.org/> “intel” installers (the default download option for the OSX installers) and Homebrew. The wheels should also work fine with older OSX releases. 

Thank you *so* much, Ronald :D.  I installed pyobjc onto my laptop just now and didn't even have to go get an icepack out of the freezer first :-).  In under ten seconds, no less, for both python 3.5 and python 2.7.  A glorious day, to be sure.

One minor note - I do notice that the 'pyobjc' package itself has no wheel, even though all its dependents do.  Any chance you could upload 2.7/3.5 wheels for that as well?  It would just complete the set :-).

Thanks again; this is fabulous,

-glyph

Re: [Pyobjc-dev] PyObjC 3.2.1 released

[Andrew J. <a.h...@gm...>]

Hi Ronald,


On 12/12/2016 09:25, Ronald Oussoren wrote:
> Hi,
>
> I’ve just pushed PyObjC 3.2.1 to PyPI. This fixes a number of small
> issues in PyObjC 3.2, but the primary new feature is that there are now
> wheels on PyPI.
>
> I’ve tested the wheels on OSX 10.12 with the Python.org
> <http://Python.org> “intel” installers (the default download option for
> the OSX installers) and Homebrew. The wheels should also work fine with
> older OSX releases.
>
Thanks. I'll also note that when used with `pip2 install --upgrade 
--ignore-installed` this solves the problem discussed a few weeks ago 
regarding clashes with the Apple-installed version on Framework 
(python.org) builds of Python. (Previously, `--ignore-installed` failed 
for some of the packages.)

Yours,

Andrew


> Ronald
>
>
> ------------------------------------------------------------------------------
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today.http://sdm.link/xeonphi
>
>
>
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>

[Pyobjc-dev] PyObjC 3.2.1 released

[Ronald O. <ron...@ma...>]

Hi,

I’ve just pushed PyObjC 3.2.1 to PyPI. This fixes a number of small issues in PyObjC 3.2, but the primary new feature is that there are now wheels on PyPI. 

I’ve tested the wheels on OSX 10.12 with the Python.org <http://python.org/> “intel” installers (the default download option for the OSX installers) and Homebrew. The wheels should also work fine with older OSX releases. 

Ronald

Re: [Pyobjc-dev] [Pythonmac-SIG] PyObjC 3.2 released

[Ronald O. <ron...@ma...>]

> On 8 Dec 2016, at 23:55, Glyph Lefkowitz <gl...@tw...> wrote:
> 
>> 
>> On Dec 8, 2016, at 3:37 AM, Ronald Oussoren <ron...@ma... <mailto:ron...@ma...>> wrote:
>> 
>> 
>>> On 8 Dec 2016, at 00:40, Glyph Lefkowitz <gl...@tw... <mailto:gl...@tw...>> wrote:
>>>> 
>>>> 
>>>> Last time I checked systems like Homebrew only build 64-bit binaries (on anything resembling modern hardware). It should be possible to support both i386/x86_64 python.org <http://python.org/> and homebrew using the same wheel file by tweaking the platform tag. The filename of the wheels will get annoyingly long, but that’s something users won’t see anyway.   If that doesn’t work out I’ll install homebrew on my build machine and have the build script generate wheels for that as well. 
>>> 
>>> You shouldn't need to do this; and in fact you shouldn't do it :).  If you tweak the platform tag, you'll break Pip's ability to discover the wheel as valid-to-install for the current platform.  Platform tags are a descriptive mechanism for Python, Pip, and Setuptools, not a point for user extensibility.
>> 
>> I know how platform tags work, I’ve read the relevant PEPs when the were proposed. The “tweak” I wanted to use is documented as “Compressed Tag Sets” in PEP 425, and is how the python version is added to the wheel filename for wheels supporting both python2 and python3, as in:
>> 
>>    pyobjc_framework_XgridFoundation-3.3a0-py2.py3-none-any.whl
>> 
>> This should work in the platform tag as well, and is already used by wheels for matplotlib (see https://pypi.python.org/pypi/matplotlib <https://pypi.python.org/pypi/matplotlib>).
> 
> Aah, I was reading you backwards.  I thought you were saying something about inventing a platform tag for Homebrew (since they don't have one of their own; they build specifically to be compatible with system python).  This makes sense.

That explains the confusion.
> 
>>> There are a lot of fiddly nuances here, but basically, "intel" is the architecture for "fat binary, intel", and "x86_64" is the architecture for "64-bit".  (I have no idea what the story is on 10.5 and previous but IMHO you can skip bothering to build wheels for them for now).  If you want to build release wheels, just build "intel" (fat binary) and any Python will be happy with them.
>> 
>> I wrote the distutils code that sets the platform to a sane value for fat binaries on OSX ;-).  
> 
> Heh. I think we both know a little too much about this for our own good :-).
> 
>> That’s cool, this means pip did implement the logic that’s needed to understand that “intel” is an acceptable architecture when looking for a wheel for an “x86_64” build of CPython.
> 
> I believe it understands the tags pretty thoroughly; I haven't tested, but I believe it also knows that an x86_64 wheel won't cut it on an 'intel' python because it might blow up later.
> 
>>> 
>>> This is probably worth reading, as it explains the above in a lot more detail: https://github.com/MacPython/wiki/wiki/Spinning-wheels <https://github.com/MacPython/wiki/wiki/Spinning-wheels>.  But the lede is: just use the default behavior of a fat binary Python, it will do the right thing :).
>> 
>> Looking at that page the relevant logic was added in pip 6, that’s old enough to not worry about using a compressed tag set for the platform. 
> 
> Cool.  I'm really looking forward to never building pyobjc again :-).

:-)

I’ve written some scripts to help me with doing the release, by scaling back the scope these scripts got a lot simpler and more importantly actually got written.  

Annoyingly the testsuite runner found some issues that I had missed before because I don’t regularly all python versions and architectures. The new test runner should make it a lot easier to do comprehensive testing, a test run will still take a lot of time but I won’t have to be present for that. 

Ronald