[Pythonmac-SIG] .pydistutils.cfg (was: pychecker)

[Bob Ippolito]

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