From jjl@pobox.com Sat Oct 5 13:03:08 2002 From: jjl@pobox.com (John J Lee) Date: Sat Oct 5 12:03:08 2002 Subject: [Distutils] MANIFEST not included Message-ID: <6686926.1033837495@async74-1.nas.onetel.net.uk> I'm not getting MANIFEST included when running sdist, though the file does get created. If I explicitly add it to MANIFEST.in, I get a message from distutils telling me that MANIFEST doesn't exist (presumably because distutils just deleted it, so it can remake it). What might be wrong? Thanks for any help John From dave@boost-consulting.com Sat Oct 5 20:16:02 2002 From: dave@boost-consulting.com (David Abrahams) Date: Sat Oct 5 19:16:02 2002 Subject: [Distutils] Building ordinary shared library? Message-ID: <048b01c26cc4$971e2440$6701a8c0@boostconsulting.com> Hi, I'm about to release v2 of Boost.Python, and I thought it might be nice to provide a distutils setup for it. We have our own build system, but some Python users might be more comfortable with distutils, and I have a secret hope that distutils will be able to work on a few paltforms we don't have covered such as MacOS X. I'm now kicking myself for throwing them away, but one of my users sent me distutils scripts for Boost.Python a while back as part of a bug report. My problems are twofold: 1. I have to distribute a shared library which is not an extension module. The extension modules I have to distribute (tests and examples) all link to this library. 2. The documentation is really incomplete, and doesn't cover this AFAICT. In fact...well, I've found yet another version of incomplete documentation at http://www.python.org/sigs/distutils-sig/doc/dist/dist.html which doesn't match the Official Python development documentation (http://www.python.org/dev/doc/devel/dist/dist.html). Which one is the official docs? Shouldn't they be synchronized? I think it still doesn't answer my question ("How do I build a shared library with distutils -- and link extension modules to it?") Thanks in advance for any info, Dave ----------------------------------------------------------- David Abrahams * Boost Consulting dave@boost-consulting.com * http://www.boost-consulting.com From pearu@cens.ioc.ee Sun Oct 6 05:43:01 2002 From: pearu@cens.ioc.ee (Pearu Peterson) Date: Sun Oct 6 04:43:01 2002 Subject: [Distutils] Building ordinary shared library? In-Reply-To: <048b01c26cc4$971e2440$6701a8c0@boostconsulting.com> Message-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --296533764-2147227541-1033893716=:5990 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sat, 5 Oct 2002, David Abrahams wrote: > Hi, > > I'm about to release v2 of Boost.Python, and I thought it might be nice to > provide a distutils setup for it. We have our own build system, but some > Python users might be more comfortable with distutils, and I have a secret > hope that distutils will be able to work on a few paltforms we don't have > covered such as MacOS X. > > I'm now kicking myself for throwing them away, but one of my users sent me > distutils scripts for Boost.Python a while back as part of a bug report. > > My problems are twofold: > > 1. I have to distribute a shared library which is not an extension module. > The extension modules I have to distribute (tests and examples) all link to > this library. Attached is a setup_libbpl2.py file that builds libbpl2.so file containing boost.python code. After setup_libbpl2.py install it can be used as follows. The setup.py file of the extension module contains the following bits: from libbpl2 import __file__ as boost_so ext = Extension('foo', sources=[..], include_dirs=[boost_dir]+.., .. extra_objects = [boost_so], ) Attachement also includes setup_ginac.py file as a real example of using libbpl2 library. Note that setup_libbpl2.py will not probaly work with the current boost.python V2 as the last time I checked it was few months ago and since then I have not had time to update it. However, the attached files illustrate one way how to solve one of your problems. HTH, Pearu --296533764-2147227541-1033893716=:5990 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="setup_ginac.py" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="setup_ginac.py" IyEvdXNyL2Jpbi9lbnYgcHl0aG9uMi4yDQoiIiINCg0KQnVpbGQvaW5zdGFs bCBQeXRob24gYmluZGluZ3MgdG8gR2lOYUMgbGlicmFyeS4NCg0KQ29weXJp Z2h0IDIwMDIgUGVhcnUgUGV0ZXJzb24gYWxsIHJpZ2h0cyByZXNlcnZlZCwN ClBlYXJ1IFBldGVyc29uIDxwZWFydUBjZW5zLmlvYy5lZT4gICAgICAgICAg DQpQZXJtaXNzaW9uIHRvIHVzZSwgbW9kaWZ5LCBhbmQgZGlzdHJpYnV0ZSB0 aGlzIHNvZnR3YXJlIGlzIGdpdmVuIHVuZGVyIHRoZQ0KdGVybXMgb2YgdGhl IExHUEwuICBTZWUgaHR0cDovL3d3dy5mc2Yub3JnDQoNCk5PIFdBUlJBTlRZ IElTIEVYUFJFU1NFRCBPUiBJTVBMSUVELiAgVVNFIEFUIFlPVVIgT1dOIFJJ U0suDQokUmV2aXNpb246IDEuNCAkDQokRGF0ZTogMjAwMi8wNi8wMSAxNjox Nzo0MyAkDQpQZWFydSBQZXRlcnNvbg0KIiIiDQoNCl9fdmVyc2lvbl9fID0g IiRJZDogc2V0dXAucHksdiAxLjQgMjAwMi8wNi8wMSAxNjoxNzo0MyBwZWFy dSBFeHAgJCINCg0KYm9vc3RfZGlyID0gJy4vYm9vc3QnDQpnY2NfZXhlID0g J2djYycNCmdwcF9leGUgPSAnZysrJw0KZGlzYWJsZV9vcHQgPSAxDQoNCmlt cG9ydCBzeXMsb3MscmUNCg0KaWYgc3lzLnZlcnNpb24gPCAnMi4yJzoNCiAg ICBwcmludCAnUHl0aG9uID49Mi4yIGlzIHJlcXVpcmVkIGJ1dCBnb3QgJytz eXMudmVyc2lvbls6Nl0NCiAgICBzeXMuZXhpdCgpDQoNCmlmIG5vdCBvcy5w YXRoLmlzZGlyKGJvb3N0X2Rpcik6DQogICAgcHJpbnQgJ05vIEJvb3N0IGRp cmVjdG9yeScsYm9vc3RfZGlyDQogICAgc3lzLmV4aXQoKQ0KDQpmcm9tIGxp YmJwbDIgaW1wb3J0IF9fZmlsZV9fIGFzIGJvb3N0X3NvDQoNCmV4dHJhX2Nv bXBpbGVfYXJncyA9IFtdDQoNCiMrKysrKysrKyBHaU5hQyBpbmZvcm1hdGlv biArKysrKysrKysNCmZyb20gY29tbWFuZHMgaW1wb3J0IGdldHN0YXR1c291 dHB1dCxnZXRvdXRwdXQNCmdpbmFjX2NvbmZpZ19zY3JpcHQgPSAnZ2luYWMt Y29uZmlnJw0KcyxnaW5hY192ZXJzaW9uID0gZ2V0c3RhdHVzb3V0cHV0KGdp bmFjX2NvbmZpZ19zY3JpcHQrJyAtLXZlcnNpb24nKQ0KaWYgbm90IHM6DQog ICAgcHJpbnQgJ0dpTmFDIHZlcnNpb24nLGdpbmFjX3ZlcnNpb24NCiAgICBn aW5hY19wcmVmaXg9Z2V0b3V0cHV0KGdpbmFjX2NvbmZpZ19zY3JpcHQrJyAt LXByZWZpeCcpDQogICAgZ2luYWNfc28gPSBvcy5wYXRoLmpvaW4gKGdpbmFj X3ByZWZpeCwnbGliJywnbGliZ2luYWMuc28nKQ0KICAgIGdpbmFjX2xpYnM9 Z2V0b3V0cHV0KGdpbmFjX2NvbmZpZ19zY3JpcHQrJyAtLWxpYnMnKQ0KICAg IGdpbmFjX2NwcGZsYWdzPWdldG91dHB1dChnaW5hY19jb25maWdfc2NyaXB0 KycgLS1jcHBmbGFncycpDQogICAgcHJpbnQgZ2luYWNfcHJlZml4DQogICAg cHJpbnQgZ2luYWNfbGlicw0KICAgIHByaW50IGdpbmFjX3NvDQogICAgcHJp bnQgZ2luYWNfY3BwZmxhZ3MNCiAgICBnaW5hY19pbmNsdWRlX2RpcnMgPSBb XQ0KICAgIG1hdGNoID0gcmUuY29tcGlsZShyJy1JLipcWicpLm1hdGNoDQog ICAgZm9yIGQgaW4gZ2luYWNfY3BwZmxhZ3Muc3BsaXQoKToNCiAgICAgICAg YXNzZXJ0IG1hdGNoKGQpDQogICAgICAgIGdpbmFjX2luY2x1ZGVfZGlycy5h cHBlbmQoZFsyOl0pDQoNCiAgICBnaW5hY19saWJyYXJ5X2RpcnMgPSBbXQ0K ICAgIGdpbmFjX2xpYnJhcmllcyA9IFtdDQogICAgbWF0Y2hfTCA9IHJlLmNv bXBpbGUocictTC4qXFonKS5tYXRjaA0KICAgIG1hdGNoX2wgPSByZS5jb21w aWxlKHInLWwuKlxaJykubWF0Y2gNCiAgICBmb3IgZCBpbiBnaW5hY19saWJz LnNwbGl0KCk6DQogICAgICAgIGlmIG1hdGNoX0woZCk6DQogICAgICAgICAg ICBnaW5hY19saWJyYXJ5X2RpcnMuYXBwZW5kKGRbMjpdKQ0KICAgICAgICBl bGlmIG1hdGNoX2woZCk6DQogICAgICAgICAgICBnaW5hY19saWJyYXJpZXMu YXBwZW5kKGRbMjpdKQ0KZWxzZToNCiAgICBwcmludCAnRmFpbGVkIHRvIGV4 ZWN1dGUnLGdpbmFjX2NvbmZpZ19zY3JpcHQNCiAgICBwcmludCAnSW5zdGFs bCBHaU5hQyAod3d3LmdpbmFjLmRlKSBhbmQgcmVydW4nLHN5cy5hcmd2WzBd DQogICAgc3lzLmV4aXQoKQ0KDQojKysrKysrKyBFeHRlbnNpb25zICsrKysr KysNCmZyb20gZGlzdHV0aWxzLmNvcmUgaW1wb3J0IHNldHVwLCBFeHRlbnNp b24NCmV4dCA9IEV4dGVuc2lvbignZ2luYWMuX2dpbmFjJywNCiAgICAgICAg ICAgICAgICBzb3VyY2VzPVsnc3JjL19naW5hYy5jcHAnXSwNCiAgICAgICAg ICAgICAgICBpbmNsdWRlX2RpcnM9W2Jvb3N0X2Rpcl0rZ2luYWNfaW5jbHVk ZV9kaXJzLA0KICAgICAgICAgICAgICAgIGxpYnJhcmllcyA9IGdpbmFjX2xp YnJhcmllcywNCiAgICAgICAgICAgICAgICBsaWJyYXJ5X2RpcnMgPSBnaW5h Y19saWJyYXJ5X2RpcnMsDQogICAgICAgICAgICAgICAgZXh0cmFfb2JqZWN0 cyA9IFtib29zdF9zb10sDQogICAgICAgICAgICAgICAgKQ0KDQojKysrSEFD SzogcmVwbGFjZSBsaW5rZXIgZ2NjIHdpdGggZysrICsrKysrKysrKysrDQoN CmZyb20gZGlzdHV0aWxzIGltcG9ydCBzeXNjb25maWcNCnNhdmVfaW5pdF9w b3NpeCA9IHN5c2NvbmZpZy5faW5pdF9wb3NpeA0KZGVmIG15X2luaXRfcG9z aXgoKToNCiAgICBzYXZlX2luaXRfcG9zaXgoKQ0KICAgIGcgPSBzeXNjb25m aWcuX2NvbmZpZ192YXJzDQogICAgZm9yIG4sciBpbiBbKCdMRFNIQVJFRCcs Z3BwX2V4ZSksKCdDQycsZ2NjX2V4ZSldOg0KICAgICAgICBpZiBnW25dWzoz XT09J2djYyc6DQogICAgICAgICAgICBwcmludCAnbXlfaW5pdF9wb3NpeDog Y2hhbmdpbmcgJXMgPSAlciclKG4sZ1tuXSksDQogICAgICAgICAgICBnW25d ID0gcitnW25dWzM6XQ0KICAgICAgICAgICAgcHJpbnQgJ3RvJyxgZ1tuXWAN CiAgICBpZiBkaXNhYmxlX29wdCBhbmQgZ1snT1BUJ11bOjE1XT09Jy1ETkRF QlVHIC1nIC1PMyc6DQogICAgICAgIHByaW50ICdteV9pbml0X3Bvc2l4OiBj aGFuZ2luZyBPUFQgPScsYGdbJ09QVCddYCwNCiAgICAgICAgZ1snT1BUJ10g PSAnIC1ETkRFQlVHIC1nICcrZ1snT1BUJ11bMTU6XQ0KICAgICAgICBwcmlu dCAndG8nLGBnWydPUFQnXWANCnN5c2NvbmZpZy5faW5pdF9wb3NpeCA9IG15 X2luaXRfcG9zaXgNCg0KIysrKysrKysrKysrKysrKysrKysrKysrKw0KZnJv bSBfX3ZlcnNpb25fXyBpbXBvcnQgdmVyc2lvbg0KcHJpbnQgJ1B5R2lOYUMg dmVyc2lvbicsdmVyc2lvbg0KDQppZiBfX25hbWVfXyA9PSAiX19tYWluX18i Og0KICAgIHNldHVwKG5hbWUgPSAicHlnaW5hYyIsDQogICAgICAgICAgdmVy c2lvbiA9IHZlcnNpb24sDQogICAgICAgICAgZGVzY3JpcHRpb24gPSAiUHlH aU5hQyAtLS0gUHl0aG9uIGJpbmRpbmdzIHRvIEMrKyBsaWJyYXJ5IEdpTmFD IiwNCiAgICAgICAgICBsb25nX2Rlc2NyaXB0aW9uPSAiIiINClB5R2lOYUMg aXMgYSBQeXRob24gcGFja2FnZSB0aGF0IGltcGxlbWVtZW50cyBiaW5kaW5n IHRvIEMrKyBsaWJyYXJ5DQpHaU5hQy4gIEdpTmFDIChodHRwOi8vd3d3Lmdp bmFjLmRlLykgaXMgYW4gb3BlbiBmcmFtZXdvcmsgZm9yIHN5bWJvbGljDQpj b21wdXRhdGlvbiB3aXRoaW4gdGhlIEMrKyBwcm9ncmFtbWluZyBsYW5ndWFn ZS4NCiIiIiwNCiAgICAgICAgICBhdXRob3IgPSAiUGVhcnUgUGV0ZXJzb24i LA0KICAgICAgICAgIGF1dGhvcl9lbWFpbCA9ICJwZWFydUBjZW5zLmlvYy5l ZSIsDQogICAgICAgICAgbWFpbnRhaW5lciA9ICJQZWFydSBQZXRlcnNvbiIs DQogICAgICAgICAgbWFpbnRhaW5lcl9lbWFpbCA9ICJwZWFydUBjZW5zLmlv Yy5lZSIsDQogICAgICAgICAgbGljZW5jZSA9ICJMR1BMIiwNCiAgICAgICAg ICB1cmwgPSAiaHR0cDovL2NlbnMuaW9jLmVlL3Byb2plY3RzL3B5Z2luYWMv IiwNCiAgICAgICAgICBleHRfbW9kdWxlcyA9IFtleHRdLA0KICAgICAgICAg IHBhY2thZ2VzID0gWydnaW5hYycsJ2dpbmFjLnRlc3RzJ10sDQogICAgICAg ICAgcGFja2FnZV9kaXIgPSB7J2dpbmFjJzonLid9LA0KICAgICAgICAgICkN Cg== --296533764-2147227541-1033893716=:5990 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="setup_libbpl2.py" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="setup_libbpl2.py" IyEvdXNyL2Jpbi9lbnYgcHl0aG9uMi4yDQoiIiINCg0KQnVpbGQgQm9vc3Qu UHl0aG9uIFYyIHNoYXJlZCBsaWJyYXJ5Lg0KUmVxdWlyZXM6IFB5dGhvbiAy LjIsIGdjYy0zLjAsIEJQTCBWMg0KDQoNCkNvcHlyaWdodCAyMDAyIFBlYXJ1 IFBldGVyc29uIGFsbCByaWdodHMgcmVzZXJ2ZWQsDQpQZWFydSBQZXRlcnNv biA8cGVhcnVAY2Vucy5pb2MuZWU+ICAgICAgICAgIA0KUGVybWlzc2lvbiB0 byB1c2UsIG1vZGlmeSwgYW5kIGRpc3RyaWJ1dGUgdGhpcyBzb2Z0d2FyZSBp cyBnaXZlbiB1bmRlciB0aGUNCnRlcm1zIG9mIHRoZSBMR1BMLiAgU2VlIGh0 dHA6Ly93d3cuZnNmLm9yZw0KDQpOTyBXQVJSQU5UWSBJUyBFWFBSRVNTRUQg T1IgSU1QTElFRC4gIFVTRSBBVCBZT1VSIE9XTiBSSVNLLg0KJFJldmlzaW9u OiAxLjQgJA0KJERhdGU6IDIwMDIvMDUvMTUgMDc6Mzc6MTggJA0KUGVhcnUg UGV0ZXJzb24NCiIiIg0KDQpfX3ZlcnNpb25fXyA9ICIkSWQ6IHNldHVwX2xp YmJwbDIucHksdiAxLjQgMjAwMi8wNS8xNSAwNzozNzoxOCBwZWFydSBFeHAg JCINCg0KYm9vc3RfZGlyID0gJ2Jvb3N0Jw0KZ2NjX2V4ZSA9ICdnY2MtMy4w Jw0KZ3BwX2V4ZSA9ICdnKystMy4wJw0KZ2NjX2V4ZSA9ICdnY2MnDQpncHBf ZXhlID0gJ2crKycNCg0KaW1wb3J0IHN5cyxvcw0KDQppZiBzeXMudmVyc2lv biA8ICcyLjInOg0KICAgIHByaW50ICdQeXRob24gPj0yLjIgaXMgcmVxdWly ZWQgYnV0IGdvdCAnK3N5cy52ZXJzaW9uWzo2XQ0KICAgIHN5cy5leGl0KCkN Cg0KaWYgbm90IG9zLnBhdGguaXNkaXIoYm9vc3RfZGlyKToNCiAgICBwcmlu dCAnTm8gQm9vc3QgZGlyZWN0b3J5Jyxib29zdF9kaXINCiAgICBzeXMuZXhp dCgpDQoNCmJwbF9kaXIgPSBvcy5wYXRoLmpvaW4oYm9vc3RfZGlyLCdsaWJz L3B5dGhvbi9zcmMnKQ0KYnBsX3NyYyA9IFsnY29udmVydGVyL2Zyb21fcHl0 aG9uLmNwcCcsDQogICAgICAgICAgICdjb252ZXJ0ZXIvcmVnaXN0cnkuY3Bw JywNCiAgICAgICAgICAgJ2NvbnZlcnRlci90eXBlX2lkLmNwcCcsDQogICAg ICAgICAgICdvYmplY3QvY2xhc3MuY3BwJywNCiAgICAgICAgICAgJ29iamVj dC9mdW5jdGlvbi5jcHAnLA0KICAgICAgICAgICAnb2JqZWN0L2luaGVyaXRh bmNlLmNwcCcsDQogICAgICAgICAgICdvYmplY3QvbGlmZV9zdXBwb3J0LmNw cCcsDQogICAgICAgICAgICdlcnJvcnMuY3BwJywNCiAgICAgICAgICAgJ21v ZHVsZS5jcHAnLA0KICAgICAgICAgICAnb2JqZWN0cy5jcHAnLA0KICAgICAg ICAgICAnY29udmVydGVyL2J1aWx0aW5fY29udmVydGVycy5jcHAnLA0KICAg ICAgICAgICAnY29udmVydGVyL2NhbGxiYWNrLmNwcCcsDQogICAgICAgICAg IF0NCmJwbF9zcmMgPSBbb3MucGF0aC5qb2luKGJwbF9kaXIscykgZm9yIHMg aW4gYnBsX3NyY10NCg0KDQpzcmNfZmlsZSA9IG9zLnBhdGguam9pbigndG1w X2xpYmJwbDIuYycpDQppZiBub3Qgb3MucGF0aC5leGlzdHMoc3JjX2ZpbGUp Og0KICAgIHByaW50ICdDcmVhdGluZyBmaWxlJyxzcmNfZmlsZQ0KICAgIGYg PSBvcGVuKHNyY19maWxlLCd3JykNCiAgICBmLndyaXRlKCcnJw0KI2lmZGVm IF9fQ1BMVVNQTFVTX18NCmV4dGVybiAiQyIgew0KI2VuZGlmDQojaW5jbHVk ZSAiUHl0aG9uLmgiDQpzdGF0aWMgUHlNZXRob2REZWYgbW9kdWxlX21ldGhv ZHNbXSA9IHsge05VTEwsTlVMTH0gfTsNCkRMX0VYUE9SVCh2b2lkKSBpbml0 bGliYnBsMih2b2lkKSB7IFB5X0luaXRNb2R1bGUoImxpYmJwbDIiLCBtb2R1 bGVfbWV0aG9kcyk7IH0NCiNpZmRlZiBfX0NQTFVTQ1BMVVNfXw0KfQ0KI2Vu ZGlmDQogICAgJycnKQ0KICAgIGYuY2xvc2UoKQ0KDQpmcm9tIGRpc3R1dGls cy5jb3JlIGltcG9ydCBzZXR1cCwgRXh0ZW5zaW9uDQoNCmV4dCA9IEV4dGVu c2lvbignbGliYnBsMicsDQogICAgICAgICAgICAgICAgc291cmNlcz1icGxf c3JjICsgW3NyY19maWxlXSwNCiAgICAgICAgICAgICAgICBpbmNsdWRlX2Rp cnM9W2Jvb3N0X2Rpcl0sDQogICAgICAgICAgICAgICAgZGVmaW5lX21hY3Jv cyA9IFsoJ0JPT1NUX1BZVEhPTl9TT1VSQ0UnLE5vbmUpLA0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgKCdCT09TVF9QWVRIT05fRFlOQU1J Q19MSUInLE5vbmUpLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgKCdCT09TVF9QWVRIT05fVjInLE5vbmUpXSwNCiAgICAgICAgICAgICAg ICAjZXh0cmFfY29tcGlsZV9hcmdzPVsnLWZ0ZW1wbGF0ZS1kZXB0aC0yMCdd ICMgZm9yIGdjYy0yLjk1LngNCiAgICAgICAgICAgICAgICApDQoNCiMrKytI QUNLOiByZXBsYWNlIGxpbmtlciBnY2Mgd2l0aCBnKysgKysrKysrKysrKysN Cg0KZnJvbSBkaXN0dXRpbHMgaW1wb3J0IHN5c2NvbmZpZw0Kc2F2ZV9pbml0 X3Bvc2l4ID0gc3lzY29uZmlnLl9pbml0X3Bvc2l4DQpkZWYgbXlfaW5pdF9w b3NpeCgpOg0KICAgIHNhdmVfaW5pdF9wb3NpeCgpDQogICAgZyA9IHN5c2Nv bmZpZy5fY29uZmlnX3ZhcnMNCiAgICBmb3IgbixyIGluIFsoJ0xEU0hBUkVE JyxncHBfZXhlKSwoJ0NDJyxnY2NfZXhlKV06DQogICAgICAgIGlmIGdbbl1b OjNdPT0nZ2NjJzoNCiAgICAgICAgICAgIHByaW50ICdteV9pbml0X3Bvc2l4 OiBjaGFuZ2luZyAlcyA9ICVyJyUobixnW25dKSwNCiAgICAgICAgICAgIGdb bl0gPSByK2dbbl1bMzpdDQogICAgICAgICAgICBwcmludCAndG8nLGBnW25d YA0Kc3lzY29uZmlnLl9pbml0X3Bvc2l4ID0gbXlfaW5pdF9wb3NpeA0KDQoN CmlmIF9fbmFtZV9fID09ICJfX21haW5fXyI6DQogICAgc2V0dXAgKG5hbWUg PSAibGliYnBsMiIsDQogICAgICAgICAgIHZlcnNpb24gPSAnMC4yJywNCiAg ICAgICAgICAgZGVzY3JpcHRpb24gPSAibGliYnBsMiAtIEJvb3N0LlB5dGhv biBWMiBzaGFyZWQgbGlicmFyeSIsDQogICAgICAgICAgIGF1dGhvciA9ICJQ ZWFydSBQZXRlcnNvbiIsDQogICAgICAgICAgIGF1dGhvcl9lbWFpbCA9ICJw ZWFydUBjZW5zLmlvYy5lZSIsDQogICAgICAgICAgIG1haW50YWluZXIgPSAi UGVhcnUgUGV0ZXJzb24iLA0KICAgICAgICAgICBtYWludGFpbmVyX2VtYWls ID0gInBlYXJ1QGNlbnMuaW9jLmVlIiwNCiAgICAgICAgICAgbGljZW5jZSA9 ICJMR1BMIiwNCiAgICAgICAgICAgdXJsID0gImh0dHA6Ly9jZW5zLmlvYy5l ZS9wcm9qZWN0cy9weWdpbmFjLyIsDQogICAgICAgICAgIGV4dF9tb2R1bGVz ID0gW2V4dF0sDQogICAgICAgICAgICkNCg0K --296533764-2147227541-1033893716=:5990-- From florent.rougon@free.fr Sun Oct 6 18:06:03 2002 From: florent.rougon@free.fr (Florent Rougon) Date: Sun Oct 6 17:06:03 2002 Subject: [Distutils] MANIFEST not included In-Reply-To: <6686926.1033837495@async74-1.nas.onetel.net.uk> References: <6686926.1033837495@async74-1.nas.onetel.net.uk> Message-ID: <87ofa7jn1o.fsf@florent.hn.org> John J Lee wrote: > created. If I explicitly add it to MANIFEST.in, I get a message from > distutils telling me that MANIFEST doesn't exist (presumably because distutils > just deleted it, so it can remake it). Since you use MANIFEST.in (and not directly MANIFEST), why don't you want to put "include MANIFEST.in" in it? -- Florent From R.Liebscher@gmx.de Mon Oct 7 04:18:02 2002 From: R.Liebscher@gmx.de (=?iso-8859-1?Q?Ren=E9?= Liebscher) Date: Mon Oct 7 03:18:02 2002 Subject: [Distutils] Building ordinary shared library? References: Message-ID: <3DA1350E.13C40C7D@gmx.de> Pearu Peterson schrieb: > > On Sat, 5 Oct 2002, David Abrahams wrote: > > > Hi, > > > > I'm about to release v2 of Boost.Python, and I thought it might be nice to > > provide a distutils setup for it. We have our own build system, but some > > Python users might be more comfortable with distutils, and I have a secret > > hope that distutils will be able to work on a few paltforms we don't have > > covered such as MacOS X. > > > > I'm now kicking myself for throwing them away, but one of my users sent me > > distutils scripts for Boost.Python a while back as part of a bug report. > > > > My problems are twofold: > > > > 1. I have to distribute a shared library which is not an extension module. > > The extension modules I have to distribute (tests and examples) all link to > > this library. > > Attached is a setup_libbpl2.py file that builds libbpl2.so file containing > boost.python code. After > setup_libbpl2.py install > it can be used as follows. The setup.py file of the extension module > contains the following bits: > > from libbpl2 import __file__ as boost_so > > ext = Extension('foo', > sources=[..], > include_dirs=[boost_dir]+.., > .. > extra_objects = [boost_so], > ) > > Attachement also includes setup_ginac.py file as a real example of using > libbpl2 library. > > ... Is is not necessary to compile it as python module, you can also use the compiler classes directly. For example for PyOpenGL we make a TK module this way. see for example function togl_build in http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/pyopengl/PyOpenGL2/setup/togl_setup.py?rev=1.7&content-type=text/vnd.viewcvs-markup kind regards Rene Liebscher From jjl@pobox.com Tue Oct 8 12:07:03 2002 From: jjl@pobox.com (John J Lee) Date: Tue Oct 8 11:07:03 2002 Subject: [Distutils] MANIFEST not included In-Reply-To: <87ofa7jn1o.fsf@florent.hn.org> References: <87ofa7jn1o.fsf@florent.hn.org> Message-ID: <8493977.1034093330@async195-11.nas.onetel.net.uk> --On 06 October 2002 23:05 +0200 Florent Rougon wrote: > John J Lee wrote: > >> created. If I explicitly add it to MANIFEST.in, I get a message from >> distutils telling me that MANIFEST doesn't exist (presumably because >> distutils just deleted it, so it can remake it). > > Since you use MANIFEST.in (and not directly MANIFEST), why don't you > want to put "include MANIFEST.in" in it? I do -- and obviously, people can generate MANIFEST themselves if they like. I just wondered why MANIFEST itself doesn't end up in there. I presumed it was supposed to be there for some purpose... though I admit I don't know quite what! Package distribution system? I think I've seen MANIFEST in other packages (not necessarily Python packages), so I guess somebody has a use for it. Anyway, is it a deliberate feature of distutils that this doesn't get included? John From P.FREMY@OBERTHURCS.com Wed Oct 9 04:45:01 2002 From: P.FREMY@OBERTHURCS.com (Philippe FREMY) Date: Wed Oct 9 03:45:01 2002 Subject: [Distutils] suggestions for distutil Message-ID: <191CBBF91062D411855D00D0B76F1C30EF1AF2@PROXIMA> Hi, I am using Python 2.2 from active state, windows 2k but this is a generic problem. I like distutils, it is a very good tools but I have some suggestions: - data_files are copied directly to the python lib directory while python modules are copied in site-packages. I would find more logical to copy data file also in site-packages, so that all your product data is available in one place in the python directory. I imagine it is not possible to break the existing behaviour. But it is probably possible to specify in the doc that is is best to copy to 'Lib/site-packages/...' - the documentation says how to install data file but not how to use them from inside a python module. How do I fetch my data files ? - the syntax to use with scripts files is not given in the documentation. I am speaking about the chapter "3.4 Listing scripts" - I would like my module to be compiled/installed with optimisation by default. Is it possible ? - python setup.py --help lists many options (--license, --long-description, ...) which are not described in the documentation. I suggest to add a list of all supported keywords arguments with their meaning. - how do I uninstall ? 'python setup.py uninstall' does not work. - the user that just downloads a python program and want to install it will probably run 'python setup.py'. The help doesn't give any hint on how to install the stuff. The second command 'python setup.py --help' still doesn't give any hint about how to install. This is only after a third step that the help mention the work install for the first time. After a fourth command, the guy is able to install the packages. For such a common and easy thing as simply running the installer, it should be simpler than that. I suggest to add a "To install this package, type 'python setup.py install'" at the end of the standard help of 'python setup.py'. This would certainly help many users. regards, Philippe ########################################### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ From mal@lemburg.com Wed Oct 9 05:26:21 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed Oct 9 04:26:21 2002 Subject: [Distutils] suggestions for distutil References: <191CBBF91062D411855D00D0B76F1C30EF1AF2@PROXIMA> Message-ID: <3DA3E7E9.3060300@lemburg.com> Philippe FREMY wrote: > Hi, > > I am using Python 2.2 from active state, windows 2k but this is a generic > problem. > > I like distutils, it is a very good tools but I have some suggestions: > > - data_files are copied directly to the python lib directory while python > modules are copied in site-packages. > I would find more logical to copy data file also in site-packages, so that > all your product data is available in one place in the python directory. Funny, I have a subclass in mxSetup.py (see e.g. egenix-mx-base) which does just that. > I imagine it is not possible to break the existing behaviour. But it is > probably possible to specify in the doc that is is best to copy to > 'Lib/site-packages/...' I found the data_files handling pretty useless, which is why I wrote my own version. However, people are probably relying on the existing behaviour, so the only way to change defaults is by providing options which let you change them in e.g. setup.cfg. > - the documentation says how to install data file but not how to use them > from inside a python module. How do I fetch my data files ? If you install them inside a Python package it's really easy to get at them, because the path to the package's root dir is listed in the module as attribute. > - the syntax to use with scripts files is not given in the documentation. I > am speaking about the chapter "3.4 Listing scripts" > > - I would like my module to be compiled/installed with optimisation by > default. Is it possible ? The install command let's you pass in a parameter: --optimize (-O) also compile with optimization: -O1 for "python -O", -O2 for "python -OO", and -O0 to disable [default: -O0] > - python setup.py --help lists many options (--license, --long-description, > ...) which are not described in the documentation. I suggest to add a list > of all supported keywords arguments with their meaning. > > - how do I uninstall ? 'python setup.py uninstall' does not work. That's true. See mxSetup.py for a way to implement that command. > - the user that just downloads a python program and want to install it will > probably run 'python setup.py'. The help > doesn't give any hint on how to install the stuff. The second command > 'python setup.py --help' still doesn't give any hint about how to install. > This is only after a third step that the help mention the work install for > the first time. After a fourth command, the guy is able to install the > packages. For such a common and easy thing as simply running the installer, > it should be simpler than that. I suggest to add a "To install this package, > type 'python setup.py install'" at the end of the standard help of 'python > setup.py'. This would certainly help many users. Good idea. Could you submit a patch to SF ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From ht@cogsci.ed.ac.uk Wed Oct 9 07:43:02 2002 From: ht@cogsci.ed.ac.uk (Henry S. Thompson) Date: Wed Oct 9 06:43:02 2002 Subject: [Distutils] UCS-2/4 conflicts in distutils-produced RPM Message-ID: I've just hit a major pblm with a package I distribute which includes extension code which in turn uses Unicode functions -- it fails if the UCS2/UCS4 build state of the source/target are not the same. I've checked the archives and can't see anything about this -- is this a known problem? What's the recommended solution? Thanks ht -- Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh W3C Fellow 1999--2002, part-time member of W3C Team 2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@cogsci.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail really from me _always_ has this .sig -- mail without it is forged spam] From mal@lemburg.com Wed Oct 9 07:53:00 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed Oct 9 06:53:00 2002 Subject: [Distutils] UCS-2/4 conflicts in distutils-produced RPM References: Message-ID: <3DA40A1C.9080407@lemburg.com> Henry S. Thompson wrote: > I've just hit a major pblm with a package I distribute which includes > extension code which in turn uses Unicode functions -- it fails if the > UCS2/UCS4 build state of the source/target are not the same. I've > checked the archives and can't see anything about this -- is this a > known problem? Yes. See the Python FAQ. > What's the recommended solution? Distribute two RPMs: one for UCS2 builds and one for UCS4 builds. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From ht@cogsci.ed.ac.uk Wed Oct 9 07:59:01 2002 From: ht@cogsci.ed.ac.uk (Henry S. Thompson) Date: Wed Oct 9 06:59:01 2002 Subject: [Distutils] UCS-2/4 conflicts in distutils-produced RPM In-Reply-To: <3DA40A1C.9080407@lemburg.com> References: <3DA40A1C.9080407@lemburg.com> Message-ID: "M.-A. Lemburg" writes: > Henry S. Thompson wrote: > > I've just hit a major pblm with a package I distribute which includes > > extension code which in turn uses Unicode functions -- it fails if the > > UCS2/UCS4 build state of the source/target are not the same. I've > > checked the archives and can't see anything about this -- is this a > > known problem? > > Yes. See the Python FAQ. I meant a known problem for distutils specifically. > > What's the recommended solution? > > Distribute two RPMs: one for UCS2 builds and one for UCS4 builds. I had figured _that_ much out for myself :-) What I meant was, is there a generic approach in view for distutils in general, e.g. by making provision in Extension for specifying a Unicode dependency, which would in turn surface in the bdist name and/or in an install-time test? ht -- Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh W3C Fellow 1999--2002, part-time member of W3C Team 2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@cogsci.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail really from me _always_ has this .sig -- mail without it is forged spam] From jmiller@stsci.edu Wed Oct 9 09:05:01 2002 From: jmiller@stsci.edu (Todd Miller) Date: Wed Oct 9 08:05:01 2002 Subject: [Distutils] How do I prepend compile/link switches? Message-ID: <3DA41B40.8040804@stsci.edu> Is there an easy way to insert additional compile/link parameters for a Python extension, where the new parameters appear in the command line *before* the source/object modules? It looks like the distutils is carrying that "feature" in about half the code, but in the end, extra_compile_args and extra_link_args wind up appended to the command line. Is there a work-around, or does more work need to be done to distutils to support this? Todd -- Todd Miller jmiller@stsci.edu STSCI / SSB From P.FREMY@OBERTHURCS.com Wed Oct 9 12:59:05 2002 From: P.FREMY@OBERTHURCS.com (Philippe FREMY) Date: Wed Oct 9 11:59:05 2002 Subject: [Distutils] suggestions for distutil Message-ID: <191CBBF91062D411855D00D0B76F1C30F17BFF@PROXIMA> > > I like distutils, it is a very good tools but I have some suggestions: > > > > - data_files are copied directly to the python lib directory while python > > modules are copied in site-packages. > > I would find more logical to copy data file also in site-packages, so that > > all your product data is available in one place in the python directory. > > Funny, I have a subclass in mxSetup.py (see e.g. egenix-mx-base) which > does just that. Would it be possible to contribute it to distutils ? > > I imagine it is not possible to break the existing behaviour. But it is > > probably possible to specify in the doc that is is best to copy to > > 'Lib/site-packages/...' > > I found the data_files handling pretty useless, which is why I > wrote my own version. However, people are probably relying on the > existing behaviour, so the only way to change defaults is by > providing options which let you change them in e.g. setup.cfg. Indeed. > > - the documentation says how to install data file but not how to use them > > from inside a python module. How do I fetch my data files ? > > If you install them inside a Python package it's really easy > to get at them, because the path to the package's root dir > is listed in the module as attribute. If I have a code sample in the documentation that explains how to do it, it will be even easier. :-) It is not that I am lazy (I am), but I would like a documented supported way. I am afraid any attempt I make to code this would not be portable. > > - I would like my module to be compiled/installed with optimisation by > > default. Is it possible ? > > The install command let's you pass in a parameter: > > --optimize (-O) also compile with optimization: -O1 > for "python -O", -O2 > for "python -OO", and -O0 to disable > [default: -O0] Yes, but I want my installed module to be optimised by default. Is this possible without tweaking too much with setup.py ? I would have imagine that standard python install would optimise everything. > > - how do I uninstall ? 'python setup.py uninstall' does not work. > > That's true. See mxSetup.py for a way to implement that command. Is mxSetup a complete rewrite, or just some improvement over setup.py ? Is it possible to contribute to distutils ? regards, Philippe ########################################### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ From mal@lemburg.com Thu Oct 10 12:10:02 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu Oct 10 11:10:02 2002 Subject: [Distutils] UCS-2/4 conflicts in distutils-produced RPM References: <3DA40A1C.9080407@lemburg.com> Message-ID: <3DA597E4.8090300@lemburg.com> Henry S. Thompson wrote: > "M.-A. Lemburg" writes: > > >>Henry S. Thompson wrote: >> >>>I've just hit a major pblm with a package I distribute which includes >>>extension code which in turn uses Unicode functions -- it fails if the >>>UCS2/UCS4 build state of the source/target are not the same. I've >>>checked the archives and can't see anything about this -- is this a >>>known problem? >> >>Yes. See the Python FAQ. > > > I meant a known problem for distutils specifically. Well, I suppose that distutils package authors should be made more aware of the problem. Note however, that the problem only surfaces in case you actually use Unicode in your C extension. >>>What's the recommended solution? >> >>Distribute two RPMs: one for UCS2 builds and one for UCS4 builds. > > > I had figured _that_ much out for myself :-) Thought so :-) > What I meant was, is there a generic approach in view for distutils in > general, e.g. by making provision in Extension for specifying a > Unicode dependency, which would in turn surface in the bdist name > and/or in an install-time test? It would probably make sense to have the information go into the bdist name, but I don't see how this could be accomplished. The Python version used for building the extension decides whether you are building UCS2 or 4 -- there's no distutils option for this (simply because its a configure time feature of Python). So in the end, the packager is in control here and she could also make sure that either the name or the info with which she distributes the package carries that information. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From robin@jessikat.fsnet.co.uk Tue Oct 15 09:42:02 2002 From: robin@jessikat.fsnet.co.uk (Robin Becker) Date: Tue Oct 15 08:42:02 2002 Subject: [Distutils] lineendings Message-ID: Does distutils know or care about text file line endings? I ask only because I would like to be able to build pure python distros and have them work properly on multiple platforms. -- Robin Becker From mal@lemburg.com Tue Oct 15 16:18:01 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Tue Oct 15 15:18:01 2002 Subject: [Distutils] lineendings References: Message-ID: <3DAC69C3.10800@lemburg.com> Robin Becker wrote: > Does distutils know or care about text file line endings? I ask only > because I would like to be able to build pure python distros and have > them work properly on multiple platforms. Why do you think you need support for line ends in distutils ? For text data files, maybe ? (Python doesn't have a problem with them for source code.) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From robin@jessikat.fsnet.co.uk Tue Oct 15 16:38:01 2002 From: robin@jessikat.fsnet.co.uk (Robin Becker) Date: Tue Oct 15 15:38:01 2002 Subject: [Distutils] lineendings In-Reply-To: <3DAC69C3.10800@lemburg.com> References: <3DAC69C3.10800@lemburg.com> Message-ID: In article <3DAC69C3.10800@lemburg.com>, M.-A. Lemburg writes >Robin Becker wrote: >> Does distutils know or care about text file line endings? I ask only >> because I would like to be able to build pure python distros and have >> them work properly on multiple platforms. > >Why do you think you need support for line ends in distutils ? >For text data files, maybe ? (Python doesn't have a problem with >them for source code.) > well it certainly does in python-2.2.2 and there's pep 278 which seems to be concerned as well. Try entering import a, \ b in mac format and then execute on a windows box. I see the following C:\>\tmp\ttt.py File "C:\tmp\ttt.py", line 1 rlextrareportlab,\ ^ SyntaxError: invalid token -- Robin Becker From andy@reportlab.com Tue Oct 15 16:47:24 2002 From: andy@reportlab.com (Andy Robinson) Date: Tue Oct 15 15:47:24 2002 Subject: [Distutils] lineendings In-Reply-To: <3DAC69C3.10800@lemburg.com> Message-ID: > Why do you think you need support for line ends in distutils ? > For text data files, maybe ? (Python doesn't have a problem with > them for source code.) When you make a package on Windows and ship it to Unix it looks really ugly in VI :-) The converse is true when some sysadmin opens a Unix-built python file in Notepad. We just assumed that it would 'do the right thing' for the platform and normalize stuff somewhere. This is more of a gripe about making zip and tar.gz files than about anything else. If it's all 'unpacked' then who is to say what's right? But if you are making a zip or EXE distro, surely known text files or source files should be \r\n, and if a tar.gz then just \n. I presume the answer is that distutils doesn't do this :-) - Andy From mal@lemburg.com Tue Oct 15 17:01:38 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Tue Oct 15 16:01:38 2002 Subject: [Distutils] lineendings References: Message-ID: <3DAC73D9.5000405@lemburg.com> Andy Robinson wrote: >>Why do you think you need support for line ends in distutils ? >>For text data files, maybe ? (Python doesn't have a problem with >>them for source code.) > > > When you make a package on Windows and ship it to Unix it looks > really ugly in VI :-) The converse is true when some sysadmin > opens a Unix-built python file in Notepad. We just assumed that it > would 'do the right thing' for the platform and normalize stuff > somewhere. > > This is more of a gripe about making zip and tar.gz files than > about anything else. If it's all 'unpacked' then who is to say > what's right? But if you are making a zip or EXE distro, surely > known text files or source files should be \r\n, and if a tar.gz > then just \n. distutils uses Unix standard internally (e.g. for pathnames), so the "standard line ending" would be \n only... > I presume the answer is that distutils doesn't do this :-) ...nothing a few subclasses wouldn't be able to add, though. Of course, the right solution would be getting a decent text editor ;-) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal@lemburg.com Tue Oct 15 17:01:41 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Tue Oct 15 16:01:41 2002 Subject: [Distutils] lineendings References: <3DAC69C3.10800@lemburg.com> Message-ID: <3DAC729A.10603@lemburg.com> Robin Becker wrote: > In article <3DAC69C3.10800@lemburg.com>, M.-A. Lemburg > writes > >>Robin Becker wrote: >> >>>Does distutils know or care about text file line endings? I ask only >>>because I would like to be able to build pure python distros and have >>>them work properly on multiple platforms. >> >>Why do you think you need support for line ends in distutils ? >>For text data files, maybe ? (Python doesn't have a problem with >>them for source code.) >> > > well it certainly does in python-2.2.2 and there's pep 278 which seems > to be concerned as well. > > Try entering > > import a, \ > b > > in mac format and then execute on a windows box. I see the following > > > C:\>\tmp\ttt.py > File "C:\tmp\ttt.py", line 1 > rlextrareportlab,\ > ^ > SyntaxError: invalid token Interesting. That must be related to Macs only, though, because I move around between Windows and Unix on a regular basis and have so far never had any problem with line ends. FWIW, Python 2.3 doesn't seem to have this problem anymore and I remember that Jack worked on universal newline support some months ago. BTW, the ZIP utility has an option which takes care of text files: Zip 2.3 (November 29th 1999). Usage: zip [-options] [-b path] [-t mmddyyyy] [-n suffixes] [zipfile list] [-xi list] ... -0 store only -l convert LF to CR LF (-ll CR LF to LF) Perhaps that's the way to go ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From robin@jessikat.fsnet.co.uk Tue Oct 15 17:22:01 2002 From: robin@jessikat.fsnet.co.uk (Robin Becker) Date: Tue Oct 15 16:22:01 2002 Subject: [Distutils] lineendings In-Reply-To: <3DAC729A.10603@lemburg.com> References: <3DAC69C3.10800@lemburg.com> <3DAC729A.10603@lemburg.com> Message-ID: <3TEcTVAKiHr9EwjQ@jessikat.fsnet.co.uk> In article <3DAC729A.10603@lemburg.com>, M.-A. Lemburg writes ..... > >Interesting. That must be related to Macs only, though, because >I move around between Windows and Unix on a regular basis and >have so far never had any problem with line ends. > I think you're right, MACS use only \r which won't work properly for unix \n or dos \r\n. I just tried unix format and that seems to work ok on dos, but for 2.1.2 FreeBSD Python the dos and mac versions seem to be wrong although I may be making some obvious mistake. Python 2.1.2 (#1, Feb 22 2002, 15:59:03) [GCC 2.95.3 20010315 (release) [FreeBSD]] on freebsd4 Type "copyright", "credits" or "license" for more information. >>> open('/tmp/mac.py','wb').write('import reportlab,\r\\\trlextra\r') >>> open('/tmp/dos.py','wb').write('import reportlab,\r\n\\\trlextra\r\n') >>> /usr/RL_HOME/users/robin: # python /tmp/mac.py File "/tmp/mac.py", line 1 \ imporlextrartlab, ^ SyntaxError: invalid syntax /usr/RL_HOME/users/robin: # python /tmp/dos.py File "/tmp/dos.py", line 1 import reportlab, ^ SyntaxError: invalid syntax as for zip last time I looked it wasn't available by default on Solaris 8 or AIX etc etc, it's not even available by default on win32. -- Robin Becker From andy47@halfcooked.com Tue Oct 15 17:52:01 2002 From: andy47@halfcooked.com (Andy Todd) Date: Tue Oct 15 16:52:01 2002 Subject: [Distutils] lineendings References: <3DAC73D9.5000405@lemburg.com> Message-ID: <3DAC7F53.2080407@halfcooked.com> M.-A. Lemburg wrote: > Andy Robinson wrote: > >>> Why do you think you need support for line ends in distutils ? >>> For text data files, maybe ? (Python doesn't have a problem with >>> them for source code.) >> >> >> >> When you make a package on Windows and ship it to Unix it looks >> really ugly in VI :-) The converse is true when some sysadmin >> opens a Unix-built python file in Notepad. We just assumed that it >> would 'do the right thing' for the platform and normalize stuff >> somewhere. >> This is more of a gripe about making zip and tar.gz files than >> about anything else. If it's all 'unpacked' then who is to say what's >> right? But if you are making a zip or EXE distro, surely known text >> files or source files should be \r\n, and if a tar.gz then just \n. > > > distutils uses Unix standard internally (e.g. for pathnames), > so the "standard line ending" would be \n only... > >> I presume the answer is that distutils doesn't do this :-) > > > ...nothing a few subclasses wouldn't be able to add, though. > > Of course, the right solution would be getting a decent > text editor ;-) > Which would be VIM ;-) But seriously, to avoid this problem whilst packaging PythonCard we build the windows packages using good old 'cmd' and the *nix packages using either Cygwin or Linux (depending on what I've booted into that day). Distutils seems to use the native platform line endings when assembling the package. Regards, Andy -- ---------------------------------------------------------------------- From the desk of Andrew J Todd esq - http://www.halfcooked.com From andy@reportlab.com Tue Oct 15 17:59:12 2002 From: andy@reportlab.com (Andy Robinson) Date: Tue Oct 15 16:59:12 2002 Subject: [Distutils] lineendings In-Reply-To: <3DAC73D9.5000405@lemburg.com> Message-ID: > Of course, the right solution would be getting a decent > text editor ;-) No, it wouldn't. We have decent editors. But we ship code to people maintaining Unix systems, who should neither know nor care if it is Java or Python or Algol. If they have to edit some config file in VI when logged into a remote server, it's just wrong to ship it full of ^M thingies; someone actually phoned me and asked if it was safe to promote! At the same time I would quite like the freedom to make a package on my Windows machine, or even on a Mac. (BTW, does OS/X have Unix line endings?) I think the right solution is "a few subclasses" and one day some options in distutils to set this if you choose to. Distutils knows which files are source, tar and zip cannot be expected to. Putting it in perspective: we had a quiet day and all decided to learn distutils, so we may ask some pretty dumb things before we grasp its inner beauty, elegance and fundamental rightness ;-) - Andy From mal@lemburg.com Wed Oct 16 04:24:01 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed Oct 16 03:24:01 2002 Subject: [Distutils] lineendings References: Message-ID: <3DAD1402.2080700@lemburg.com> Andy Robinson wrote: >>Of course, the right solution would be getting a decent >>text editor ;-) > > > No, it wouldn't. We have decent editors. But we ship > code to people maintaining Unix systems, who should > neither know nor care if it is Java or Python or Algol. > If they have to edit some config file in VI when logged > into a remote server, it's just wrong to ship it full of > ^M thingies; someone actually phoned me and asked if it was > safe to promote! At the same time I would quite like the > freedom to make a package on my Windows machine, or even > on a Mac. (BTW, does OS/X have Unix line endings?) > > I think the right solution is "a few subclasses" and one > day some options in distutils to set this if you choose > to. Distutils knows which files are source, tar and zip > cannot be expected to. That's true, but currently distutils isn't messing with line ends in source code at all -- at least not from what I've seen in the source code or in practice. It does use Unix line ends in some generated files, though. One thing you should consider is shipping the software using Unix line ends to both Windows and Macs. All sane editors in those two worlds know how to deal with Unix file ends (no, Notepad is not a sane editor, it's a text widget demonstration :-). Even if you would be able to define the line endings for various different files by means of options, you'd still run into problems, since files created by your applications wouldn't change, so things would only be half backed in the end. Another problem is that of platform dependent text file mode: on some platforms this adds/removes the CR LF, on others just LF, no idea what Macs do... it's just a mess. > Putting it in perspective: we had a quiet day and all > decided to learn distutils, so we may ask some pretty > dumb things before we grasp its inner beauty, elegance > and fundamental rightness ;-) Oh dear ;-) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mwh@python.net Wed Oct 16 07:48:02 2002 From: mwh@python.net (Michael Hudson) Date: Wed Oct 16 06:48:02 2002 Subject: [Distutils] lineendings In-Reply-To: "Andy Robinson"'s message of "Tue, 15 Oct 2002 21:56:39 +0100" References: Message-ID: <2mr8eqslrx.fsf@starship.python.net> "Andy Robinson" writes: > > Of course, the right solution would be getting a decent > > text editor ;-) > > No, it wouldn't. We have decent editors. But we ship > code to people maintaining Unix systems, who should > neither know nor care if it is Java or Python or Algol. > If they have to edit some config file in VI when logged > into a remote server, it's just wrong to ship it full of > ^M thingies; someone actually phoned me and asked if it was > safe to promote! At the same time I would quite like the > freedom to make a package on my Windows machine, or even > on a Mac. In Python 2.3, this will be better. PEP 278, I think. Maybe this could be ported to the 2.2 line after 2.3 is out and all the bugs have been shaken out of it. > (BTW, does OS/X have Unix line endings?) I think that depends :-/ > I think the right solution is "a few subclasses" and one > day some options in distutils to set this if you choose > to. Distutils knows which files are source, tar and zip > cannot be expected to. I think so far distutils has made the right choice on this one: be dumb. This is much less aggravating than trying to do something smart and stuffing it up would be, IMHO. > Putting it in perspective: we had a quiet day and all > decided to learn distutils, so we may ask some pretty > dumb things before we grasp its inner beauty, elegance > and fundamental rightness ;-) If you can fix all the horrible bits while you're at it, that would be even better :) Cheers, M. -- "Well, the old ones go Mmmmmbbbbzzzzttteeeeeep as they start up and the new ones go whupwhupwhupwhooopwhooooopwhooooooommmmmmmmmm." -- Graham Reed explains subway engines on asr From flash@itp.tu-graz.ac.at Thu Oct 17 08:35:03 2002 From: flash@itp.tu-graz.ac.at (Christian Pfaffel) Date: Thu Oct 17 07:35:03 2002 Subject: [Distutils] distutils & AFS Message-ID: <7g8z0x8fy6.fsf@faeppc20.tu-graz.ac.at> --=-=-= -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello! I have a problem with using distutils on a filesystem residing on AFS. AFS does not allow hard-linking across directory boundaries. So the copy method from file_util.py using hard links files fails, e.g.: # ./setup.py sdist running sdist reading manifest file 'MANIFEST' making hard links in foo-1.0... hard linking MANIFEST.in -> foo-1.0 error: Invalid cross-device link The system I run is linux, thus it tries to hard link, I did not dig too deep into file_util.py but I figured out that it is the link mode which has to be set to None to make it working on AFS so that it copies files. I made a rather non elegant change to the code, which I attached. I am sure that you can come up with a better solution. I do, unfortunately not have the time, to fix it elsewhere. Just wanted to let you know. Best regards, Christian Pfaffel --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=file_util.py.diff Content-Description: patch for an ugly fix --- /usr/lib/python2.2/distutils/file_util.py~ Fri Apr 12 21:30:22 2002 +++ /usr/lib/python2.2/distutils/file_util.py Wed Oct 16 17:30:04 2002 @@ -151,7 +151,20 @@ # (Unix only, of course, but that's the caller's responsibility) elif link == 'hard': if not (os.path.exists(dst) and os.path.samefile(src, dst)): - os.link(src, dst) + try: + os.link(src, dst) + except: + _copy_file_contents(src, dst) + if preserve_mode or preserve_times: + st = os.stat(src) + + # According to David Ascher , utime() should be done + # before chmod() (at least under NT). + if preserve_times: + os.utime(dst, (st[ST_ATIME], st[ST_MTIME])) + if preserve_mode: + os.chmod(dst, S_IMODE(st[ST_MODE])) + elif link == 'sym': if not (os.path.exists(dst) and os.path.samefile(src, dst)): os.symlink(src, dst) --=-=-= - -- PGP-Key: http://fubphpc.tu-graz.ac.at/~flash/pubkey.gpg -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.7 iD8DBQE9rqAzzNp7/ndBhMQRAoO3AJ90Q77x3TUU6S/OaP/ehzKbFYrIWACcDBBZ UK4XthK4zZjpSYRxxRCBoTY= =bfqa -----END PGP SIGNATURE----- --=-=-=-- From thomas.heller@ion-tof.com Fri Oct 18 13:01:22 2002 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Fri Oct 18 12:01:22 2002 Subject: [Distutils] source distributions for compiler-less machines Message-ID: I'm currently hacking together a python package management system - I have some free time over the weekend ;-). I just had an idea how to prepare source-distributions for people (on windows) without a compiler: The developer could just call 'setup.py build' before calling 'setup.py sdist', add the '--no-prune' flag to the sdist command, add 'recursive-include build *.*' to the MANIFEST.in file, and now the build directory, with the object files and binary extension files is included in the zip file. This source distribution can now be installed by 'setup.py install' just as usual - since all targets are up to date, the (nonexistant) C compiler will not be called. Any comments on this idea? Thomas From mal@lemburg.com Fri Oct 18 15:18:24 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri Oct 18 14:18:24 2002 Subject: [Distutils] source distributions for compiler-less machines References: Message-ID: <3DB0502A.6000202@lemburg.com> Thomas Heller wrote: > I'm currently hacking together a python package management system - I > have some free time over the weekend ;-). > > I just had an idea how to prepare source-distributions for people > (on windows) without a compiler: > > The developer could just call 'setup.py build' before calling > 'setup.py sdist', add the '--no-prune' flag to the sdist command, add > 'recursive-include build *.*' to the MANIFEST.in file, and now the > build directory, with the object files and binary extension files is > included in the zip file. > > This source distribution can now be installed by 'setup.py install' > just as usual - since all targets are up to date, the (nonexistant) C > compiler will not be called. > > Any comments on this idea? That's pretty close to what ActiveState is doing with their PPM format. Unfortunately, they haven't so far decided whether to contribute the code for this or not, but PPMs are basically pre-built, but uninstalled distutils packages. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From andersjm@dancontrol.dk Mon Oct 21 08:31:01 2002 From: andersjm@dancontrol.dk (Anders J. Munch) Date: Mon Oct 21 07:31:01 2002 Subject: [Distutils] Sharing code between C extensions Message-ID: <005701c278f4$e1d967b0$2501a8c0@quebec> Hi all, I have a set of C extensions that I developed while using my own Borland compiler Win32 Python build, statically linking the whole thing. Recently I gave up on using that special build, too much hassle to get third-party stuff (like wxWindows) to work. So now I'm using distutils, and I must say it's been surprisingly smooth sailing so far. Good work guys! I've hit a snag, though: My C extensions (are supposed to) share code and data. But distutils insists that each extension be self-contained and include everything that it depends on. So that means that some of my C extensions and library code now exists in multiple copies, one copy per extension. I don't mind the memory used; but the duplicated static data and duplicated type objects are causing problems. I guess placing the shared stuff in a DLL is an option but not one I'm too fond of, for various reasons. (Or perhaps I should switch to Linux where shared objects behave differently? Well, some other time, perhaps ;-)) What I'd like to do is to have multiple C extensions in the same .pyd. Like, instead of writing (simplified): ext_modules = [Extension('foo', source=['foo.cc']), Extension('bar', source=['bar.cc'])] if I could do: ext_modules = [Extension(['foo','bar'], source=['foo.cc','bar.cc'])] and have both extensions in the same .pyd. Hmm... come to think of it I guess I could fake it with ext_modules = [Extension('foo', source=['foo.cc', 'bar.cc'])] and then calling initbar() from initfoo(). I'd like to find a cleaner solution though. regards, Anders From mal@lemburg.com Mon Oct 21 16:04:01 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon Oct 21 15:04:01 2002 Subject: [Distutils] Sharing code between C extensions References: <005701c278f4$e1d967b0$2501a8c0@quebec> Message-ID: <3DB44F68.4000705@lemburg.com> Anders J. Munch wrote: > Hi all, > > I have a set of C extensions that I developed while using my own > Borland compiler Win32 Python build, statically linking the whole > thing. Recently I gave up on using that special build, too much > hassle to get third-party stuff (like wxWindows) to work. > > So now I'm using distutils, and I must say it's been surprisingly > smooth sailing so far. Good work guys! > > I've hit a snag, though: My C extensions (are supposed to) share code > and data. But distutils insists that each extension be self-contained > and include everything that it depends on. > > So that means that some of my C extensions and library code now exists > in multiple copies, one copy per extension. I don't mind the memory > used; but the duplicated static data and duplicated type objects are > causing problems. > > I guess placing the shared stuff in a DLL is an option but not one I'm > too fond of, for various reasons. (Or perhaps I should switch to > Linux where shared objects behave differently? Well, some other time, > perhaps ;-)) > > What I'd like to do is to have multiple C extensions in the same .pyd. > Like, instead of writing (simplified): > ext_modules = [Extension('foo', source=['foo.cc']), > Extension('bar', source=['bar.cc'])] > if I could do: > ext_modules = [Extension(['foo','bar'], source=['foo.cc','bar.cc'])] > and have both extensions in the same .pyd. > > Hmm... come to think of it I guess I could fake it with > ext_modules = [Extension('foo', source=['foo.cc', 'bar.cc'])] > and then calling initbar() from initfoo(). I'd like to find a cleaner > solution though. That won't work: Python uses the DLL name to determine the init function name, so in your example it will look for initfoo(). If you want to share data between extensions, the right thing to do is to wrap the data in a PyCObject which you then access using the standard Python import mechanisms. Works great. See mxDateTime for an example on this can be done or the interaction between socketmodule.c|h and _ssl.c in Python itself. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From gward@python.net Mon Oct 21 19:07:06 2002 From: gward@python.net (Greg Ward) Date: Mon Oct 21 18:07:06 2002 Subject: [Distutils] Re: python installation question... In-Reply-To: References: Message-ID: <20021021220510.GA16284@cthulhu.gerg.ca> [In the future, please ask distutils questions on distutils-sig@python.org.] On 21 October 2002, Tom Rauch said: > I'm trying to install MySQL-python-0.9.0 on a RH 7.3 box. I get this > message about "sklpping byte compilation" which I suspect is > preventing the Zope MySQL database adapter from being installed. I > saw on the web that you've had some experience with this error > message...can you offer any suggestions on how to work around this? The "skipping byte compilation" message simply means that you already have a version of MySQL-python installed on that box. Since the distutils skipped byte compilation for *all* files, you probably already have the exact version that you're trying to install. You might try blowing away the existing MySQL-python installation and starting from scratch. Greg -- Greg Ward http://www.gerg.ca/ Rules for Urban Cycling, #1: Green means go; yellow means go like hell; red means proceed with caution. From Jack.Jansen@oratrix.com Mon Oct 21 19:08:02 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Mon Oct 21 18:08:02 2002 Subject: [Distutils] Sharing code between C extensions In-Reply-To: <005701c278f4$e1d967b0$2501a8c0@quebec> Message-ID: <51F4E642-E541-11D6-9C45-003065517236@oratrix.com> On maandag, oktober 21, 2002, at 01:27 , Anders J. Munch wrote: > What I'd like to do is to have multiple C extensions in the same .pyd. All attempts to do this lead to disaster. If it isn't on your platform it is on another one. And the same is true for multiple .pyd files, each containing a single module, that link against each other. (I know: been there, done that:-) There's two solutions I use for this, but you'd have to work out the distutils magic for yourself: 1. Use a normal shared library (.dll, .so) for the shared code and/or the glue between the modules. Use a shared-data DLL if you need to share data. On some OSes you can get away with putting the dll in the same directory as the pyd's, on others you may have to install it in a system location. PythonWin does something like this with PyWinTypes. MacPython does it with a little help from the core. 2. Use Python's import mechanism. In module A's init() routine import module B. Call a special method in B that returns a pointer (coded a Python integer or Cobject or some such). You now have a pointer from one module to the other. Numeric does this. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From andersjm@dancontrol.dk Tue Oct 22 06:40:02 2002 From: andersjm@dancontrol.dk (Anders J. Munch) Date: Tue Oct 22 05:40:02 2002 Subject: [Distutils] Sharing code between C extensions References: <005701c278f4$e1d967b0$2501a8c0@quebec> <3DB44F68.4000705@lemburg.com> Message-ID: <003401c279ae$b8361e20$2501a8c0@quebec> From: "M.-A. Lemburg" > > My C extensions (are supposed to) share code > > and data. But distutils insists that each extension be self-contained > > and include everything that it depends on. [....] > > Hmm... come to think of it I guess I could fake it with > > ext_modules = [Extension('foo', source=['foo.cc', 'bar.cc'])] > > and then calling initbar() from initfoo(). I'd like to find a cleaner > > solution though. > > That won't work: Python uses the DLL name to determine the > init function name, so in your example it will look for > initfoo(). I tried it out and I see what you mean. I figure the point is that the .pyd isn't (necessarily) loaded until "import foo" forces it, so I can't expect "import bar" to work. But then if I require "import bar" to always be preceeded by "import foo", it seems to work. Yeah I know, "seems", but then it doesn't need to be completely polished, and it doesn't need to be portable, as this is just for an internal distribution whose current user count is 2. > If you want to share data between extensions, the right > thing to do is to wrap the data in a PyCObject which you > then access using the standard Python import mechanisms. Ok, I took a look at PyCObjects and I can see how this is the way to go for a serious Python extension with wide distribution. It would, at the cost of some added complexity and void*-magic, solve part of the problem. But no all of it - it's no good for using Python to wrap source trees with internal dependencies: Say I have three C files, foo.c, bar.c and shared.c, that I want to access from Python as separate modules, and to do that I write some wrapper code in pyFoo.c, pyBar.c and pyShared.c. foo.c and bar.c both call functions in shared.c. I can't use PyCObjects here without modifying the original source code. But the original source code is used in other places too and shouldn't depend on Python. - Anders From andersjm@dancontrol.dk Tue Oct 22 06:41:01 2002 From: andersjm@dancontrol.dk (Anders J. Munch) Date: Tue Oct 22 05:41:01 2002 Subject: [Distutils] Sharing code between C extensions References: <51F4E642-E541-11D6-9C45-003065517236@oratrix.com> Message-ID: <003501c279ae$c7cd5bf0$2501a8c0@quebec> From: "Jack Jansen" > > On maandag, oktober 21, 2002, at 01:27 , Anders J. Munch wrote: > > What I'd like to do is to have multiple C extensions in the same .pyd. > > All attempts to do this lead to disaster. Whoa, did you burn down your house trying or something? ;-> >If it isn't on your > platform it is on another one. And the same is true for multiple > .pyd files, each containing a single module, that link against > each other. (I know: been there, done that:-) Now this is just for in-house use, so I'm going with the half-baked solution calling inits from inits, unless you can point to some disaster that will happen even on a single (Win32) platform. I presume you were trying for a complete and portable solution. - Anders From rjones@ekit-inc.com Tue Oct 22 22:22:02 2002 From: rjones@ekit-inc.com (Richard Jones) Date: Tue Oct 22 21:22:02 2002 Subject: [Distutils] Online index for distutils Message-ID: <200210231120.25208.rjones@ekit-inc.com> [edited repost of mail sent to catalog-sig yesterday] I have written a simple CGI and distutils command that handles registration of distutils package metadata in a central index. The intention is that this system is run on python.org, mostly to lend it an air of legitimacy. It's simple, it's bare-bones, it works: http://mechanicalcat.net:8081/ I just figured we needed _something_ to get out there to start the ball rolling. And I'm serious about the python.org part... I've trawled through the distutils archive and found several references to Trove, and "sounds like a good idea" but Trove metadata attributes never made it into distutils distribution metadata. Can anyone explain why? It'd make the above index a whole lot easier to search... Richard From mal@lemburg.com Wed Oct 23 08:06:01 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed Oct 23 07:06:01 2002 Subject: [Distutils] How to find out the default include path Message-ID: <3DB6825E.1040001@lemburg.com> Is there a way to find out the default include path used by a compiler ? Does distutils have an API for this ? I scanned the code but couldn't find any hint. Thanks, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal@lemburg.com Wed Oct 23 08:55:01 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed Oct 23 07:55:01 2002 Subject: [Distutils] How to find out the default include path References: <3DB6825E.1040001@lemburg.com> Message-ID: <3DB68DF5.1000706@lemburg.com> M.-A. Lemburg wrote: > Is there a way to find out the default include path > used by a compiler ? Does distutils have an API for > this ? > > I scanned the code but couldn't find any hint. So far I found these defaults: Linux: libs: /lib, /usr/lib headers: /usr/include Windows: libs: $LIB headers: $INCLUDE Are there similar settings or environment variables on other platforms ? Thanks, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From thomas.heller@ion-tof.com Wed Oct 23 09:22:01 2002 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Wed Oct 23 08:22:01 2002 Subject: [Distutils] Re: How to find out the default include path References: <3DB6825E.1040001@lemburg.com> <3DB68DF5.1000706@lemburg.com> Message-ID: <65vt5p76.fsf@ion-tof.com> "M.-A. Lemburg" writes: > M.-A. Lemburg wrote: > > Is there a way to find out the default include path > > used by a compiler ? Does distutils have an API for > > this ? > > I scanned the code but couldn't find any hint. > > > So far I found these defaults: > > Linux: > libs: /lib, /usr/lib > headers: /usr/include > > Windows: > libs: $LIB > headers: $INCLUDE Hm, what do you mean? These are not always set on Windows, depending on how MSVC was installed. You are aware of the function get_msvc_paths() in msvccompiler.py? Thomas From mal@lemburg.com Wed Oct 23 09:59:02 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed Oct 23 08:59:02 2002 Subject: [Distutils] Re: How to find out the default include path References: <3DB6825E.1040001@lemburg.com> <3DB68DF5.1000706@lemburg.com> <65vt5p76.fsf@ion-tof.com> Message-ID: <3DB69CD3.6010000@lemburg.com> Thomas Heller wrote: > "M.-A. Lemburg" writes: > > >>M.-A. Lemburg wrote: >> >>>Is there a way to find out the default include path >>>used by a compiler ? Does distutils have an API for >>>this ? >>>I scanned the code but couldn't find any hint. >> >> >>So far I found these defaults: >> >>Linux: >> libs: /lib, /usr/lib >> headers: /usr/include >> >>Windows: >> libs: $LIB >> headers: $INCLUDE > > > Hm, what do you mean? I took the Windows environment vars from the the file vcvars32.bat that comes with VC++ > These are not always set on Windows, depending > on how MSVC was installed. > > You are aware of the function get_msvc_paths() in msvccompiler.py? Not until now :-) What about other Unixes and MacOS ? Thanks, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From pearu@cens.ioc.ee Wed Oct 23 10:13:01 2002 From: pearu@cens.ioc.ee (Pearu Peterson) Date: Wed Oct 23 09:13:01 2002 Subject: [Distutils] How to find out the default include path In-Reply-To: <3DB68DF5.1000706@lemburg.com> Message-ID: On Wed, 23 Oct 2002, M.-A. Lemburg wrote: > M.-A. Lemburg wrote: > > Is there a way to find out the default include path > > used by a compiler ? Does distutils have an API for > > this ? > > > > I scanned the code but couldn't find any hint. > > So far I found these defaults: > > Linux: > libs: /lib, /usr/lib > headers: /usr/include /lib is used by the system, python related stuff should never go there, not even look there. Under Linux I would suggest the following defaults: libs: /usr/local/lib, /opt/lib, /usr/lib headers: /usr/local/include, /opt/include, /usr/include If it matters, add also /lib, /include (some people install Python with --prefix=$HOME, for example). Also, compilers may use their one include/lib directories, e.g. gcc uses /lib/gcc-lib/i686-pc-linux-gnu/3.0.4/ /include/g++-v3/ Pearu From mal@lemburg.com Wed Oct 23 10:20:01 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed Oct 23 09:20:01 2002 Subject: [Distutils] How to find out the default include path References: Message-ID: <3DB6A1A9.2080208@lemburg.com> Pearu Peterson wrote: > On Wed, 23 Oct 2002, M.-A. Lemburg wrote: > > >>M.-A. Lemburg wrote: >> >>>Is there a way to find out the default include path >>>used by a compiler ? Does distutils have an API for >>>this ? >>> >>>I scanned the code but couldn't find any hint. >> >>So far I found these defaults: >> >>Linux: >> libs: /lib, /usr/lib >> headers: /usr/include > > > /lib is used by the system, python related stuff should never go > there, not even look there. Ok. > Under Linux I would suggest the following defaults: > > libs: /usr/local/lib, /opt/lib, /usr/lib > headers: /usr/local/include, /opt/include, /usr/include Thanks. > If it matters, add also /lib, /include (some > people install Python with --prefix=$HOME, for example). Well, these paths are needed to find 3rd party libs to link against, so I'd suspect that Python dirs are not necessary on the default paths. > Also, compilers may use their one include/lib directories, e.g. gcc uses > /lib/gcc-lib/i686-pc-linux-gnu/3.0.4/ > /include/g++-v3/ Right, but again, these probably don't contain the libs I'm looking for in the search for 3rd party libs. Should have mentioned that before: The idea is to try the same lookups as the compiler does per default when you don't pass in any -Ipath options. This is needed for auto configuration since I have to check lib and header versions (and sometimes even for naming conflicts) in these files. Thanks again, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal@lemburg.com Wed Oct 23 10:26:01 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed Oct 23 09:26:01 2002 Subject: [Distutils] How to find out the default include path References: Message-ID: <3DB6A30F.40309@lemburg.com> Pearu Peterson wrote: > On Wed, 23 Oct 2002, M.-A. Lemburg wrote: > > > Under Linux I would suggest the following defaults: > > libs: /usr/local/lib, /opt/lib, /usr/lib > headers: /usr/local/include, /opt/include, /usr/include Is /opt/include on the compiler's default include path or not ? Dito for /opt/lib ? BTW, is there a way to query the default search path for header files in GCC ? I have so far only found the default path for libs. Thanks, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From pearu@cens.ioc.ee Wed Oct 23 10:27:01 2002 From: pearu@cens.ioc.ee (Pearu Peterson) Date: Wed Oct 23 09:27:01 2002 Subject: [Distutils] How to find out the default include path In-Reply-To: <3DB6A1A9.2080208@lemburg.com> Message-ID: On Wed, 23 Oct 2002, M.-A. Lemburg wrote: > Pearu Peterson wrote: > > If it matters, add also /lib, /include (some > > people install Python with --prefix=$HOME, for example). > > Well, these paths are needed to find 3rd party libs to link > against, so I'd suspect that Python dirs are not necessary > on the default paths. Actually, people may install also 3rd party libs to $HOME. In fact, sometimes Python itself can be considered as one. I do it consistently when I happen to work on a system where I don't have root permissions and sysadmins are so slow to install anything from the 3rd party. Pearu From mal@lemburg.com Wed Oct 23 10:32:02 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed Oct 23 09:32:02 2002 Subject: [Distutils] How to find out the default include path References: Message-ID: <3DB6A47A.1080806@lemburg.com> Pearu Peterson wrote: > On Wed, 23 Oct 2002, M.-A. Lemburg wrote: > > >>Pearu Peterson wrote: > > >>>If it matters, add also /lib, /include (some >>>people install Python with --prefix=$HOME, for example). >> >>Well, these paths are needed to find 3rd party libs to link >>against, so I'd suspect that Python dirs are not necessary >>on the default paths. > > > Actually, people may install also 3rd party libs to $HOME. In fact, > sometimes Python itself can be considered as one. > > I do it consistently when I happen to work on a system where I don't have > root permissions and sysadmins are so slow to install anything from the > 3rd party. Ok, good argument. I'll add that as well, then. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From pearu@cens.ioc.ee Wed Oct 23 10:39:02 2002 From: pearu@cens.ioc.ee (Pearu Peterson) Date: Wed Oct 23 09:39:02 2002 Subject: [Distutils] How to find out the default include path In-Reply-To: <3DB6A30F.40309@lemburg.com> Message-ID: On Wed, 23 Oct 2002, M.-A. Lemburg wrote: > Pearu Peterson wrote: > > On Wed, 23 Oct 2002, M.-A. Lemburg wrote: > > > > > > Under Linux I would suggest the following defaults: > > > > libs: /usr/local/lib, /opt/lib, /usr/lib > > headers: /usr/local/include, /opt/include, /usr/include > > Is /opt/include on the compiler's default include path or not ? > Dito for /opt/lib ? Depends on the compiler. For example, the default prefix for Intel compiler is /opt/intel. Though, /opt is more often used on other unices than on Linux, but still used also on Linux (depends on the background of a local sysadmin). > BTW, is there a way to query the default search path for > header files in GCC ? I have so far only found the default > path for libs. In principle, one should let the compiler to take care of its paths. Anyway, the answer depends on the version of the compiler. For example, in the case of gcc-3.1, you can study the output of 'gcc -v'. For earlier versions, 2.95 for instance, you can get the lib path and then extrapolate from that the include path (by ../../../../include/g++-v or something like that). Pearu From mats@laplaza.org Wed Oct 23 11:51:00 2002 From: mats@laplaza.org (Mats Wichmann) Date: Wed Oct 23 10:51:00 2002 Subject: [Distutils] How to find out the default include path In-Reply-To: <3DB68DF5.1000706@lemburg.com> References: <3DB6825E.1040001@lemburg.com> Message-ID: <5.1.0.14.1.20021023084146.029bba80@204.151.72.2> At 01:54 PM 10/23/2002 +0200, M.-A. Lemburg wrote: >M.-A. Lemburg wrote: >> Is there a way to find out the default include path >> used by a compiler ? Does distutils have an API for >> this ? >> >> I scanned the code but couldn't find any hint. > >So far I found these defaults: > >Linux: > libs: /lib, /usr/lib > headers: /usr/include Depends on what you mean by "default" :-) For any given Linux system, the linker will search libraries in locations built in to the compilation system (I think your list is correct there), plus whatever's listed in /etc/ld.so.conf. Sometimes assisted or hampered by what's in /etc/ld.so.cache :-{ Headers are searched in /usr/local/include and /usr/include, plus a compiler-private directory (pathname determined by compiler version and host details). It's possible, if the compiler indeed is gcc, to ask the compiler to tell you the path to the "specs" file for that compiler which you can then examine to obtain more details than you wanted....(ahem, I've actually had to do this, please don't ask why). From mal@lemburg.com Thu Oct 24 06:21:01 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu Oct 24 05:21:01 2002 Subject: [Distutils] How to find out the default include path References: <3DB6825E.1040001@lemburg.com> <5.1.0.14.1.20021023084146.029bba80@204.151.72.2> Message-ID: <3DB7BB47.5040500@lemburg.com> Mats Wichmann wrote: > At 01:54 PM 10/23/2002 +0200, M.-A. Lemburg wrote: > >M.-A. Lemburg wrote: > >> Is there a way to find out the default include path > >> used by a compiler ? Does distutils have an API for > >> this ? > >> > >> I scanned the code but couldn't find any hint. > > > >So far I found these defaults: > > > >Linux: > > libs: /lib, /usr/lib > > headers: /usr/include > > Depends on what you mean by "default" :-) What I'm working on is an automatic system for finding 3rd party libs to link against, e.g. say I have an extension which links against OpenSSL I want the setup.py to automatically find the .so and .h files. It easy to simply look in a few directories, but I found that I have to be very careful about adding things like -I/usr/include to the compiler run, because on some systems this can bomb (the compiler picks up non-compiler compatible standard C header files, like e.g. stdarg.h). > For any given Linux system, the linker will search > libraries in locations built in to the compilation > system (I think your list is correct there), plus > whatever's listed in /etc/ld.so.conf. Sometimes > assisted or hampered by what's in /etc/ld.so.cache :-{ Does the linker search there too or only the dynamic one at load time ? > Headers are searched in /usr/local/include and > /usr/include, plus a compiler-private directory > (pathname determined by compiler version and > host details). > > It's possible, if the compiler indeed is gcc, > to ask the compiler to tell you the path to > the "specs" file for that compiler which you can > then examine to obtain more details than you > wanted....(ahem, I've actually had to do this, > please don't ask why). Thanks, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From pearu@cens.ioc.ee Thu Oct 24 07:13:01 2002 From: pearu@cens.ioc.ee (Pearu Peterson) Date: Thu Oct 24 06:13:01 2002 Subject: [Distutils] How to find out the default include path In-Reply-To: <3DB7BB47.5040500@lemburg.com> Message-ID: On Thu, 24 Oct 2002, M.-A. Lemburg wrote: > Mats Wichmann wrote: > > > > Depends on what you mean by "default" :-) > > What I'm working on is an automatic system for finding 3rd > party libs to link against, e.g. say I have an extension > which links against OpenSSL I want the setup.py to > automatically find the .so and .h files. Have you looked at scipy/scipy_distutils/system_info.py? It does exactly this thing for various 3rd party software like atlas,blas,lapack,X11,fftw,etc. and is meant to be easily extendable. See http://scipy.net/cgi-bin/viewcvsx.cgi/*checkout*/scipy/scipy_distutils/system_info.py?content-type=text/plain > > For any given Linux system, the linker will search > > libraries in locations built in to the compilation > > system (I think your list is correct there), plus > > whatever's listed in /etc/ld.so.conf. Sometimes > > assisted or hampered by what's in /etc/ld.so.cache :-{ > > Does the linker search there too or only the dynamic > one at load time ? I think /etc/ld.so.conf is looked during the load time, linker never uses it. HTH, Pearu From mwh@python.net Thu Oct 24 07:30:02 2002 From: mwh@python.net (Michael Hudson) Date: Thu Oct 24 06:30:02 2002 Subject: [Distutils] How to find out the default include path In-Reply-To: "M.-A. Lemburg"'s message of "Thu, 24 Oct 2002 11:20:07 +0200" References: <3DB6825E.1040001@lemburg.com> <5.1.0.14.1.20021023084146.029bba80@204.151.72.2> <3DB7BB47.5040500@lemburg.com> Message-ID: <2madl4t9iv.fsf@starship.python.net> "M.-A. Lemburg" writes: > Mats Wichmann wrote: > > At 01:54 PM 10/23/2002 +0200, M.-A. Lemburg wrote: > > >M.-A. Lemburg wrote: > > >> Is there a way to find out the default include path > > >> used by a compiler ? Does distutils have an API for > > >> this ? > > >> > > >> I scanned the code but couldn't find any hint. > > > > > >So far I found these defaults: > > > > > >Linux: > > > libs: /lib, /usr/lib > > > headers: /usr/include > > > > Depends on what you mean by "default" :-) > > What I'm working on is an automatic system for finding 3rd > party libs to link against, e.g. say I have an extension > which links against OpenSSL I want the setup.py to > automatically find the .so and .h files. > > It easy to simply look in a few directories, but I found > that I have to be very careful about adding things like > -I/usr/include to the compiler run, because on some systems > this can bomb (the compiler picks up non-compiler compatible > standard C header files, like e.g. stdarg.h). I would have thought the autoconf approach of trial compilations is the only reasonable way of doing this. Cheers, M. -- Sufficiently advanced political correctness is indistinguishable from irony. -- Erik Naggum From robin@jessikat.fsnet.co.uk Thu Oct 24 08:08:02 2002 From: robin@jessikat.fsnet.co.uk (Robin Becker) Date: Thu Oct 24 07:08:02 2002 Subject: [Distutils] How to find out the default include path In-Reply-To: <3DB7BB47.5040500@lemburg.com> References: <3DB6825E.1040001@lemburg.com> <5.1.0.14.1.20021023084146.029bba80@204.151.72.2> <3DB7BB47.5040500@lemburg.com> Message-ID: In article <3DB7BB47.5040500@lemburg.com>, M.-A. Lemburg writes ...... > >> For any given Linux system, the linker will search >> libraries in locations built in to the compilation >> system (I think your list is correct there), plus >> whatever's listed in /etc/ld.so.conf. Sometimes >> assisted or hampered by what's in /etc/ld.so.cache :-{ > >Does the linker search there too or only the dynamic >one at load time ? I thought that executables could specify a preferred location as well for use at dynamic link time, and then there's also LD_LIBRARY_PATH etc etc, must be at least 10 ways to shoot your own foot. -- Robin Becker From mal@lemburg.com Fri Oct 25 09:22:00 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri Oct 25 08:22:00 2002 Subject: [Distutils] How to find out the default include path References: Message-ID: <3DB9373D.7070103@lemburg.com> Pearu Peterson wrote: > On Thu, 24 Oct 2002, M.-A. Lemburg wrote: > > >>Mats Wichmann wrote: >> >>>Depends on what you mean by "default" :-) >> >>What I'm working on is an automatic system for finding 3rd >>party libs to link against, e.g. say I have an extension >>which links against OpenSSL I want the setup.py to >>automatically find the .so and .h files. > > > Have you looked at scipy/scipy_distutils/system_info.py? > It does exactly this thing for various 3rd party software like > atlas,blas,lapack,X11,fftw,etc. and is meant to be easily extendable. > See > > http://scipy.net/cgi-bin/viewcvsx.cgi/*checkout*/scipy/scipy_distutils/system_info.py?content-type=text/plain Interesting. That approach is quite similar to what I'm doing in mxSetup.py for my packages. I've also added a reg. expr. search on the files to work around naming conflicts (e.g. ODBC data drivers tend to all use the same names for names for certain header files), so that I can identify these based on the success of the RE search, e.g. # SAP DB 7.3.0.21 ODBC driver mx_Extension('mx.ODBC.SAPDB.mxODBC', ['mx/ODBC/SAPDB/mxODBC.c', 'mx/ODBC/SAPDB/mxSQLCodes.c'], include_dirs=['mx/ODBC/SAPDB'], define_macros=[('SAPDB', None)], needed_includes=[('sql.h', ['/opt/sapdb/interfaces/odbc/incl'], 'ODBC Core functions')], needed_libraries=[('sqlod', ['/opt/sapdb/interfaces/odbc/lib'], '\[SAP DB\]')], data_files=['mx/ODBC/SAPDB/COPYRIGHT', 'mx/ODBC/SAPDB/LICENSE', 'mx/ODBC/SAPDB/README'], packages=['mx.ODBC.SAPDB'], required=0 ), Thanks, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From amk@amk.ca Wed Oct 30 20:19:02 2002 From: amk@amk.ca (A.M. Kuchling) Date: Wed Oct 30 20:19:02 2002 Subject: [Distutils] Proposed patch: allowing unknown keywords Message-ID: <20021030204046.A1748@nyman.amk.ca> I'd like to check in the following patch; it causes unknown keywords in the setup() invocation to trigger a warning instead of an exception. This will make it possible to add more metadata arguments to setup() in future versions while still letting packages be installed with Distutils versions lacking the added arguments. Any objections? Should it be backported to Python 2.2? --amk Index: dist.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/distutils/dist.py,v retrieving revision 1.56 diff -u -u -r1.56 dist.py --- dist.py 11 Sep 2002 16:31:52 -0000 1.56 +++ dist.py 31 Oct 2002 00:24:55 -0000 @@ -9,7 +9,7 @@ __revision__ = "$Id: dist.py,v 1.56 2002/09/11 16:31:52 jhylton Exp $" -import sys, os, string, re +import sys, os, string, re, warnings from types import * from copy import copy from distutils.errors import * @@ -206,8 +206,7 @@ elif hasattr(self, key): setattr(self, key, val) else: - raise DistutilsSetupError, \ - "invalid distribution option '%s'" % key + warnings.warn("Unknown distribution option: %r" % key) self.finalize_options() From tim.one@comcast.net Wed Oct 30 21:44:02 2002 From: tim.one@comcast.net (Tim Peters) Date: Wed Oct 30 21:44:02 2002 Subject: [Distutils] Proposed patch: allowing unknown keywords In-Reply-To: <20021030204046.A1748@nyman.amk.ca> Message-ID: [A.M. Kuchling] > I'd like to check in the following patch; it causes unknown keywords > in the setup() invocation to trigger a warning instead of an > exception. This will make it possible to add more metadata arguments > to setup() in future versions while still letting packages be > installed with Distutils versions lacking the added arguments. +1. Fine idea! The only caution is that a package may *need* those "future options" to install correctly -- but then that's up to the package's authoer to keep straight. > Any objections? Should it be backported to Python 2.2? I think so -- looks like the 2.2 line will be around for a long time. From mal@lemburg.com Thu Oct 31 03:36:01 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu Oct 31 03:36:01 2002 Subject: [Distutils] Proposed patch: allowing unknown keywords References: <20021030204046.A1748@nyman.amk.ca> Message-ID: <3DC0EB15.1010401@lemburg.com> A.M. Kuchling wrote: > I'd like to check in the following patch; it causes unknown keywords > in the setup() invocation to trigger a warning instead of an > exception. This will make it possible to add more metadata arguments > to setup() in future versions while still letting packages be > installed with Distutils versions lacking the added arguments. > > Any objections? Should it be backported to Python 2.2? No and yes :-) > --amk > > Index: dist.py > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Lib/distutils/dist.py,v > retrieving revision 1.56 > diff -u -u -r1.56 dist.py > --- dist.py 11 Sep 2002 16:31:52 -0000 1.56 > +++ dist.py 31 Oct 2002 00:24:55 -0000 > @@ -9,7 +9,7 @@ > > __revision__ = "$Id: dist.py,v 1.56 2002/09/11 16:31:52 jhylton Exp $" > > -import sys, os, string, re > +import sys, os, string, re, warnings > from types import * > from copy import copy > from distutils.errors import * > @@ -206,8 +206,7 @@ > elif hasattr(self, key): > setattr(self, key, val) > else: > - raise DistutilsSetupError, \ > - "invalid distribution option '%s'" % key > + warnings.warn("Unknown distribution option: %r" % key) > > self.finalize_options() > > > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > http://mail.python.org/mailman/listinfo/distutils-sig -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Juergen Hermann" Message-ID: On Wed, 30 Oct 2002 21:42:47 -0500, Tim Peters wrote: >+1. Fine idea! The only caution is that a package may *need* those "f= uture >options" to install correctly -- but then that's up to the package's au= thoer >to keep straight. To make that last task easier, can we also add a distutils.dist.Distribution.getSupportedOptions() -> list of strings method? That would make the check read like so: from distutils.dist import Distribution assert hasattr(Distribution, "getSupportedOptions") assert "foo" in Distribution.getSupportedOptions() Ciao, J=FCrgen -- J=FCrgen Hermann, Developer WEB.DE AG, http://webde-ag.de/ From rjones@ekit-inc.com Thu Oct 31 08:23:02 2002 From: rjones@ekit-inc.com (Richard Jones) Date: Thu Oct 31 08:23:02 2002 Subject: [Distutils] Proposed patch: allowing unknown keywords In-Reply-To: <20021030204046.A1748@nyman.amk.ca> References: <20021030204046.A1748@nyman.amk.ca> Message-ID: <200211010019.42433.rjones@ekit-inc.com> On Thu, 31 Oct 2002 12:40 pm, A.M. Kuchling wrote: > I'd like to check in the following patch; it causes unknown keywords > in the setup() invocation to trigger a warning instead of an > exception. This will make it possible to add more metadata arguments > to setup() in future versions while still letting packages be > installed with Distutils versions lacking the added arguments. > > Any objections? Should it be backported to Python 2.2? No objections, yes to 2.2 please :) Richard From amk@amk.ca Thu Oct 31 08:28:34 2002 From: amk@amk.ca (A.M. Kuchling) Date: Thu Oct 31 08:28:34 2002 Subject: [Distutils] Proposed patch: allowing unknown keywords In-Reply-To: ; from jh@web.de on Thu, Oct 31, 2002 at 10:24:41AM +0200 References: Message-ID: <20021031071810.A2827@nyman.amk.ca> On Thu, Oct 31, 2002 at 10:24:41AM +0200, Juergen Hermann wrote: > from distutils.dist import Distribution > assert hasattr(Distribution, "getSupportedOptions") > assert "foo" in Distribution.getSupportedOptions() Distutils uses underscores, so that would be get_supported_options(), but it seems like a reasonable idea. Should I write a micro-PEP about this, or is this addition too trivial? Incidentally, the change's use of warnings.warn() means that it will only work in Python 2.1 or later. For earlier versions, it could just print a message to stderr. There seems little reason to break 1.5.2/2.0 compatibility for this one little thing. --amk From amk@amk.ca Thu Oct 31 14:49:32 2002 From: amk@amk.ca (A.M. Kuchling) Date: Thu Oct 31 14:49:32 2002 Subject: [Distutils] Proposed patch: allowing unknown keywords In-Reply-To: ; from jh@web.de on Thu, Oct 31, 2002 at 10:24:41AM +0200 References: Message-ID: <20021031143845.A4943@nyman.amk.ca> On Thu, Oct 31, 2002 at 10:24:41AM +0200, Juergen Hermann wrote: > from distutils.dist import Distribution > assert hasattr(Distribution, "getSupportedOptions") > assert "foo" in Distribution.getSupportedOptions() Now that I look at, why would this be a method on Distribution? Are the options dependent on the Distribution instance, or on the version of Distutils installed? If the latter, then it should probably be a function in distutils/core.py. Given that many people write 'from distutils.core import *', maybe the function should be named get_distutil_options() to make its origin clearer. Here's a proposed docstring for core.py. There aren't any options to record yet, so the returned list is empty. Anyone see problems with this? def get_distutil_options (): """Returns a list of strings recording changes to the Distutils. setup.py files can then do: if 'optional-thing' in get_distutil_options(): ... """ return [] --amk