On Jan 4, 2005, at 4:17 PM, Jack Jansen wrote:
On 4-jan-05, at 14:42, Bob Ippolito wrote:
On Jan 4, 2005, at 8:09 AM, Jack Jansen wrote:
I'd never even heard of .pydistutils.cfg. I've added a note to the
FAQ pointing to it.
It has some more features in Python 2.4, you can use it to add new
build command packages to distutils out-of-tree (like py2app,
bdist_mpkg, etc.). Of course, very few distutils extensions are
implemented in away that is compatible with this new feature, but
it's there and I'll probably end up making py2app and bdist_mpkg
compatible.
Interesting... Although: you only need py2app and bdist_mpkg on the
supplier-side (right?), so it doesn't really buy us all that much
except a bit of convenience.
If you want to create redistributable Mac applications, even "applets",
then you are a "supplier". So I think it does buy *something* in this
case, but not much. It saves you a line or two per setup.py, because
right now py2app and bdist_mpkg jigger themselves into distutils by
monkeypatch on import like py2exe does.
Another thing that would be nice is to have some admin-writable place
to put header files (in addition to Python's own headers) too. But
that would require a patch to distutils and might need to happen in
the 2.5 tree.
[EVIL GRIN] What happens if we set both "include_dirs" and "headers"
to, say, /Library/Python/2.3/python-includes in distutils.cfg? We'd
need a bit of extra glue for PackMan binary installs (so it sends
include files there too), but if this would cause include files to be
installed there *and* that directory added to the -I flags we'd be all
set, I think...
If the person who created the package had it set that way, it would
already work like that.. since it isn't done by symlink, it should show
up in what bdist_dumb will create.
-bob