Re: [Pythonmac-SIG] Py2app-built app giving error 255 on loading AppKit?
On 21 May, 2013, at 16:04, fste...@mindspring.com wrote:
I've built an app with Py2app. It runs as expected on my development machine,
but on machines (10.7.5 and 10.8.2, at least) without a development
environment, I get:
testmini1:~ administrator$
/Users/administrator/Desktop/EasySetup.app/Contents/MacOS/EasySetup ; exit;
Traceback (most recent call last):
File
/Users/administrator/Desktop/EasySetup.app/Contents/Resources/__boot__.py,
line 43, in module
_run()
File
/Users/administrator/Desktop/EasySetup.app/Contents/Resources/__boot__.py,
line 38, in _run
exec(compile(source, path, 'exec'), globals(), globals())
File
/Users/administrator/Desktop/EasySetup.app/Contents/Resources/EasySetup.py,
line 13, in module
import AppKit
File AppKit/__init__.pyc, line 43, in module
File AppKit/_AppKit.pyc, line 14, in module
File AppKit/_AppKit.pyc, line 10, in __load
ImportError:
dlopen(/Users/administrator/Desktop/EasySetup.app/Contents/Resources/lib/python2.7/lib-dynload/AppKit/_AppKit.so,
2): Symbol not found: _OBJC_CLASS_$_NSObject
Referenced from:
/Users/administrator/Desktop/EasySetup.app/Contents/Resources/lib/python2.7/lib-dynload/AppKit/_AppKit.so
Expected in: /usr/lib/libobjc.A.dylib
in
/Users/administrator/Desktop/EasySetup.app/Contents/Resources/lib/python2.7/lib-dynload/AppKit/_AppKit.so
2013-05-21 09:19:44.502 EasySetup[393:707] EasySetup Error
The _AppKit.so file referenced is in the location referenced. I've deleted
/build and /dist and rebuilt the app.
It is odd that the problem occurs on all machines without development tools.
What's the deployment target of the application? You can check the actual
deployment target in binaries (such as _AppKit.so) using otool -vl FILENAME,
look for 'LC_VERSION_MIN_MACOSX'. Having a too high deployment target could
explain why the app doesn't work on 10.7, but not why it doesn't work on 10.8
machines without devtools.
Ronald
My setup.py:
from setuptools import setup
APP = ['EasySetup.py']
DATA_FILES = ['EasySetup/MainMenu.xib', 'loggers.py', 'MacTools.py',
'create_corplocaladministrator-1.0.pkg', 'macepoprodagentinstall.sh',
'corp-logo.png']
OPTIONS = {'argv_emulation': False, 'iconfile':'EasySetup.icns'}
setup(
app=APP,
data_files=DATA_FILES,
install_requires=[pyobjc],
options={'py2app': OPTIONS},
setup_requires=['py2app'],
)
I'm using virtualenv, where yolk -list gives:
python - 2.7.3- active development
(/usr/local/Cellar/python/2.7.3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload)
altgraph- 0.10.2 - active
beautifulsoup4 - 4.1.3- active
macholib- 1.5.1- active
modulegraph - 0.10.4 - active
pexpect - 2.4 - active
pip - 1.3.1- active
py2app - 0.7.3- non-active
pyobjc-core - 2.5.1- active
pyobjc-framework-Accounts - 2.5.1- active
pyobjc-framework-AddressBook - 2.5.1- active
pyobjc-framework-AppleScriptKit - 2.5.1- active
pyobjc-framework-AppleScriptObjC - 2.5.1- active
pyobjc-framework-Automator - 2.5.1- active
pyobjc-framework-CFNetwork - 2.5.1- active
pyobjc-framework-CalendarStore - 2.5.1- active
pyobjc-framework-Cocoa - 2.5.1- active
pyobjc-framework-Collaboration - 2.5.1- active
pyobjc-framework-CoreData - 2.5.1- active
pyobjc-framework-CoreLocation - 2.5.1- active
pyobjc-framework-CoreText - 2.5.1- active
pyobjc-framework-DictionaryServices - 2.5.1- active
pyobjc-framework-EventKit - 2.5.1- active
pyobjc-framework-ExceptionHandling - 2.5.1- active
pyobjc-framework-FSEvents - 2.5.1- active
pyobjc-framework-InputMethodKit - 2.5.1- active
pyobjc-framework-InstallerPlugins - 2.5.1- active
pyobjc-framework-InstantMessage - 2.5.1- active
pyobjc-framework-LatentSemanticMapping - 2.5.1- active
pyobjc-framework-LaunchServices - 2.5.1- active
pyobjc-framework-Message - 2.5.1- active
pyobjc-framework-PreferencePanes - 2.5.1- active
pyobjc-framework-PubSub - 2.5.1- active
pyobjc-framework-QTKit - 2.5.1- active
pyobjc-framework-Quartz - 2.5.1- active
pyobjc-framework-ScreenSaver - 2.5.1- active
pyobjc-framework-ScriptingBridge - 2.5.1- active
pyobjc-framework-SearchKit - 2.5.1- active
pyobjc-framework-ServerNotification - 2.5.1- active
pyobjc-framework-ServiceManagement - 2.5.1- active
pyobjc-framework-Social - 2.5.1- active
pyobjc-framework-SyncServices - 2.5.1- active
pyobjc-framework-SystemConfiguration - 2.5.1- active
pyobjc-framework-WebKit - 2.5.1- active
pyobjc - 2.5.1- active
requests
Re: [Pythonmac-SIG] Py2app-built app giving error 255 on loading AppKit?
That was it -- Thanks! I built a new Python 2.7.4 virtual environment this
morning, and code built with gives 10.6 as the minimum target. I'm not sure how
my 2.7.3 environment got built with 10.8 only.
Best,
Frank
On May 22, 2013, at 4:15 AM, Ronald Oussoren ronaldousso...@mac.com wrote:
On 21 May, 2013, at 16:04, fste...@mindspring.com wrote:
I've built an app with Py2app. It runs as expected on my development
machine, but on machines (10.7.5 and 10.8.2, at least) without a development
environment, I get:
testmini1:~ administrator$
/Users/administrator/Desktop/EasySetup.app/Contents/MacOS/EasySetup ; exit;
Traceback (most recent call last):
File
/Users/administrator/Desktop/EasySetup.app/Contents/Resources/__boot__.py,
line 43, in module
_run()
File
/Users/administrator/Desktop/EasySetup.app/Contents/Resources/__boot__.py,
line 38, in _run
exec(compile(source, path, 'exec'), globals(), globals())
File
/Users/administrator/Desktop/EasySetup.app/Contents/Resources/EasySetup.py,
line 13, in module
import AppKit
File AppKit/__init__.pyc, line 43, in module
File AppKit/_AppKit.pyc, line 14, in module
File AppKit/_AppKit.pyc, line 10, in __load
ImportError:
dlopen(/Users/administrator/Desktop/EasySetup.app/Contents/Resources/lib/python2.7/lib-dynload/AppKit/_AppKit.so,
2): Symbol not found: _OBJC_CLASS_$_NSObject
Referenced from:
/Users/administrator/Desktop/EasySetup.app/Contents/Resources/lib/python2.7/lib-dynload/AppKit/_AppKit.so
Expected in: /usr/lib/libobjc.A.dylib
in
/Users/administrator/Desktop/EasySetup.app/Contents/Resources/lib/python2.7/lib-dynload/AppKit/_AppKit.so
2013-05-21 09:19:44.502 EasySetup[393:707] EasySetup Error
The _AppKit.so file referenced is in the location referenced. I've deleted
/build and /dist and rebuilt the app.
It is odd that the problem occurs on all machines without development tools.
What's the deployment target of the application? You can check the actual
deployment target in binaries (such as _AppKit.so) using otool -vl
FILENAME, look for 'LC_VERSION_MIN_MACOSX'. Having a too high deployment
target could explain why the app doesn't work on 10.7, but not why it doesn't
work on 10.8 machines without devtools.
Ronald
My setup.py:
from setuptools import setup
APP = ['EasySetup.py']
DATA_FILES = ['EasySetup/MainMenu.xib', 'loggers.py', 'MacTools.py',
'create_corplocaladministrator-1.0.pkg', 'macepoprodagentinstall.sh',
'corp-logo.png']
OPTIONS = {'argv_emulation': False, 'iconfile':'EasySetup.icns'}
setup(
app=APP,
data_files=DATA_FILES,
install_requires=[pyobjc],
options={'py2app': OPTIONS},
setup_requires=['py2app'],
)
I'm using virtualenv, where yolk -list gives:
python - 2.7.3- active development
(/usr/local/Cellar/python/2.7.3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload)
altgraph- 0.10.2 - active
beautifulsoup4 - 4.1.3- active
macholib- 1.5.1- active
modulegraph - 0.10.4 - active
pexpect - 2.4 - active
pip - 1.3.1- active
py2app - 0.7.3- non-active
pyobjc-core - 2.5.1- active
pyobjc-framework-Accounts - 2.5.1- active
pyobjc-framework-AddressBook - 2.5.1- active
pyobjc-framework-AppleScriptKit - 2.5.1- active
pyobjc-framework-AppleScriptObjC - 2.5.1- active
pyobjc-framework-Automator - 2.5.1- active
pyobjc-framework-CFNetwork - 2.5.1- active
pyobjc-framework-CalendarStore - 2.5.1- active
pyobjc-framework-Cocoa - 2.5.1- active
pyobjc-framework-Collaboration - 2.5.1- active
pyobjc-framework-CoreData - 2.5.1- active
pyobjc-framework-CoreLocation - 2.5.1- active
pyobjc-framework-CoreText - 2.5.1- active
pyobjc-framework-DictionaryServices - 2.5.1- active
pyobjc-framework-EventKit - 2.5.1- active
pyobjc-framework-ExceptionHandling - 2.5.1- active
pyobjc-framework-FSEvents - 2.5.1- active
pyobjc-framework-InputMethodKit - 2.5.1- active
pyobjc-framework-InstallerPlugins - 2.5.1- active
pyobjc-framework-InstantMessage - 2.5.1- active
pyobjc-framework-LatentSemanticMapping - 2.5.1- active
pyobjc-framework-LaunchServices - 2.5.1- active
pyobjc-framework-Message - 2.5.1- active
pyobjc-framework-PreferencePanes - 2.5.1- active
pyobjc-framework-PubSub - 2.5.1- active
pyobjc-framework-QTKit - 2.5.1- active
pyobjc-framework-Quartz - 2.5.1- active
pyobjc-framework-ScreenSaver - 2.5.1- active
pyobjc-framework-ScriptingBridge - 2.5.1- active
pyobjc-framework-SearchKit - 2.5.1- active
pyobjc-framework-ServerNotification - 2.5.1- active
pyobjc-framework-ServiceManagement - 2.5.1
[Pythonmac-SIG] Advice wanted on dependency building...
Hey folks, I'm looking for advice, and maybe even some consensus among the MacPython community, on how to build and distribute packages with non-python dependencies. As we all know, a number of Python packages require libs that are used outside of python itself. These libs fall into (sort of) what I would call two catagories; 1) general purpose libs used by multiple python packages: libpng, freetype, etc. (I'm still confused on why Apple doesn't provide all these -- particularly libpng -- what's up with that?) 2) More specific libs, likely only used by a single python package -- netcdf, proj.4, etc. Users also fall into two categories: 1) Folks that do Python development on OS-X much like Linux, etc -- these folks are likely to use macports or homebrew, or are used to the .configure, make, make install dance. We don't need to do anything to support these folks -- pip install generally works for them. 2) folks that want to use a Mac like a Mac, and people that develop for those folks -- these people need binary installers, and may want to be able to use and deploy either packages or applications (Py2app) that will run on systems older than the one developed on, or want universal builds, or ??? - These are the folks I'd like to support, but I'm still unsure as to how best to do that. Way back when Bob Ippolito maintained a repository of binary packages for the mac -- it was a great resource, but he's long since moved on to other things. We kind of get away with it because a number of major package maintainers have done a good job of providing binaries themselves (wxPython, numpy/scipy/matplotlib), but others fail to do so (PIL). Plus some of us have minor packages that we want to distribute. I'd like to put together an archive, much like Bob's was, or like Christoph Gohlke's one for Windows (By the way -- that one is HUGE -- I have no idea how he keeps it up! http://www.lfd.uci.edu/~gohlke/pythonlibs/) But with or without that archive, I still need to build the darn things. So now on to the question: How should the dependencies be distributed? 1) They should be built to match the Python binary being targeted (honestly, I think that's now only the Intel 32-64 bit ones -- PPC machines, and pre 10.6, are getting really rare...) 2) Static or dynamic? IIUC, most successful binary packages for the Mac have relied on statically linking the dependencies -- this works, and is pretty robust. However, it can be kind of a pain to do (though I've finally figure how to do it more reliably!). Also, it seems like a waste to me for packages that use common dependencies -- how many copies of libpng do I really want linked into my single instance of Python at run time? But if dynamic, where do you put them? We'll still want to ship them with the binary, so people have a one-click install. I don't think we want to install them into a standard location, like /usr/local, as that could stomp on something else the user is doing. So: - Do we put the in the Python Framework, say in: /Library/Frameworks/Python.framework/Versions/2.7/lib - This make some sense, but then you couldn't share them between, say, python 2.7 and 3.3 (and however many other versions... - Do we create a new Framework, say: /Library/Frameworks/PythonDeps.framework and put them all there? But this may confuse things for different deployment targets. If we go one of these routes, would we have a separate installer for the libs, and all the other installers would depend on that? Or would each installer put a copy of the libs it needed into the common location, maybe writing over one that's already there (which should be OK -- it should be compatible, or have a different version number, etc.) Note that I've used the term we here ;-) I'm hoping that others will join me in following a convention and getting stuff out there, but even if not, I'd love feedback on how best to do it. By the way, the other goal is to build scripts that do the builds the way we need for various libs, packages, etc, so that it's easy to do it all when new builds are required... (maybe use gattai? -- http://sourceforge.net/projects/gattai/) Feedback please!! -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
Re: [Pythonmac-SIG] Advice wanted on dependency building...
On 22 May, 2013, at 19:30, Chris Barker - NOAA Federal chris.bar...@noaa.gov wrote: Hey folks, I'm looking for advice, and maybe even some consensus among the MacPython community, on how to build and distribute packages with non-python dependencies. As we all know, a number of Python packages require libs that are used outside of python itself. These libs fall into (sort of) what I would call two catagories; 1) general purpose libs used by multiple python packages: libpng, freetype, etc. (I'm still confused on why Apple doesn't provide all these -- particularly libpng -- what's up with that?) In general Apple doesn't ship libraries that it doesn't use itself, and for image format support they have their own libraries (in particular the ImageIO framework). To move back onto topic, not relying on unix-level libraries in OSX is in a good thing as it makes it easier to support multiple OSX versions with a single set of binaries. 2) More specific libs, likely only used by a single python package -- netcdf, proj.4, etc. Users also fall into two categories: 1) Folks that do Python development on OS-X much like Linux, etc -- these folks are likely to use macports or homebrew, or are used to the .configure, make, make install dance. We don't need to do anything to support these folks -- pip install generally works for them. Except for a number of more complicated libraries (such as PIL/Pillow) when using universal binaries (when using 'pip install', homebrew/macports/... have their own mechanisms for building). 2) folks that want to use a Mac like a Mac, and people that develop for those folks -- these people need binary installers, and may want to be able to use and deploy either packages or applications (Py2app) that will run on systems older than the one developed on, or want universal builds, or ??? - These are the folks I'd like to support, but I'm still unsure as to how best to do that. It would be nice to have a set of binary packages, based on a reproducable build system. Way back when Bob Ippolito maintained a repository of binary packages for the mac -- it was a great resource, but he's long since moved on to other things. The binary packages that Bob maintained had IMHO two major problems: 1) The largest problem is that the packages were AFAIK created ad-hoc (Bob or some other contributor did the magic incantations to build library dependencies) 2) The packages were Installer.app packages. The current state of the art for development/project environments is to use virtualenv or buildout to create separated python installations and install all project depedencies there instead of the global site-packages directory. That's not something that's easily supported with Installer.app packages. We kind of get away with it because a number of major package maintainers have done a good job of providing binaries themselves (wxPython, numpy/scipy/matplotlib), but others fail to do so (PIL). Plus some of us have minor packages that we want to distribute. I'd like to put together an archive, much like Bob's was, or like Christoph Gohlke's one for Windows (By the way -- that one is HUGE -- I have no idea how he keeps it up! http://www.lfd.uci.edu/~gohlke/pythonlibs/) But with or without that archive, I still need to build the darn things. So now on to the question: How should the dependencies be distributed? 1) They should be built to match the Python binary being targeted (honestly, I think that's now only the Intel 32-64 bit ones -- PPC machines, and pre 10.6, are getting really rare...) No objections there. Supporting PPC is getting way to hard now that the Xcode version that you can install on recent machines cannot generate PPC code. I have VMs with older OSX releases for running the compiler, but that's barely usable. 2) Static or dynamic? IIUC, most successful binary packages for the Mac have relied on statically linking the dependencies -- this works, and is pretty robust. However, it can be kind of a pain to do (though I've finally figure how to do it more reliably!). Also, it seems like a waste to me for packages that use common dependencies -- how many copies of libpng do I really want linked into my single instance of Python at run time? As long as the libpng state isn't shared static linking isn't really a problem. It does get a problem when two extensions use the same external library and share state, for example the curses and curses_panel extensions in the stdlib. Dynamic linking has at least two disadvantages: 1) Relocation of the installation prefix is harder due to the way the dynamic linker on OSX looks for libraries: when extension foo.so uses library libfoo.dylib the absolute path of libfoo.dylib is included in the MachO header for foo.so. The header is easily updated using macholib, but that makes installation harder and isn't supported by the standard packaging tools
Re: [Pythonmac-SIG] Advice wanted on dependency building...
Thanks Ronald, On Wed, May 22, 2013 at 2:53 PM, Ronald Oussoren ronaldousso...@mac.com wrote: To move back onto topic, not relying on unix-level libraries in OSX is in a good thing as it makes it easier to support multiple OSX versions with a single set of binaries. hmm -- I figured if it was a system lib, it should work on whatever system It's running on. For example, I'm working right now on the netcdf4 lib -- it required hdr5, which requires zlib. Im using the system zlib -- is that a bad idea? Should I build it too, to make sure it matches the rest of it? (I do want the binaries to run anywhere the binary Python I'm using runs) Except for a number of more complicated libraries (such as PIL/Pillow) when using universal binaries (when using 'pip install', homebrew/macports/... have their own mechanisms for building). right -- Universal libs are not well supported by those systems -- but that's the power users problem! 2) folks that want to use a Mac like a Mac, and people that develop for those folks -- these people need binary installers, and may want to be able to use and deploy either packages or applications (Py2app) that will run on systems older than the one developed on, or want universal builds, or ??? - These are the folks I'd like to support, but I'm still unsure as to how best to do that. It would be nice to have a set of binary packages, based on a reproducable build system. Exactly what I'd like to build! Way back when Bob Ippolito maintained a repository of binary packages for the mac -- it was a great resource, but he's long since moved on to other things. The binary packages that Bob maintained had IMHO two major problems: 1) The largest problem is that the packages were AFAIK created ad-hoc (Bob or some other contributor did the magic incantations to build library dependencies) Yeah, and he never gave anyone else permission to push to it... 2) The packages were Installer.app packages. The current state of the art for development/project environments is to use virtualenv or buildout to create separated python installations and install all project depedencies there instead of the global site-packages directory. That's not something that's easily supported with Installer.app packages. It was the way to go at the time, but I agree a binary format that supports virtualenv would be great. do I really want linked into my single instance of Python at run time? As long as the libpng state isn't shared static linking isn't really a problem. good to know, but somehow it still offends my sensibilities Dynamic linking has at least two disadvantages: 1) Relocation of the installation prefix is harder due to the way the dynamic linker on OSX looks for libraries: yeah -- that is a pain. The header is easily updated using macholib, but that makes installation harder and isn't supported by the standard packaging tools (easy_install and pip) But if we put the shared libs in amore central location, then all your virtual-ens could use the same ones, yes? 2) The primary use case for dynamic linking is to share dylibs between extensions, and when those extensions are in different PyPI packages the packaging story gets more complicated. The easiest workaround is to ignore sharing dylibs and still bundle multipe copies of libpng if two different PyPI packages both link with libpng. when you say bundle, do you mean static link? Or just package up the dylib with the bundle, which is what i was thinking -- each package installs the libs it needs, which may or may not already have been installed by another package -- but so what? And I expect the number of folks building packages will be fairly small, so one builder would one have to build one set of dylibs. But if dynamic, where do you put them? We'll still want to ship them A new framework isn't necessary. There are three locations that could easily be used: 1) A directory in Python.framework, for example /Library/Frameworks/Python.framework/Frameworks That makes sense to me. 2) A directory in /Library/Python, for example /Library/Python/Externals that feels a bit lke Apple's turf, but what do I know? 3) As 2), but in the users home directory (~/Library/Python/Externals) The latter is the only one where you can install without admin privileges. But we put the python binaries in /LIbrary/Frameworks -- it seems we should do the same with libs... The folks over on distutils-sig are working towards support for wheels (PEP 427, http://www.python.org/dev/peps/pep-0427/) at least in pip and distribute/setuptools and possibly in the stdlib as well (for 3.4). It would be nice if the OSX package collection would be in wheel format, that would make it relatively easy to install the packages using the defacto standard tools. Any idea what the time scale is on this? What I haven't looked into yet is how easy it would be to configure pip to look for
Re: [Pythonmac-SIG] Advice wanted on dependency building...
I just poked a bit into the Anaconda Python distribution. their packages are simple tarballs, but I think they have a dependency management system of some sort. They deliver the dependencies as separate packages (tarballs), one for each lib. It looksl ike it all gets unpacked inot a sinlgle dir (in /opt), and an example python extension is built like this: $ otool -L netCDF4.so netCDF4.so: @loader_path/../../libnetcdf.7.dylib (compatibility version 10.0.0, current version 10.0.0) @loader_path/../../libhdf5_hl.7.dylib (compatibility version 8.0.0, current version 8.3.0) @loader_path/../../libhdf5.7.dylib (compatibility version 8.0.0, current version 8.3.0) @loader_path/../../libz.1.dylib (compatibility version 1.0.0, current version 1.2.7) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.0.0) I don't know how to get that @loader_path thing in there, but this seems like a reasonable way to do it (though I guess it wouldn't support virtualenv...) -Chris On Wed, May 22, 2013 at 3:46 PM, Chris Barker - NOAA Federal chris.bar...@noaa.gov wrote: Thanks Ronald, On Wed, May 22, 2013 at 2:53 PM, Ronald Oussoren ronaldousso...@mac.com wrote: To move back onto topic, not relying on unix-level libraries in OSX is in a good thing as it makes it easier to support multiple OSX versions with a single set of binaries. hmm -- I figured if it was a system lib, it should work on whatever system It's running on. For example, I'm working right now on the netcdf4 lib -- it required hdr5, which requires zlib. Im using the system zlib -- is that a bad idea? Should I build it too, to make sure it matches the rest of it? (I do want the binaries to run anywhere the binary Python I'm using runs) Except for a number of more complicated libraries (such as PIL/Pillow) when using universal binaries (when using 'pip install', homebrew/macports/... have their own mechanisms for building). right -- Universal libs are not well supported by those systems -- but that's the power users problem! 2) folks that want to use a Mac like a Mac, and people that develop for those folks -- these people need binary installers, and may want to be able to use and deploy either packages or applications (Py2app) that will run on systems older than the one developed on, or want universal builds, or ??? - These are the folks I'd like to support, but I'm still unsure as to how best to do that. It would be nice to have a set of binary packages, based on a reproducable build system. Exactly what I'd like to build! Way back when Bob Ippolito maintained a repository of binary packages for the mac -- it was a great resource, but he's long since moved on to other things. The binary packages that Bob maintained had IMHO two major problems: 1) The largest problem is that the packages were AFAIK created ad-hoc (Bob or some other contributor did the magic incantations to build library dependencies) Yeah, and he never gave anyone else permission to push to it... 2) The packages were Installer.app packages. The current state of the art for development/project environments is to use virtualenv or buildout to create separated python installations and install all project depedencies there instead of the global site-packages directory. That's not something that's easily supported with Installer.app packages. It was the way to go at the time, but I agree a binary format that supports virtualenv would be great. do I really want linked into my single instance of Python at run time? As long as the libpng state isn't shared static linking isn't really a problem. good to know, but somehow it still offends my sensibilities Dynamic linking has at least two disadvantages: 1) Relocation of the installation prefix is harder due to the way the dynamic linker on OSX looks for libraries: yeah -- that is a pain. The header is easily updated using macholib, but that makes installation harder and isn't supported by the standard packaging tools (easy_install and pip) But if we put the shared libs in amore central location, then all your virtual-ens could use the same ones, yes? 2) The primary use case for dynamic linking is to share dylibs between extensions, and when those extensions are in different PyPI packages the packaging story gets more complicated. The easiest workaround is to ignore sharing dylibs and still bundle multipe copies of libpng if two different PyPI packages both link with libpng. when you say bundle, do you mean static link? Or just package up the dylib with the bundle, which is what i was thinking -- each package installs the libs it needs, which may or may not already have been installed by another package -- but so what? And I expect the number of folks building packages will be fairly small, so one
