From symbiont at berlios.de Sun Oct 3 18:57:58 2004 From: symbiont at berlios.de (Jeff Pitman) Date: Sun Oct 3 18:58:09 2004 Subject: [Distutils] Add RPM-friendly Record Option In-Reply-To: <20040929172529.GA19153@tummy.com> References: <200409280044.34908.symbiont@berlios.de> <20040929172529.GA19153@tummy.com> Message-ID: <200410040057.58361.symbiont@berlios.de> On Thursday 30 September 2004 01:25, Sean Reifschneider wrote: > Any comments on this patch? ?symbiont has been doing a lot of work > with RPMs, and has run into some issues where he needs some more > features than the normal record file provides. ?Any objections to my > accepting this patch? I'm at v0.4 with the patch on sf.net because extra-path (Numeric) introduces some complexity, so I just hardcoded excluding 'site-packages' from the list. This won't be able to cover the case where the base lib directory changes to something say like 'homers-packages', but I think we're ok on that. But, I hit another snag whilst packaging IPython. They really pulled a doozy on me by introducing an additional "install_data_ext" which uses a different data format then the standard self.distribution.data_files. A local run of setup.py works because they've installed install_data_ext as the callback (or whatever we call it now-a-days) for install_data which handles the new data form. However, the write_record_rpm sneaks in to check what the directories are for this list. I'm wondering if there is any hope to cover for this situation. Any ideas? (Since IPython installs docs in a non-standard loc, I will bypass this, but I'm still wondering for the sake of long term usage.) take care, -- -jeff From bob at redivi.com Sun Oct 3 22:51:41 2004 From: bob at redivi.com (Bob Ippolito) Date: Sun Oct 3 22:52:18 2004 Subject: [Distutils] ANN: py2app 0.1 Message-ID: <074B39A6-157E-11D9-9C5D-000A95686CD8@redivi.com> py2app is the bundlebuilder replacement we've all been waiting for. It is implemented as a distutils command, similar to py2exe. Even at this early stage, it's probably the most advanced python packaging utility out there with regard to dependency analysis. It's at a "works for me and the two other people that have tried it" stage. It's not particularly documented, and I don't have time to document it today, but you should be able to get along given the examples. Since it is very similar to py2exe in design, you can also borrow ideas from there. If you have any issues with py2app, please let me know. Provide source if possible. I'm particularly interested in problematic packages which use import tricks or in-package data files such as PIL or pygame. These two are explicitly supported by the extensible "recipe" mechanism of py2app, but there are surely others. I believe PEAK, ZConfig, Twisted, etc. may do one or both of these things. Until a recipe is created for a particular problematic package, you may always just include it wholesale with the -p argument. Download and related links are here: http://undefined.org/python/#py2app -bob From pje at telecommunity.com Mon Oct 4 04:52:08 2004 From: pje at telecommunity.com (Phillip J. Eby) Date: Mon Oct 4 04:52:00 2004 Subject: [Distutils] ANN: py2app 0.1 In-Reply-To: <074B39A6-157E-11D9-9C5D-000A95686CD8@redivi.com> Message-ID: <5.1.1.6.0.20041003224544.02456eb0@mail.telecommunity.com> At 04:51 PM 10/3/04 -0400, Bob Ippolito wrote: >I believe PEAK, ZConfig, Twisted, etc. may do one or both of these things. PEAK definitely includes data files in package directories, and the latest version of the distutils supports doing such installs directly. (PEAK uses setuptools, though, since its minimum Python version is Python 2.2.2.) I don't have a Mac, though, so I'll have to rely on your feedback regarding PEAK's buildability with py2app. There are a number of potential issues: * Current versions of Python have a broken reload() function with respect to PEP 302; PEAK uses 'reload()' to drive a "lazy import" facility that also allows setting triggers to run when modules are imported. * PEAK uses in-package data files, and expects them to be accessible as regular files. This means that even if reload() worked correctly, it would break with e.g. putting the package in a zipfile. I do plan to make this PEP 302 compatible in the near future, by checking for a __loader__ attribute with a 'get_data()' method, and using that instead of direct filesystem access, if available. * PEAK uses dynamic and lazy imports extensively, which makes it impossible to find all its imports using only bytecode analysis. An ability to specify modules or packages as part of a setup.py is a must. From bob at redivi.com Mon Oct 4 05:16:58 2004 From: bob at redivi.com (Bob Ippolito) Date: Mon Oct 4 05:17:33 2004 Subject: [Distutils] ANN: py2app 0.1 In-Reply-To: <5.1.1.6.0.20041003224544.02456eb0@mail.telecommunity.com> References: <5.1.1.6.0.20041003224544.02456eb0@mail.telecommunity.com> Message-ID: On Oct 3, 2004, at 10:52 PM, Phillip J. Eby wrote: > At 04:51 PM 10/3/04 -0400, Bob Ippolito wrote: >> I believe PEAK, ZConfig, Twisted, etc. may do one or both of these >> things. > > PEAK definitely includes data files in package directories, and the > latest version of the distutils supports doing such installs directly. > (PEAK uses setuptools, though, since its minimum Python version is > Python 2.2.2.) py2app is using setuptools too, supporting a minimum Python version of 2.3.0. It was MUCH MUCH simpler than using distutils directly. Additionally I borrowed the sdist script from PyObjC that ignores subversion junk. > I don't have a Mac, though, so I'll have to rely on your feedback > regarding PEAK's buildability with py2app. There are a number of > potential issues: > > * Current versions of Python have a broken reload() function with > respect to PEP 302; PEAK uses 'reload()' to drive a "lazy import" > facility that also allows setting triggers to run when modules are > imported. > > * PEAK uses in-package data files, and expects them to be accessible > as regular files. This means that even if reload() worked correctly, > it would break with e.g. putting the package in a zipfile. I do plan > to make this PEP 302 compatible in the near future, by checking for a > __loader__ attribute with a 'get_data()' method, and using that > instead of direct filesystem access, if available. > > * PEAK uses dynamic and lazy imports extensively, which makes it > impossible to find all its imports using only bytecode analysis. An > ability to specify modules or packages as part of a setup.py is a > must. Yeah, I was pretty sure that this was the case. You simply just specify that you want to include PEAK as a package (which includes the whole package as-is, outside of the zip file). At some point I'll add a recipe that detects the presence of PEAK and makes this happen automatically, like I do for pygame, but I'm going to wait a bit until I hear about other packages so I can just do them all at once before the next release. -bob From pje at telecommunity.com Mon Oct 4 05:51:33 2004 From: pje at telecommunity.com (Phillip J. Eby) Date: Mon Oct 4 05:51:25 2004 Subject: [Distutils] ANN: py2app 0.1 In-Reply-To: References: <5.1.1.6.0.20041003224544.02456eb0@mail.telecommunity.com> <5.1.1.6.0.20041003224544.02456eb0@mail.telecommunity.com> Message-ID: <5.1.1.6.0.20041003234922.03412d90@mail.telecommunity.com> At 11:16 PM 10/3/04 -0400, Bob Ippolito wrote: >py2app is using setuptools too, supporting a minimum Python version of >2.3.0. It was MUCH MUCH simpler than using distutils directly. Nice to know. What parts of setuptools did you end up using? "Features", "dependencies", or just the data file stuff? From bob at redivi.com Mon Oct 4 06:36:34 2004 From: bob at redivi.com (Bob Ippolito) Date: Mon Oct 4 06:37:10 2004 Subject: [Distutils] ANN: py2app 0.1 In-Reply-To: <5.1.1.6.0.20041003234922.03412d90@mail.telecommunity.com> References: <5.1.1.6.0.20041003224544.02456eb0@mail.telecommunity.com> <5.1.1.6.0.20041003224544.02456eb0@mail.telecommunity.com> <5.1.1.6.0.20041003234922.03412d90@mail.telecommunity.com> Message-ID: On Oct 3, 2004, at 11:51 PM, Phillip J. Eby wrote: > At 11:16 PM 10/3/04 -0400, Bob Ippolito wrote: >> py2app is using setuptools too, supporting a minimum Python version >> of 2.3.0. It was MUCH MUCH simpler than using distutils directly. > > Nice to know. What parts of setuptools did you end up using? > "Features", "dependencies", or just the data file stuff? Well, it's open source, you can look for yourself :) http://svn.red-bean.com/bob/py2app/trunk/setup.py I'm using find_packages, the package_data stuff.. maybe other stuff implicitly? I didn't read the source or documentation for setuptools, I just cut+pasted from PEAK's setup.py. I went to PEAK first because I knew it dealt with installing multiple top level packages with data files and such, and I knew these things were terribly difficult with stock distutils. "Features" will probably be useful to me in the future, but it's not something I needed for this. -bob From fccoelho at fiocruz.br Mon Oct 4 15:05:29 2004 From: fccoelho at fiocruz.br (=?iso-8859-1?q?Fl=E1vio_Code=E7o_Coelho?=) Date: Mon Oct 4 15:05:47 2004 Subject: [Distutils] ANN: py2app 0.1 In-Reply-To: <074B39A6-157E-11D9-9C5D-000A95686CD8@redivi.com> References: <074B39A6-157E-11D9-9C5D-000A95686CD8@redivi.com> Message-ID: <200410041305.30026.fccoelho@fiocruz.br> Does it work on Linux? Flavio On Sunday 03 October 2004 20:51, Bob Ippolito wrote: > py2app is the bundlebuilder replacement we've all been waiting for. It > is implemented as a distutils command, similar to py2exe. > > Even at this early stage, it's probably the most advanced python > packaging utility out there with regard to dependency analysis. It's > at a "works for me and the two other people that have tried it" stage. > It's not particularly documented, and I don't have time to document it > today, but you should be able to get along given the examples. Since > it is very similar to py2exe in design, you can also borrow ideas from > there. > > If you have any issues with py2app, please let me know. Provide source > if possible. I'm particularly interested in problematic packages which > use import tricks or in-package data files such as PIL or pygame. > These two are explicitly supported by the extensible "recipe" mechanism > of py2app, but there are surely others. I believe PEAK, ZConfig, > Twisted, etc. may do one or both of these things. Until a recipe is > created for a particular problematic package, you may always just > include it wholesale with the -p argument. > > Download and related links are here: > http://undefined.org/python/#py2app > > -bob > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > http://mail.python.org/mailman/listinfo/distutils-sig From bob at redivi.com Mon Oct 4 18:56:43 2004 From: bob at redivi.com (Bob Ippolito) Date: Mon Oct 4 18:57:18 2004 Subject: [Distutils] ANN: py2app 0.1 In-Reply-To: <200410041305.30026.fccoelho@fiocruz.br> References: <074B39A6-157E-11D9-9C5D-000A95686CD8@redivi.com> <200410041305.30026.fccoelho@fiocruz.br> Message-ID: <5EA2A6AE-1626-11D9-9B53-000A95686CD8@redivi.com> On Oct 4, 2004, at 9:05 AM, Fl?vio Code?o Coelho wrote: > On Sunday 03 October 2004 20:51, Bob Ippolito wrote: >> py2app is the bundlebuilder replacement we've all been waiting for. >> It >> is implemented as a distutils command, similar to py2exe. >> >> Even at this early stage, it's probably the most advanced python >> packaging utility out there with regard to dependency analysis. It's >> at a "works for me and the two other people that have tried it" stage. >> It's not particularly documented, and I don't have time to document it >> today, but you should be able to get along given the examples. Since >> it is very similar to py2exe in design, you can also borrow ideas from >> there. >> >> If you have any issues with py2app, please let me know. Provide >> source >> if possible. I'm particularly interested in problematic packages >> which >> use import tricks or in-package data files such as PIL or pygame. >> These two are explicitly supported by the extensible "recipe" >> mechanism >> of py2app, but there are surely others. I believe PEAK, ZConfig, >> Twisted, etc. may do one or both of these things. Until a recipe is >> created for a particular problematic package, you may always just >> include it wholesale with the -p argument. >> >> Download and related links are here: >> http://undefined.org/python/#py2app > > Does it work on Linux? > No, it's for Mac OS X only. Surely actually visiting the link would've been an easier way to come to that conclusion? :) -bob From trasno-bounces at ceu.fi.udc.es Wed Oct 6 05:15:04 2004 From: trasno-bounces at ceu.fi.udc.es (trasno-bounces@ceu.fi.udc.es) Date: Wed Oct 6 05:15:14 2004 Subject: [Distutils] Your message to Trasno awaits moderator approval Message-ID: Your mail to 'Trasno' with the subject Re: Your website Is being held until the list moderator can review it for approval. The reason it is being held: SpamAssassin identified this message as possible spam Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: http://ceu.fi.udc.es/cgi-bin/mailman/confirm/trasno/2b67ce20a75e1b647eadf8f026ef60f0874ccfec From bob at redivi.com Wed Oct 6 07:36:53 2004 From: bob at redivi.com (Bob Ippolito) Date: Wed Oct 6 07:37:00 2004 Subject: [Distutils] ANN: py2app 0.1.1 Message-ID: `py2app`_ is the bundlebuilder replacement we've all been waiting for. It is implemented as a distutils command, similar to `py2exe`_, that builds Mac OS X applications from Python scripts, extensions, and related data files. It tries very hard to include all dependencies it can find so that your application can be distributed standalone, as Mac OS X applications should be. `py2app`_ 0.1.1 is primarily a bugfix release: * Several problems related to Mac OS X 10.2 compatibility and standalone building have been resolved * Scripts that are not in the same directory as setup.py now work * A new recipe has been added that removes the pydoc -> Tkinter dependency * A recipe has been added for py2app itself * a `wxPython`_ example (superdoodle) has been added. Demonstrates not only how easy it is (finally!) to bundle `wxPython`_ applications, but also how one setup.py can deal with both `py2exe`_ and `py2app`_. * A new experimental tool, py2applet, has been added. Once you've built it (``python setup.py py2app``, of course), you should be able to build simple applications simply by dragging your main script and optionally any packages, data files, Info.plist and icon it needs. Known issues: * Includes *all* files from packages, it should be smart enough to strip unused .py/.pyc/.pyo files (to save space, depending on which optimization flag is used). * The default PyRuntimeLocations can cause problems on machines that have a /Library/Frameworks/Python.framework installed. Workaround is to set a plist that has the following key: ``PyRuntimeLocations=['/System/Library/Frameworks/Python.framework/ Versions/2.3/Python']`` (this will be resolved soon) Download and related links are here: http://undefined.org/python/#py2app .. _`wxPython`: http://www.wxpython.org/ .. _`py2app`: http://undefined.org/python/#py2app .. _`py2exe`: http://starship.python.net/crew/theller/py2exe/ From bob at redivi.com Wed Oct 6 21:38:43 2004 From: bob at redivi.com (Bob Ippolito) Date: Wed Oct 6 21:39:24 2004 Subject: [Distutils] Re: [Pythonmac-SIG] Re: ANN: py2app 0.1.1 In-Reply-To: References: Message-ID: <552D13C8-17CF-11D9-A1CC-000A95686CD8@redivi.com> On Oct 6, 2004, at 3:34 PM, Russell E. Owen wrote: > In article , > Bob Ippolito wrote: > >> `py2app`_ is the bundlebuilder replacement we've all been waiting for. >> It is implemented as a distutils command, similar to `py2exe`_, that >> builds Mac OS X applications from Python scripts, extensions, and >> related data files. It tries very hard to include all dependencies it >> can find so that your application can be distributed standalone, as >> Mac >> OS X applications should be. > > I look at the 0.1 distro and examples and it really looks promising. > However, I did have two questions before I dive into trying to get my > app bundled: > - Do you have any hints or gotchas for distributing Tkinter apps and > have Tcl/Tk bundled inside. I want the target MacOS X 10.3 user to be > able to run my app without installing anything. It works exactly like that out of the box. > - As an extension to that question...any hints on installing tcl > extensions ("snack", specifically) into such a bundled app? No idea, give me instructions on how to do it and a minimal example that uses it and I'll see what can be done. -bob From rowen at cesmail.net Wed Oct 6 21:34:47 2004 From: rowen at cesmail.net (Russell E. Owen) Date: Wed Oct 6 21:51:03 2004 Subject: [Distutils] Re: ANN: py2app 0.1.1 References: Message-ID: In article , Bob Ippolito wrote: > `py2app`_ is the bundlebuilder replacement we've all been waiting for. > It is implemented as a distutils command, similar to `py2exe`_, that > builds Mac OS X applications from Python scripts, extensions, and > related data files. It tries very hard to include all dependencies it > can find so that your application can be distributed standalone, as Mac > OS X applications should be. I look at the 0.1 distro and examples and it really looks promising. However, I did have two questions before I dive into trying to get my app bundled: - Do you have any hints or gotchas for distributing Tkinter apps and have Tcl/Tk bundled inside. I want the target MacOS X 10.3 user to be able to run my app without installing anything. - As an extension to that question...any hints on installing tcl extensions ("snack", specifically) into such a bundled app? -- Russell From faheem at email.unc.edu Wed Oct 6 22:53:46 2004 From: faheem at email.unc.edu (Faheem Mitha) Date: Wed Oct 6 22:53:49 2004 Subject: [Distutils] addition to distutils documentation Message-ID: Hi, Can you add a mention of the new depends target for distutils to the documentation "Distributing Python Modules ". I think it of general interest. Thanks. See eg. http://docs.python.org/whatsnew/node18.html. Should I file a bug about this? Please reply to the above email address. Faheem. From andi at osafoundation.org Thu Oct 7 00:17:31 2004 From: andi at osafoundation.org (Andi Vajda) Date: Thu Oct 7 00:16:10 2004 Subject: [Distutils] patch for more SWIG support Message-ID: The distutils documentation about using it with SWIG says that support is rough around the edges. (see http://www.python.org/doc/current/dist/setup-script.html, section 3.3.2) The attached patch tries to unroughen things a little. I needed support for two things: . specifying more swig options than just '-c++' . specifying the path to the swig executable The attached patch to build_ext.py replaces the --swig-cpp option with: . --swig-opts= . --swig= I just subscribed to this list, pardon my ignorance about the process to follow to get this patch accepted and integrated into the sources, what do I need to do next ? Thanks ! Andi.. ps: the attached patch file is relative to the Pythonn 2.3.3 source distribution -------------- next part -------------- --- Python-2.3.3/Lib/distutils/command/build_ext.py Tue Nov 19 05:12:28 2002 +++ Python-2.3.3-patched/Lib/distutils/command/build_ext.py Tue Oct 5 14:24:48 2004 @@ -79,11 +79,13 @@ "forcibly build everything (ignore file timestamps)"), ('compiler=', 'c', "specify the compiler type"), - ('swig-cpp', None, - "make SWIG create C++ files (default is C)"), + ('swig-opts=', None, + "list of SWIG command line options"), + ('swig=', None, + "path to the SWIG executable"), ] - boolean_options = ['inplace', 'debug', 'force', 'swig-cpp'] + boolean_options = ['inplace', 'debug', 'force'] help_options = [ ('help-compiler', None, @@ -107,8 +109,8 @@ self.debug = None self.force = None self.compiler = None - self.swig_cpp = None - + self.swig_opts = None + self.swig = None def finalize_options (self): from distutils import sysconfig @@ -205,6 +207,11 @@ if self.undef: self.undef = string.split(self.undef, ',') + if self.swig_opts is None: + self.swig_opts = [] + else: + self.swig_opts = self.swig_opts.split(' ') + # finalize_options () @@ -509,7 +516,7 @@ # source -- but there should be an option to put SWIG output in # the temp dir. - if self.swig_cpp: + if '-c++' in self.swig_opts: target_ext = '.cpp' else: target_ext = '.c' @@ -526,10 +533,9 @@ if not swig_sources: return new_sources - swig = self.find_swig() - swig_cmd = [swig, "-python"] - if self.swig_cpp: - swig_cmd.append("-c++") + swig = self.swig or self.find_swig() + swig_cmd = [swig, '-python'] + swig_cmd.extend(self.swig_opts) for source in swig_sources: target = swig_targets[source] From cdieterich at geosci.uchicago.edu Thu Oct 7 00:44:23 2004 From: cdieterich at geosci.uchicago.edu (Christian Dieterich) Date: Thu Oct 7 00:44:32 2004 Subject: [Distutils] distutils with swig support Message-ID: <452D61D6-17E9-11D9-A5CD-000A9582377C@geosci.uchicago.edu> Hi, Some of my Python packages that build swigged code need to run swig with include directories and/or with macro definitions. The standard Python distutils does not provide this as an option, so I ended up with two sub-classes of the distutils package that I distribute along with the setup script. I consider it more a hack, but my colleagues keep telling me, I should let you know, so that it might be considered for a future distutils version or that it is at least available to the community. Below is an attachment including an alternative distribution class for distutils that applies the --include-dirs and --define options of the build_ext command not only to the compiler but also to swig. The include_dirs and define_macros keywords in the setup call are considered as well. Usually the Python support file from swig is left unused in the src directory. The alternative distribution class also puts the Python output of swig to the build/lib.machine/package directory, so that it gets installed. Here are a few lines of a setup.py script that uses the alternative distribution class. The two files dist_with_swig.py and build_ext_with_swig.py live in the same directory than setup.py. # import setup tools from distutils.core import setup, Extension # import distribution class with swig support from dist_with_swig import Distribution_with_swig # set up package setup(distclass=Distribution_with_swig, name="my_package", ...) Happy swigging, Christian P.S. I used distutils version 1.0.3 of Python 2.3.3 to sub-class. In the attachment are also the patches for dist.py and build_ext.py. -------------- next part -------------- A non-text attachment was scrubbed... Name: dist_with_swig.tar.gz Type: application/x-gzip Size: 21118 bytes Desc: not available Url : http://mail.python.org/pipermail/distutils-sig/attachments/20041006/a4418967/dist_with_swig.tar-0001.bin -------------- next part -------------- From admin at www.kfi.ro Thu Oct 7 08:35:13 2004 From: admin at www.kfi.ro (admin@www.kfi.ro) Date: Thu Oct 7 08:13:40 2004 Subject: [Distutils] VIRUS IN YOUR MAIL TO kfioffice Message-ID: <200410070635.i976ZDE12751@www.kfi.ro> V I R U S A L E R T Our viruschecker found a VIRUS in your email to "kfioffice". We stopped delivery of this email! Now it is on you to check your system for viruses Visit http://www.amavis.org for details on this viruschecker. For your reference, here are the headers from your email: ------------------------- BEGIN HEADERS ----------------------------- Return-Path: Received: from kfi.ro (client-2-68-109-203.iqara.net [203.109.68.2] (may be forged)) by www.kfi.ro (8.11.3/8.11.3) with ESMTP id i976Z7p12568 for ; Thu, 7 Oct 2004 09:35:07 +0300 Message-Id: <200410070635.i976Z7p12568@www.kfi.ro> From: distutils-sig@python.org To: kfi@kfi.ro Subject: Re: Thank you for delivery Date: Thu, 7 Oct 2004 11:43:51 +0530 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0016----=_NextPart_000_0016" X-Priority: 3 X-MSMail-Priority: Normal X-AntiVirus: scanned for viruses by AMaViS 0.2.1 (http://amavis.org/) -------------------------- END HEADERS ------------------------------ From calvin at users.sourceforge.net Thu Oct 7 14:15:55 2004 From: calvin at users.sourceforge.net (Bastian Kleineidam) Date: Thu Oct 7 14:16:02 2004 Subject: [Distutils] patch for more SWIG support In-Reply-To: References: Message-ID: <20041007121555.GA13084@treasure> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Andi, On Wed, Oct 06, 2004 at 03:17:31PM -0700, Andi Vajda wrote: > I just subscribed to this list, pardon my ignorance about the process > to follow to get this patch accepted and integrated into the sources, > what do I need to do next ? I think the best way is to submit a patch to SourceForge. Here is the SF page for patches, there is also a distutils category: http://sourceforge.net/tracker/?group_id=5470&atid=305470 > ps: the attached patch file is relative to the Pythonn 2.3.3 source It would be nice to have it against CVS, or at least against newest upstream version (2.3.4). There are some developer guidelines on the python homepage: http://www.python.org/dev/devfaq.html > --- Python-2.3.3/Lib/distutils/command/build_ext.py Tue Nov 19 05:12:28 2002 > +++ Python-2.3.3-patched/Lib/distutils/command/build_ext.py Tue Oct 5 14:24:48 2004 > @@ -79,11 +79,13 @@ > "forcibly build everything (ignore file timestamps)"), > ('compiler=', 'c', > "specify the compiler type"), > - ('swig-cpp', None, > - "make SWIG create C++ files (default is C)"), I think it is not necessary here to break backwards compatibility (ie. removing --swig-cpp). As you wrote above the --swig-cpp options is equivalent to - --swig-opts="-c++" ? This way you can keep the old option there, and perhaps print a deprecation message. Regards, Bastian - -- ,''`. Bastian Kleineidam . calvin (at) debian.org : :' : `. `' GnuPG Schl?ssel http://kampfwurst.net/gpgkey.txt `- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBZTN6eBwlBDLsbz4RAtqZAJ9oiSXB7PVPPd9cNlXdX7cLcN2ncgCeNvyj xdJfvgHYtR29CcjwpgTuzJM= =136L -----END PGP SIGNATURE----- From rowen at cesmail.net Thu Oct 7 21:38:11 2004 From: rowen at cesmail.net (Russell E. Owen) Date: Thu Oct 7 21:38:17 2004 Subject: [Distutils] Re: [Pythonmac-SIG] Re: ANN: py2app 0.1.1 References: <552D13C8-17CF-11D9-A1CC-000A95686CD8@redivi.com> Message-ID: In article <552D13C8-17CF-11D9-A1CC-000A95686CD8@redivi.com>, Bob Ippolito wrote: > On Oct 6, 2004, at 3:34 PM, Russell E. Owen wrote: > .. > > In article , > > Bob Ippolito wrote: > >... > > - As an extension to that question...any hints on installing tcl > > extensions ("snack", specifically) into such a bundled app? > > No idea, give me instructions on how to do it and a minimal example > that uses it and I'll see what can be done. Aqua Tcl extensions live in /Library/Tcl, typically each in its own subfolder. For example snack lives in /Library/Tcl/snack2.2/ When bundled, Tcl can find extensions in Contents/Frameworks/Tcl.framework/Resources/ e.g. for snack: Contents/Frameworks/Tcl.framework/Resources/snack2.2/ (That may not be the best location, but it works. I found it by trial and error.). I can put together a sample app and send it along separately if you like. -- Russell From bob at redivi.com Thu Oct 7 21:51:11 2004 From: bob at redivi.com (Bob Ippolito) Date: Thu Oct 7 21:51:47 2004 Subject: [Distutils] Re: [Pythonmac-SIG] Re: ANN: py2app 0.1.1 In-Reply-To: References: <552D13C8-17CF-11D9-A1CC-000A95686CD8@redivi.com> Message-ID: <3D3C89B4-189A-11D9-AB63-000A95686CD8@redivi.com> On Oct 7, 2004, at 3:38 PM, Russell E. Owen wrote: > In article <552D13C8-17CF-11D9-A1CC-000A95686CD8@redivi.com>, > Bob Ippolito wrote: > >> On Oct 6, 2004, at 3:34 PM, Russell E. Owen wrote: >> .. >>> In article , >>> Bob Ippolito wrote: >>> ... >>> - As an extension to that question...any hints on installing tcl >>> extensions ("snack", specifically) into such a bundled app? >> >> No idea, give me instructions on how to do it and a minimal example >> that uses it and I'll see what can be done. > > Aqua Tcl extensions live in /Library/Tcl, typically each in its own > subfolder. For example snack lives in /Library/Tcl/snack2.2/ > > When bundled, Tcl can find extensions in > Contents/Frameworks/Tcl.framework/Resources/ > e.g. for snack: > Contents/Frameworks/Tcl.framework/Resources/snack2.2/ > > (That may not be the best location, but it works. I found it by trial > and error.). > > I can put together a sample app and send it along separately if you > like. I'm more interested in having a development environment that mirrors yours to see if it's possible or reasonable to find usage of snack automatically. Depending on how Tcl extensions are linked, it might be necessary to rewrite their mach headers (or else you can, in theory, get the same "version mismatch" problem that Python has). If Tcl can find extensions in Contents/Frameworks/Tcl.framework/Resources when *not* bundled, that might be a good place to put them.. because py2app makes little attempt to strip down frameworks other than Python.framework. For versioned frameworks, it will skip the versions you are not linking to, but everything in that version (and anything outside of versioned directories) will be copied. -bob From bob at redivi.com Sat Oct 9 00:04:12 2004 From: bob at redivi.com (Bob Ippolito) Date: Sat Oct 9 00:04:47 2004 Subject: [Distutils] ANN: py2app 0.1.2 Message-ID: `py2app`_ is the bundlebuilder replacement we've all been waiting for. It is implemented as a distutils command, similar to `py2exe`_, that builds Mac OS X applications from Python scripts, extensions, and related data files. It tries very hard to include all dependencies it can find so that your application can be distributed standalone, as Mac OS X applications should be. `py2app`_ 0.1.2 is primarily a bugfix release: * The encodings package now gets included in the zip file (saves space) * A copy of the Python interpreter is not included anymore in standalone builds (saves space) * The executable bootstrap is now stripped by default (saves a little space) * sys.argv is set correctly now, it used to point to the executable, now it points to the boot script. This should enhance compatibility with some applications. * Adds an "Alias" feature to modulegraph, so that sys.modules craziness such as wxPython.wx -> wx can be accomodated (this particular craziness is also now handled by default) * A sys.path alternative may be passed to find_modules now, though this is not used yet * The Command instance is now passed to recipes instead of the Distribution instance (though no recipes currently use either) * The post-filtering of modules and extensions is now generalized into a stack and can be modified by recipes * A `wxPython`_ example demonstrating how to package `wxGlade`_ has been added * PyRuntimeLocations is now set to (only) the location of the current interpreter's Python.framework for alias and semi-standalone build modes (enhances compatibility with extensions built with an unpatched Makefile with Mac OS X 10.3's Python 2.3.0) Known issues: * Includes *all* files from packages, it should be smart enough to strip unused .py/.pyc/.pyo files (to save space, depending on which optimization flag is used). Download and related links are here: http://undefined.org/python/#py2app .. _`wxGlade`: http://wxglade.sourceforge.net/ .. _`wxPython`: http://www.wxpython.org/ .. _`py2app`: http://undefined.org/python/#py2app .. _`py2exe`: http://starship.python.net/crew/theller/py2exe/ From bob at redivi.com Sun Oct 10 21:18:16 2004 From: bob at redivi.com (Bob Ippolito) Date: Sun Oct 10 21:18:54 2004 Subject: [Distutils] ANN: py2app 0.1.3 Message-ID: <23860F46-1AF1-11D9-BA09-000A95686CD8@redivi.com> `py2app`_ is the bundlebuilder replacement we've all been waiting for. It is implemented as a distutils command, similar to `py2exe`_, that builds Mac OS X applications from Python scripts, extensions, and related data files. It tries very hard to include all dependencies it can find so that your application can be distributed standalone, as Mac OS X applications should be. `py2app`_ 0.1.3 is a refactoring and new features release: * ``altgraph``, my fork of Istvan Albert's `graphlib`_, is now part of the distribution * ``py2app.modulegraph`` has been refactored to use ``altgraph`` * `py2app`_ can now create `GraphViz`_ DOT graphs with the ``-g`` option (`TinyTinyEdit example`_) * Moved the filter stack into ``py2app.modulegraph`` * Fixed a bug that may have been in 0.1.2 where explicitly included packages would not be scanned by ``macholib`` * ``py2app.apptemplate`` now contains a stripped down ``site`` module as opposed to a ``sitecustomize`` * Alias builds are now the only ones that contain the system and user ``site-packages`` directory in ``sys.path`` * The ``pydoc`` recipe has been beefed up to also exclude ``BaseHTTPServer``, etc. Known issues: * Commands marked with XXX in the help are not implemented * Includes *all* files from packages, it should be smart enough to strip unused .py/.pyc/.pyo files (to save space, depending on which optimization flag is used) * ``macholib`` should be refactored to use ``altgraph`` * ``py2app.build_app`` and ``py2app.modulegraph`` should be refactored to search for dependencies on a per-application basis Download and related links are here: http://undefined.org/python/#py2app .. _`graphlib`: http://www.personal.psu.edu/staff/i/u/iua1/python/graphlib/html/ .. _`GraphViz`: http://www.research.att.com/sw/tools/graphviz/ .. _`TinyTinyEdit example`: http://undefined.org/~bob/TinyTinyEdit.pdf .. _`py2app`: http://undefined.org/python/#py2app .. _`py2exe`: http://starship.python.net/crew/theller/py2exe/ From Scott.Daniels at Acm.Org Tue Oct 12 05:17:36 2004 From: Scott.Daniels at Acm.Org (Scott David Daniels) Date: Tue Oct 12 05:16:25 2004 Subject: [Distutils] A bit o' help on creating a distribution with MingW32 Message-ID: I am having a bit of trouble creating a windows distributable with a C module using MingW32. While I can do: python setup.py build_ext --compile=mingw32 or: python setup.py build --compile=mingw32 I don't know how to do: python setup.py bdist_wininst --compile=mingw32 If I do: python setup.py build --compile=mingw32 python setup.py bdist_wininst --skip-build I get an executable with no tag for the particular python version. The built executable doesn't record the python version at all, so even if I rename whatever-0.4.win32.exe to whatever-0.4.win32-py2.4.exe, it gives me the choice of installing in both python 2.4 and python 2.3 directories. Actually I need to patch config.h before this works, but if I can get the process down, I am sure I can convince somebody to accept my patch to config.in (or whatever). Is there some trick I am missing? -- -- Scott David Daniels Scott.Daniels@Acm.Org From theller at python.net Tue Oct 12 08:40:21 2004 From: theller at python.net (Thomas Heller) Date: Tue Oct 12 08:40:03 2004 Subject: [Distutils] A bit o' help on creating a distribution with MingW32 In-Reply-To: (Scott David Daniels's message of "Mon, 11 Oct 2004 20:17:36 -0700") References: Message-ID: Scott David Daniels writes: > I am having a bit of trouble creating a windows distributable > with a C module using MingW32. While I can do: > python setup.py build_ext --compile=mingw32 > or: > python setup.py build --compile=mingw32 > > I don't know how to do: > python setup.py bdist_wininst --compile=mingw32 You could use command chaining, if that's the correct word for that: python setup.py build --compiler=mingw32 bdist_wininst or create a setup.cfg file which contains 'compiler=mingw32'. > If I do: > python setup.py build --compile=mingw32 > python setup.py bdist_wininst --skip-build > > I get an executable with no tag for the particular python version. If that's really true (seems I cannot repro it at the moment, but that may be because I don't use mingw32), you can use the --target-version option: python setup.py bdist_wininst --skip-build --target-version=2.3 Thomas From Scott.Daniels at Acm.Org Tue Oct 12 20:31:20 2004 From: Scott.Daniels at Acm.Org (Scott David Daniels) Date: Tue Oct 12 20:30:11 2004 Subject: [Distutils] Re: A bit o' help on creating a distribution with MingW32 In-Reply-To: References: Message-ID: Thomas Heller wrote: > Scott David Daniels writes: >>I am having a bit of trouble creating a windows distributable >>with a C module using MingW32. While I can do: >> python setup.py build --compile=mingw32 >> python setup.py bdist_wininst --skip-build >>I get an executable with no tag for the particular python version. > > You could use command chaining, if that's the correct word for that: > python setup.py build --compiler=mingw32 bdist_wininst This does the trick, both for using the mingw32 compiler, and for tagging the result with the python version. Thanks for the help. -- Scott David Daniels Scott.Daniels@Acm.Org From pje at telecommunity.com Tue Oct 12 22:31:29 2004 From: pje at telecommunity.com (Phillip J. Eby) Date: Tue Oct 12 22:32:04 2004 Subject: [Distutils] Re: A bit o' help on creating a distribution with MingW32 In-Reply-To: References: Message-ID: <5.1.1.6.0.20041012162821.0239d4a0@mail.telecommunity.com> At 11:31 AM 10/12/04 -0700, Scott David Daniels wrote: >Thomas Heller wrote: >>Scott David Daniels writes: >>>I am having a bit of trouble creating a windows distributable >>>with a C module using MingW32. While I can do: > >> python setup.py build --compile=mingw32 > >> python setup.py bdist_wininst --skip-build > >>I get an executable with no tag for the particular python version. >>You could use command chaining, if that's the correct word for that: >>python setup.py build --compiler=mingw32 bdist_wininst > >This does the trick, both for using the mingw32 compiler, and for >tagging the result with the python version. Thanks for the help. Note that if you intend to build most of your extensions with mingw32, just add this: [build] compiler = mingw32 to C:\PythonNN\Lib\distutils\distutils.cfg. Then, you needn't specify the compiler argument all the time; it's sufficient to run setup.py bdist_wininst. Alternatively, you can add it to 'setup.cfg' in the same directory as your 'setup.py', but then you have to do it for each project. From lars at ibp.de Wed Oct 13 14:30:18 2004 From: lars at ibp.de (Lars Immisch) Date: Wed Oct 13 14:30:20 2004 Subject: [Distutils] patch for more SWIG support In-Reply-To: <20041007121555.GA13084@treasure> References: <20041007121555.GA13084@treasure> Message-ID: <416D1FDA.1000607@ibp.de> Hi, I had a look at both proposed SWIG patches and I very much want one of them to be accepted (for the record, I wrote a very similar one a while back). Three very similar patches for SWIG support in distutils do make the point that distutils SWIG support is suboptimal. Regarding Andi's and Christian's patches: First of all, I agree with Bastian that a patch against current CVS would be nice. Second, we should decide which patch to select. After a brief comparison, I prefer Andi's patch, because it is smaller. Third, I agree with Bastian that leaving the option swig-cpp in place, but adding a DepreciationWarning might provide a gently nagging upgrade path and be consistent with Python's way of evolving. Unless some major disagreement breaks out: Andi, do you want to rework your patch and submit it to the sourceforge bug tracker? I can try to find some time to do it myself if you cannot. - Lars From andi at osafoundation.org Wed Oct 13 18:13:57 2004 From: andi at osafoundation.org (Andi Vajda) Date: Wed Oct 13 18:12:38 2004 Subject: [Distutils] patch for more SWIG support In-Reply-To: <416D1FDA.1000607@ibp.de> References: <20041007121555.GA13084@treasure> <416D1FDA.1000607@ibp.de> Message-ID: Yes, I agree with the changes suggested for my patch. I'd love to submit it to sourceforge but my new account registration seems stuck somewhere. It told me to wait up to 24 hrs. Well, I submitted it last Thursday and haven't heard back yet (yes, I did provide a valid email address). Andi.. On Wed, 13 Oct 2004, Lars Immisch wrote: > Hi, > > I had a look at both proposed SWIG patches and I very much want one of them > to be accepted (for the record, I wrote a very similar one a while back). > > Three very similar patches for SWIG support in distutils do make the point > that distutils SWIG support is suboptimal. > > Regarding Andi's and Christian's patches: > > First of all, I agree with Bastian that a patch against current CVS would be > nice. > > Second, we should decide which patch to select. After a brief comparison, I > prefer Andi's patch, because it is smaller. > > Third, I agree with Bastian that leaving the option swig-cpp in place, but > adding a DepreciationWarning might provide a gently nagging upgrade path and > be consistent with Python's way of evolving. > > Unless some major disagreement breaks out: > > Andi, do you want to rework your patch and submit it to the sourceforge bug > tracker? > > I can try to find some time to do it myself if you cannot. > > - Lars > From anthony at interlink.com.au Wed Oct 13 18:28:12 2004 From: anthony at interlink.com.au (Anthony Baxter) Date: Wed Oct 13 18:28:33 2004 Subject: [Distutils] patch for more SWIG support In-Reply-To: References: <20041007121555.GA13084@treasure> <416D1FDA.1000607@ibp.de> Message-ID: <416D579C.5050008@interlink.com.au> Andi Vajda wrote: > > Yes, I agree with the changes suggested for my patch. I'd love to submit > it to sourceforge but my new account registration seems stuck somewhere. > It told me to wait up to 24 hrs. Well, I submitted it last Thursday and > haven't heard back yet (yes, I did provide a valid email address). I have a patch here that works, but I have no SWIG-using projects to test it with (all my stuff got switched to Pyrex a while ago). Anyone point me at a simple distutils-and-swig-using package? -- Anthony Baxter It's never too late to have a happy childhood. From anthony at interlink.com.au Wed Oct 13 19:15:15 2004 From: anthony at interlink.com.au (Anthony Baxter) Date: Wed Oct 13 19:15:26 2004 Subject: [Distutils] patch for more SWIG support In-Reply-To: <416D579C.5050008@interlink.com.au> References: <20041007121555.GA13084@treasure> <416D1FDA.1000607@ibp.de> <416D579C.5050008@interlink.com.au> Message-ID: <416D62A3.2040204@interlink.com.au> Patch is at: http://sourceforge.net/tracker/index.php?func=detail&aid=1046404&group_id=5470&atid=105470 If someone wants to eyeball it, that'd be good. -- Anthony Baxter It's never too late to have a happy childhood. From lars at ibp.de Wed Oct 13 20:35:49 2004 From: lars at ibp.de (Lars Immisch) Date: Wed Oct 13 20:35:27 2004 Subject: [Distutils] patch for more SWIG support In-Reply-To: <416D579C.5050008@interlink.com.au> References: <20041007121555.GA13084@treasure> <416D1FDA.1000607@ibp.de> <416D579C.5050008@interlink.com.au> Message-ID: <416D7585.9060604@ibp.de> Hi Anthony, >> Yes, I agree with the changes suggested for my patch. I'd love to >> submit it to sourceforge but my new account registration seems stuck >> somewhere. It told me to wait up to 24 hrs. Well, I submitted it last >> Thursday and haven't heard back yet (yes, I did provide a valid email >> address). > > > I have a patch here that works, but I have no SWIG-using projects to > test it with (all my stuff got switched to Pyrex a while ago). Anyone > point me at a simple distutils-and-swig-using package? Brilliant. And while I don't know any public SWIG-using projects, I would be happy to test it with my private ones. - Lars From jmiller at stsci.edu Wed Oct 13 20:37:55 2004 From: jmiller at stsci.edu (Todd Miller) Date: Wed Oct 13 20:38:02 2004 Subject: [Distutils] Windows .lib files for Python extensions Message-ID: <1097692675.631.676.camel@halloween.stsci.edu> I have a numarray user who is trying to link his application (on windows) to one of the numarray DLL's and he says he needs a .lib file to do it. I accidentally found a bizarre approach to building a .lib with the right name: build with Python-2.4 and VC.NET followed by build with Python-2.3 and VC6.0. This produces 2.4 and 2.3 versions of libnumarray.lib. I didn't add anything to my setup to generate anything other than Python extensions. My dim recollection of "windows stuff" is that libnumarray.lib would probably contain "DLL stubs" to permit quasi-static linking to libnumarray.pyd. Is this the case or is it just a static library? Is something new going on in the distutils for Python-2.4 which leaves behind an artifact which would affect a Python-2.3 build? Is there a standard approach to producing .lib files for Python-2.3? Regards, Todd From lars at ibp.de Wed Oct 13 22:18:07 2004 From: lars at ibp.de (Lars Immisch) Date: Wed Oct 13 22:17:46 2004 Subject: [Distutils] patch for more SWIG support In-Reply-To: <416D62A3.2040204@interlink.com.au> References: <20041007121555.GA13084@treasure> <416D1FDA.1000607@ibp.de> <416D579C.5050008@interlink.com.au> <416D62A3.2040204@interlink.com.au> Message-ID: <416D8D7F.2050306@ibp.de> Hi Anthony, > http://sourceforge.net/tracker/index.php?func=detail&aid=1046404&group_id=5470&atid=105470 I've found a nuisance. The following works: python setup.py build_ext --swig-opts=-I../include What does not work is something like: from distutils.core import setup,Extension setup (name = "aculab", ext_modules = [Extension("aculab._lowlevel", ['acu.i'], swig_opts=['-I../include', '-modern']], packages = ["aculab"]) To do this, one needs to modify extension.py and core.py. In a nutshell, core.py needs 'swig_opts' in extension_keywords and extension.py needs it in the argument list of Extension.__init__. Also, build_ext.swig_sources needs an extra argument containing the extension. I have attached a patch that supersedes (i.e. includes) your patch. It's against 2.3.4. Your patch didn't work against 2.4a2 and I didn't have time yet to get CVS HEAD. I will send the same against CVS HEAD in an hour or so. Lars -------------- next part -------------- --- Lib/distutils/core.orig 2003-02-19 15:16:00.000000000 +0100 +++ Lib/distutils/core.py 2004-10-13 22:02:56.460291200 +0200 @@ -54,7 +54,7 @@ 'define_macros', 'undef_macros', 'library_dirs', 'libraries', 'runtime_library_dirs', 'extra_objects', 'extra_compile_args', 'extra_link_args', - 'export_symbols', 'depends', 'language') + 'export_symbols', 'swig_opts', 'depends', 'language') def setup (**attrs): """The gateway to the Distutils: do everything your setup script needs --- Lib/distutils/extension.orig 2003-01-27 17:30:36.000000000 +0100 +++ Lib/distutils/extension.py 2004-10-13 22:03:13.665030400 +0200 @@ -70,6 +70,9 @@ when linking object files together to create the extension (or to create a new static Python interpreter). Similar interpretation as for 'extra_compile_args'. + swig_opts : [string] + any extra options to pass to SWIG if a source file has the .i + extension. export_symbols : [string] list of symbols to be exported from a shared extension. Not used on all platforms, and not generally necessary for Python @@ -94,6 +97,7 @@ extra_objects=None, extra_compile_args=None, extra_link_args=None, + swig_opts=None, export_symbols=None, depends=None, language=None, @@ -115,6 +119,7 @@ self.extra_objects = extra_objects or [] self.extra_compile_args = extra_compile_args or [] self.extra_link_args = extra_link_args or [] + self.swig_opts = swig_opts or [] self.export_symbols = export_symbols or [] self.depends = depends or [] self.language = language --- Lib/distutils/command/build_ext.orig 2002-11-19 14:12:28.000000000 +0100 +++ Lib/distutils/command/build_ext.py 2004-10-13 22:06:30.327817600 +0200 @@ -81,6 +81,11 @@ "specify the compiler type"), ('swig-cpp', None, "make SWIG create C++ files (default is C)"), + ('swig-opts=', None, + "list of SWIG command line options"), + ('swig=', None, + "path to the SWIG executable"), + ] boolean_options = ['inplace', 'debug', 'force', 'swig-cpp'] @@ -108,6 +113,8 @@ self.force = None self.compiler = None self.swig_cpp = None + self.swig_opts = None + self.swig = None def finalize_options (self): @@ -205,6 +212,12 @@ if self.undef: self.undef = string.split(self.undef, ',') + if self.swig_opts is None: + self.swig_opts = [] + else: + self.swig_opts = self.swig_opts.split(' ') + + # finalize_options () @@ -429,7 +442,7 @@ # First, scan the sources for SWIG definition files (.i), run # SWIG on 'em to create .c files, and modify the sources list # accordingly. - sources = self.swig_sources(sources) + sources = self.swig_sources(sources, ext) # Next, compile the source code to object files. @@ -492,7 +505,7 @@ target_lang=language) - def swig_sources (self, sources): + def swig_sources (self, sources, extension): """Walk the list of source files in 'sources', looking for SWIG interface (.i) files. Run SWIG on all that are found, and @@ -509,7 +522,10 @@ # source -- but there should be an option to put SWIG output in # the temp dir. - if self.swig_cpp: + if self.swig_cpp: + log.warn("--swig-cpp is deprecated - use --swig-opts=-c++") + + if self.swig_cpp or ('-c++' in self.swig_opts): target_ext = '.cpp' else: target_ext = '.c' @@ -526,11 +542,15 @@ if not swig_sources: return new_sources - swig = self.find_swig() + swig = self.swig or self.find_swig() swig_cmd = [swig, "-python"] + swig_cmd.extend(self.swig_opts) if self.swig_cpp: swig_cmd.append("-c++") + for o in extension.swig_opts: + swig_cmd.append(o) + for source in swig_sources: target = swig_targets[source] log.info("swigging %s to %s", source, target) From lars at ibp.de Thu Oct 14 00:23:23 2004 From: lars at ibp.de (Lars Immisch) Date: Thu Oct 14 00:23:00 2004 Subject: [Distutils] patch for more SWIG support In-Reply-To: <416D62A3.2040204@interlink.com.au> References: <20041007121555.GA13084@treasure> <416D1FDA.1000607@ibp.de> <416D579C.5050008@interlink.com.au> <416D62A3.2040204@interlink.com.au> Message-ID: <416DAADB.9090001@ibp.de> Hi Anthony, > http://sourceforge.net/tracker/index.php?func=detail&aid=1046404&group_id=5470&atid=105470 As promised, I have attached a patch (and submitted to SourceForge) that deals both with: from distutils.core import setup,Extension setup (name = "aculab", ext_modules = [Extension("_aculab", ['acu.i'], swig_opts=['-modern', '-I../include']]) and the commandline argument: python setup.py build_ext --swig-opts="-modern -I../include" When both the keyword argument and the commandline option are given, the commandline option takes precedence. I hope this is consistent with existing distutils usage. In SourceForge, the patch is is at: http://sourceforge.net/tracker/index.php?func=detail&aid=1046644&group_id=5470&atid=105470 - Lars -------------- next part -------------- --- Lib/distutils/core.orig 2003-02-19 15:16:00.000000000 +0100 +++ Lib/distutils/core.py 2004-10-13 22:02:56.460291200 +0200 @@ -54,7 +54,7 @@ 'define_macros', 'undef_macros', 'library_dirs', 'libraries', 'runtime_library_dirs', 'extra_objects', 'extra_compile_args', 'extra_link_args', - 'export_symbols', 'depends', 'language') + 'export_symbols', 'swig_opts', 'depends', 'language') def setup (**attrs): """The gateway to the Distutils: do everything your setup script needs --- Lib/distutils/extension.orig 2003-01-27 17:30:36.000000000 +0100 +++ Lib/distutils/extension.py 2004-10-13 22:03:13.665030400 +0200 @@ -70,6 +70,9 @@ when linking object files together to create the extension (or to create a new static Python interpreter). Similar interpretation as for 'extra_compile_args'. + swig_opts : [string] + any extra options to pass to SWIG if a source file has the .i + extension. export_symbols : [string] list of symbols to be exported from a shared extension. Not used on all platforms, and not generally necessary for Python @@ -94,6 +97,7 @@ extra_objects=None, extra_compile_args=None, extra_link_args=None, + swig_opts=None, export_symbols=None, depends=None, language=None, @@ -115,6 +119,7 @@ self.extra_objects = extra_objects or [] self.extra_compile_args = extra_compile_args or [] self.extra_link_args = extra_link_args or [] + self.swig_opts = swig_opts or [] self.export_symbols = export_symbols or [] self.depends = depends or [] self.language = language --- Lib/distutils/command/build_ext.orig 2002-11-19 14:12:28.000000000 +0100 +++ Lib/distutils/command/build_ext.py 2004-10-13 22:06:30.327817600 +0200 @@ -81,6 +81,11 @@ "specify the compiler type"), ('swig-cpp', None, "make SWIG create C++ files (default is C)"), + ('swig-opts=', None, + "list of SWIG command line options"), + ('swig=', None, + "path to the SWIG executable"), + ] boolean_options = ['inplace', 'debug', 'force', 'swig-cpp'] @@ -108,6 +113,8 @@ self.force = None self.compiler = None self.swig_cpp = None + self.swig_opts = None + self.swig = None def finalize_options (self): @@ -205,6 +212,12 @@ if self.undef: self.undef = string.split(self.undef, ',') + if self.swig_opts is None: + self.swig_opts = [] + else: + self.swig_opts = self.swig_opts.split(' ') + + # finalize_options () @@ -429,7 +442,7 @@ # First, scan the sources for SWIG definition files (.i), run # SWIG on 'em to create .c files, and modify the sources list # accordingly. - sources = self.swig_sources(sources) + sources = self.swig_sources(sources, ext) # Next, compile the source code to object files. @@ -492,7 +505,7 @@ target_lang=language) - def swig_sources (self, sources): + def swig_sources (self, sources, extension): """Walk the list of source files in 'sources', looking for SWIG interface (.i) files. Run SWIG on all that are found, and @@ -509,7 +522,10 @@ # source -- but there should be an option to put SWIG output in # the temp dir. - if self.swig_cpp: + if self.swig_cpp: + log.warn("--swig-cpp is deprecated - use --swig-opts=-c++") + + if self.swig_cpp or ('-c++' in self.swig_opts): target_ext = '.cpp' else: target_ext = '.c' @@ -526,11 +542,15 @@ if not swig_sources: return new_sources - swig = self.find_swig() + swig = self.swig or self.find_swig() swig_cmd = [swig, "-python"] + swig_cmd.extend(self.swig_opts) if self.swig_cpp: swig_cmd.append("-c++") + for o in extension.swig_opts: + swig_cmd.append(o) + for source in swig_sources: target = swig_targets[source] log.info("swigging %s to %s", source, target) From mal at egenix.com Thu Oct 14 01:03:51 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Oct 14 01:03:54 2004 Subject: [Distutils] patch for more SWIG support In-Reply-To: <416DAADB.9090001@ibp.de> References: <20041007121555.GA13084@treasure> <416D1FDA.1000607@ibp.de> <416D579C.5050008@interlink.com.au> <416D62A3.2040204@interlink.com.au> <416DAADB.9090001@ibp.de> Message-ID: <416DB457.6000103@egenix.com> Lars Immisch wrote: > Hi Anthony, > >> http://sourceforge.net/tracker/index.php?func=detail&aid=1046404&group_id=5470&atid=105470 > > > > As promised, I have attached a patch (and submitted to SourceForge) that > deals both with: > > from distutils.core import setup,Extension > > setup (name = "aculab", > ext_modules = [Extension("_aculab", ['acu.i'], > swig_opts=['-modern', '-I../include']]) > > > and the commandline argument: > > python setup.py build_ext --swig-opts="-modern -I../include" > > When both the keyword argument and the commandline option are given, the > commandline option takes precedence. > > I hope this is consistent with existing distutils usage. Looks good. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From anthony at interlink.com.au Thu Oct 14 12:02:45 2004 From: anthony at interlink.com.au (Anthony Baxter) Date: Thu Oct 14 12:03:01 2004 Subject: [Distutils] patch for more SWIG support In-Reply-To: <416DAADB.9090001@ibp.de> References: <20041007121555.GA13084@treasure> <416D1FDA.1000607@ibp.de> <416D579C.5050008@interlink.com.au> <416D62A3.2040204@interlink.com.au> <416DAADB.9090001@ibp.de> Message-ID: <416E4EC5.6090006@interlink.com.au> Lars Immisch wrote: > In SourceForge, the patch is is at: > > http://sourceforge.net/tracker/index.php?func=detail&aid=1046644&group_id=5470&atid=105470 This has been applied, and will be in 2.4b1 Thanks! Anthony -- Anthony Baxter It's never too late to have a happy childhood. From lars at ibp.de Thu Oct 14 12:50:11 2004 From: lars at ibp.de (Lars Immisch) Date: Thu Oct 14 12:46:51 2004 Subject: [Distutils] patch for more SWIG support In-Reply-To: <416E4EC5.6090006@interlink.com.au> References: <20041007121555.GA13084@treasure> <416D1FDA.1000607@ibp.de> <416D579C.5050008@interlink.com.au> <416D62A3.2040204@interlink.com.au> <416DAADB.9090001@ibp.de> <416E4EC5.6090006@interlink.com.au> Message-ID: <416E59E3.8060907@ibp.de> Dear Anthony, >> http://sourceforge.net/tracker/index.php?func=detail&aid=1046644&group_id=5470&atid=105470 > > This has been applied, and will be in 2.4b1 Nice! Thanks. I have also submitted a patch for the documentation. It is at http://sourceforge.net/tracker/index.php?func=detail&aid=1046945&group_id=5470&atid=105470 I like it, but it *documents* distutils SWIG support and thus raises expectations about the interface being stable. Apply as you see fit ;-) - Lars From symbiont at berlios.de Thu Oct 14 18:30:57 2004 From: symbiont at berlios.de (Jeff Pitman) Date: Thu Oct 14 18:31:15 2004 Subject: [Distutils] Add RPM-friendly Record Option In-Reply-To: <20040929172529.GA19153@tummy.com> References: <200409280044.34908.symbiont@berlios.de> <20040929172529.GA19153@tummy.com> Message-ID: <200410150030.57631.symbiont@berlios.de> On Thursday 30 September 2004 01:25, Sean Reifschneider wrote: > Any objections to my accepting this > patch? Would my recent updates to sf.net be acceptable for 2.4? take care, -- -jeff From anthony at interlink.com.au Wed Oct 13 15:38:58 2004 From: anthony at interlink.com.au (Anthony Baxter) Date: Fri Oct 15 03:51:44 2004 Subject: [Distutils] patch for more SWIG support In-Reply-To: <416D1FDA.1000607@ibp.de> References: <20041007121555.GA13084@treasure> <416D1FDA.1000607@ibp.de> Message-ID: <416D2FF2.40002@interlink.com.au> I'm going to try and do the work myself, very shortly. We're about a day away from b1, so unless someone else speaks up pretty much straight away, this needs to be done, and needs to be done, well, now. Anthony -- Anthony Baxter It's never too late to have a happy childhood. From dank at kegel.com Sat Oct 16 21:59:25 2004 From: dank at kegel.com (Dan Kegel) Date: Sat Oct 16 22:56:00 2004 Subject: [Distutils] re: Cross-compilation support in distutils? Message-ID: <41717D9D.1040703@kegel.com> On Jul 27 2004, Tim Gilbert wrote (http://mail.python.org/pipermail/distutils-sig/2004-July/004105.html) > As anybody who might have tried to cross-compile python before has > probably noticed, this isn't easy. ... > After much furrowing of my brow and hacking of the makefile I've managed > to get the compilation to go through the whole way ... > Once I'm a little farther along I'll put up a web page with some patches > and things that will hopefully make this all a little clearer, but for > now I'd like to get a little input. > > 1. Is there interest in adding cross-compilation support to distutils? Oh, yes. Cross-compiling Python and its extensions (at least as of 2.2.5, the version I tried) is extremely painful, and we need to fix that. > (Beyond that of yours truly.) If so, I'd like to get a discussion going > on some options for how to do this - especially, I'd like to have a way > to specify via configure arguments or a python script which libraries to > include. Yes, yes, yes. > ... > Cross-compiling python for ARM howto: > http://www.ailis.de/~k/docs/crosscompiling/python.php I found this quite helpful. However, I'm still facing the problem of keeping setup.py from searching /usr, /usr/local, etc. and finding locally-installed packages. I guess I should write a little patch to disable the implicit automatic search of those directories. - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html From wurst2 at kampfwurst.net Sat Oct 16 23:36:36 2004 From: wurst2 at kampfwurst.net (Bastian Kleineidam) Date: Sat Oct 16 23:36:45 2004 Subject: [Distutils] re: Cross-compilation support in distutils? In-Reply-To: <41717D9D.1040703@kegel.com> References: <41717D9D.1040703@kegel.com> Message-ID: <20041016213636.GA577@treasure> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sat, Oct 16, 2004 at 12:59:25PM -0700, Dan Kegel wrote: > >(Beyond that of yours truly.) If so, I'd like to get a discussion going > >on some options for how to do this - especially, I'd like to have a way > >to specify via configure arguments or a python script which libraries to > >include. > > Yes, yes, yes. I wrote a little howto with details about linux -> win32 cross compilation with the mingw32 compiler. It is here: http://kampfwurst.net/python-mingw32/ For setup.py I used the CC and LDSHARED environment variables to specify the mingw compiler and linker. Includes and LDFLAGS are handled by setup.py itself. Greetings, Bastian - -- ,''`. Bastian Kleineidam . calvin (at) debian.org : :' : `. `' GnuPG Schl?ssel http://kampfwurst.net/gpgkey.txt `- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBcZRkeBwlBDLsbz4RAh1MAKDNf8W9Z5HPOkHuq1gA5ULyl6FHkQCg0aWX f5qZATJY/yyRSWHW+Hte5dM= =XTgk -----END PGP SIGNATURE----- From dank at kegel.com Sun Oct 17 06:32:25 2004 From: dank at kegel.com (Dan Kegel) Date: Sun Oct 17 07:29:01 2004 Subject: [Distutils] re: Cross-compilation support in distutils? In-Reply-To: <41717D9D.1040703@kegel.com> References: <41717D9D.1040703@kegel.com> Message-ID: <4171F5D9.7030806@kegel.com> Dan Kegel wrote: > On Jul 27 2004, Tim Gilbert wrote > (http://mail.python.org/pipermail/distutils-sig/2004-July/004105.html) > >> As anybody who might have tried to cross-compile python before has >> probably noticed, this isn't easy. ... >> >> 1. Is there interest in adding cross-compilation support to distutils? > > > Oh, yes. Cross-compiling Python and its extensions (at least as of 2.2.5, > the version I tried) is extremely painful, and we need to fix that. Guido even likes the idea of adding support (see below). >> ... Cross-compiling python for ARM howto: >> http://www.ailis.de/~k/docs/crosscompiling/python.php > > > I found this quite helpful. However, I'm still facing the > problem of keeping setup.py from searching /usr, /usr/local, etc. > and finding locally-installed packages. I guess I should > write a little patch to disable the implicit automatic > search of those directories. Hah. Found a patch that does that. Here's a page that describes everything I dug up about this while searching tonight. I wish I'd dug up more of this stuff before I tried actually cross-building Python. http://kegel.com/crosstool/python.html - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html From misterbike at hotmail.com Sun Oct 17 07:48:23 2004 From: misterbike at hotmail.com (Craig) Date: Sun Oct 17 07:49:17 2004 Subject: [Distutils] distutils question Message-ID: <000601c4b40d$09566d10$7776fea9@TheDell> Hi - I'm trying to use distutils to set up a package that has lots of config files that are co-located with the package itself. The problem I'm having is how to install these files in the same place as my python package. The following ugly hack is what I came up with, but I can't believe there isn't a better way. If it matters, the platforms I'm using are windows and linux. Thanks, Craig MANIFEST.in: graft Rooms graft Devices setup.py: from distutils.core import setup import glob import os.path from distutils.dist import Distribution i = Distribution().get_command_obj('install') i.finalize_options() path = i.install_purelib setup(name="Photronica", author="Craig D", author_email="craig.durland@hp.com", package_dir = {"Photronica": ""}, packages=["Photronica","Photronica.DAS"], data_files = [ (os.path.join(path,"Photronica","Devices"), glob.glob("Devices/*")), (os.path.join(path,"Photronica","Rooms"), glob.glob("Rooms/*")), ] ) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/distutils-sig/attachments/20041016/7f64d461/attachment.htm From mal at egenix.com Sun Oct 17 12:48:06 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Oct 17 12:48:09 2004 Subject: [Distutils] re: Cross-compilation support in distutils? In-Reply-To: <41717D9D.1040703@kegel.com> References: <41717D9D.1040703@kegel.com> Message-ID: <41724DE6.9090405@egenix.com> Dan Kegel wrote: > On Jul 27 2004, Tim Gilbert wrote > (http://mail.python.org/pipermail/distutils-sig/2004-July/004105.html) > >> As anybody who might have tried to cross-compile python before has >> probably noticed, this isn't easy. ... After much furrowing of my >> brow and hacking of the makefile I've managed to get the compilation >> to go through the whole way ... >> Once I'm a little farther along I'll put up a web page with some >> patches and things that will hopefully make this all a little clearer, >> but for now I'd like to get a little input. >> >> 1. Is there interest in adding cross-compilation support to distutils? > > Oh, yes. Cross-compiling Python and its extensions (at least as of 2.2.5, > the version I tried) is extremely painful, and we need to fix that. > >> (Beyond that of yours truly.) If so, I'd like to get a discussion >> going on some options for how to do this - especially, I'd like to >> have a way to specify via configure arguments or a python script which >> libraries to include. > > > Yes, yes, yes. > >> ... Cross-compiling python for ARM howto: >> http://www.ailis.de/~k/docs/crosscompiling/python.php > > > I found this quite helpful. However, I'm still facing the > problem of keeping setup.py from searching /usr, /usr/local, etc. > and finding locally-installed packages. I guess I should > write a little patch to disable the implicit automatic > search of those directories. I think you need to be more explicit about what you are trying to achieve here: As far as I understand the setup.py you are talking about is the one that is used to compile the extensions that come with Python (those in Modules/) rather than extensions built using stock distutils. If that's the case, then you are talking about adding support to that particular setup.py and not distutils in general, so the discussion would need to take place on python-dev rather than here. What I'd be more interested in is figuring out which things would help distutils users *in general* in order to make cross-compilation feasable. In particular: * which features are missing ? * which extra commands would be needed ? * what else is missing in support of cross-compilation ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 17 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From pje at telecommunity.com Sun Oct 17 14:03:24 2004 From: pje at telecommunity.com (Phillip J. Eby) Date: Sun Oct 17 14:03:12 2004 Subject: [Distutils] distutils question In-Reply-To: <000601c4b40d$09566d10$7776fea9@TheDell> Message-ID: <5.1.1.6.0.20041017075546.022e06e0@mail.telecommunity.com> At 10:48 PM 10/16/04 -0700, Craig wrote: >Hi - I'm trying to use distutils to set up a package that has lots of >config files that are co-located with the package itself. The problem I'm >having is how to install these files in the same place as my python >package. The following ugly hack is what I came up with, but I can't >believe there isn't a better way. If it matters, the platforms I'm using >are windows and linux. There is a better way. For Python 2.4, there's a new 'package_data' option to the 'setup()' function. See: http://www.python.org/dev/doc/devel/dist/node11.html for details. If you can't wait for Python 2.4, you can use the 'setuptools' package, which is available in the Python CVS "sandbox" (python/nondist/sandbox). Instead of importing 'setup' from 'distutils.core', just import it from 'setuptools'. The 'setup.py' for 'setuptools' actually uses setuptools, so you can use it as an example. If the target system won't have setuptools installed ahead of time, you'll need to include setuptools itself in your source distribution, installed in the main directory of the distribution. Be sure to add a: recursive-include setuptools *.py to your MANIFEST.in, so that it will be included when you build a source distribution of your package. From misterbike at hotmail.com Mon Oct 18 02:06:48 2004 From: misterbike at hotmail.com (Craig) Date: Mon Oct 18 02:07:05 2004 Subject: [Distutils] Enhancement request Message-ID: Here is something I'd like to be able to do with distutils "install": python distinstall.py foo-3.2.zip and have the foo package installed, no unzipping needed. distinstall.py (or whatever it is called) would be in the python path and would be just a simple front end to setup.py. This would make my life easier. It would be really cool if it could do this in memory, without creating temp files (for when I'm sitting on a read only network drive installing packages). Also, I'd like to be able to package distutil packages and have them installed. eg I create a package that depends on pysnmp so I'd like to distribute pysnmp with my package. I'd like to avoid extending my setup.py to repackage pysnmp (because I don't to have any idea of how it's author packaged it) and just shove pysnmp-3.4.2.tar.gz into my dist bundle and let distutils deal with it. This would also help me bundle up all the packages my team is creating for our project (we are working independently). Thanks, Craig Durland -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/distutils-sig/attachments/20041017/524d5f0f/attachment.html From mcfletch at rogers.com Mon Oct 18 23:40:18 2004 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Mon Oct 18 23:40:21 2004 Subject: [Distutils] MSToolkit and --debug-on-release for MSVCCompiler Message-ID: <41743842.4030002@rogers.com> The MS Toolkit compiler recipe I put together for building Python 2.4 extensions currently requires manually diff-ing the source of msvccompiler.py, as does my recipe for building a single extension with debug information so that developers can track down bugs in their code (without needing to rebuild dozens of other modules and core python in debug mode). The changes are pretty trivial in both cases, so I'm looking for feedback on whether I should go with sub-classing as separate compiler modules, or whether the changes should be integrated into the core compiler code-base. The debug-on-release recipe consists entirely of altering the compile_options and ldflags_shared properties of the compiler object. Problem is, the compiler API assumes that debug is a boolean flag, and AFAICT, has no access to the options the user passed in to whatever command is calling the compiler. As a result, it looks like it would be necessary to provide a compiler sub-class, one where specifying debug causes a debug-on-release set of options to be used. That seems silly, as it's just a feature of the MSVC compilers. Still, don't see any other elegant way to approach the problem. That said, this is a comparatively minor feature (which I'm told isn't really a *great* idea, no matter how practical/useful), so no big deal to keep having people do it with diffs. The more important issue, is the MSToolkit compiler. Here the logic of creating a sub-class of msvccompiler seems obvious, but doing so doesn't seem necessary from a technical standpoint... Overriding load_macros and get_msvc_paths is no problem, but the changes to get_msvc_paths should, if I read correctly, actually fix one of the long-standing annoyances (having to run the GUI at least once to get the registry keys, even though the vcvars.bat variables are already specifying everything necessary). This is coded in such a way that it simply replaces the "you should run the GUI" error message with an attempt to retrieve the variables from the environment (i.e. the only case where you run it is where you would have failed with an error before). The changes to load_macros shouldn't interfere with MSVC operation in the least (they are done as a try:except: which is only used when the MSVC operation fails). MSToolkit howto: http://www.vrplumber.com/programming/mstoolkit/ debug-on-release howto: http://groups.google.ca/groups?selm=mailman.26.1065949224.2192.python-list%40python.org Enjoy yourselves, Mike ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com From mal at egenix.com Tue Oct 19 09:54:23 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Oct 19 09:54:18 2004 Subject: [Distutils] MSToolkit and --debug-on-release for MSVCCompiler In-Reply-To: <41743842.4030002@rogers.com> References: <41743842.4030002@rogers.com> Message-ID: <4174C82F.9020706@egenix.com> Mike C. Fletcher wrote: > The MS Toolkit compiler recipe I put together for building Python 2.4 > extensions currently requires manually diff-ing the source of > msvccompiler.py, as does my recipe for building a single extension with > debug information so that developers can track down bugs in their code > (without needing to rebuild dozens of other modules and core python in > debug mode). > > The changes are pretty trivial in both cases, so I'm looking for > feedback on whether I should go with sub-classing as separate compiler > modules, or whether the changes should be integrated into the core > compiler code-base. > > The debug-on-release recipe consists entirely of altering the > compile_options and ldflags_shared properties of the compiler object. > Problem is, the compiler API assumes that debug is a boolean flag, and > AFAICT, has no access to the options the user passed in to whatever > command is calling the compiler. As a result, it looks like it would be > necessary to provide a compiler sub-class, one where specifying debug > causes a debug-on-release set of options to be used. That seems silly, > as it's just a feature of the MSVC compilers. Still, don't see any > other elegant way to approach the problem. That said, this is a > comparatively minor feature (which I'm told isn't really a *great* idea, > no matter how practical/useful), so no big deal to keep having people do > it with diffs. Perhaps I'm missing something, but I don't really see the advantage here. If I call python setup.py build --debug I do get proper MSVC debug builds (provided I have the Python debug libs installed) of distutils based extensions. I'm not even sure whether it's a good idea to mix debug and non-debug builds of libs due to the different ways they do memory allocation (but this might be a red herring). > The more important issue, is the MSToolkit compiler. Here the logic of > creating a sub-class of msvccompiler seems obvious, but doing so doesn't > seem necessary from a technical standpoint... > Overriding load_macros and get_msvc_paths is no problem, but the changes > to get_msvc_paths should, if I read correctly, actually fix one of the > long-standing annoyances (having to run the GUI at least once to get the > registry keys, even though the vcvars.bat variables are already > specifying everything necessary). This is coded in such a way that it > simply replaces the "you should run the GUI" error message with an > attempt to retrieve the variables from the environment (i.e. the only > case where you run it is where you would have failed with an error before). > > The changes to load_macros shouldn't interfere with MSVC operation in > the least (they are done as a try:except: which is only used when the > MSVC operation fails). > > MSToolkit howto: > http://www.vrplumber.com/programming/mstoolkit/ > > debug-on-release howto: > http://groups.google.ca/groups?selm=mailman.26.1065949224.2192.python-list%40python.org > > > Enjoy yourselves, > Mike > > ________________________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://www.vrplumber.com > http://blog.vrplumber.com > > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > http://mail.python.org/mailman/listinfo/distutils-sig -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 19 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From calvin at users.sourceforge.net Tue Oct 19 10:38:17 2004 From: calvin at users.sourceforge.net (Bastian Kleineidam) Date: Tue Oct 19 10:38:27 2004 Subject: [Distutils] gcc is hardcoded in mingw32/cygwin compiler Message-ID: <20041019083817.GA16046@treasure> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://mail.python.org/pipermail/distutils-sig/attachments/20041019/cdf3ef03/attachment.pgp From pje at telecommunity.com Tue Oct 19 17:50:19 2004 From: pje at telecommunity.com (Phillip J. Eby) Date: Tue Oct 19 17:49:50 2004 Subject: [Distutils] gcc is hardcoded in mingw32/cygwin compiler In-Reply-To: <20041019083817.GA16046@treasure> Message-ID: <5.1.1.6.0.20041019114841.03cb28d0@mail.telecommunity.com> At 10:38 AM 10/19/04 +0200, Bastian Kleineidam wrote: >Hi, > >when playing with cross compiling, I noticed that "gcc" is hardcoded >in the mingw32 and cygwin compiler classes. >I'd like them to be adjustable with environment variables CC, CXX etc. >like in the unixccompiler.py class. >I attached a patch that works for me(tm), but there might be a better >way using already existing methods in sysconfig.py. >The command line I use under linux for bdist_wininst is: >CC=/usr/bin/i586-mingw32msvc-gcc \ > CCSHARED=/usr/bin/i586-mingw32msvc-gcc \ > CXX=/usr/bin/i586-mingw32msvc-g++ \ > LDSHARED="/usr/bin/i586-mingw32msvc-gcc -shared" \ > PY_HOST_PLATFORM=nt \ > $(PYTHON) setup.py build -c mingw32 bdist_wininst Sorry about this off-topic question, but are you actually successful in building bdist_wininst from Linux this way? And if so, how do you install/setup the compiler(s)? I'd love to be able to generate "daily builds" of my software on Linux, targeting bdist_wininst as well as sdist. From mcfletch at rogers.com Tue Oct 19 19:19:10 2004 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Tue Oct 19 19:19:14 2004 Subject: [Distutils] MSToolkit and --debug-on-release for MSVCCompiler In-Reply-To: <4174C82F.9020706@egenix.com> References: <41743842.4030002@rogers.com> <4174C82F.9020706@egenix.com> Message-ID: <41754C8E.8030108@rogers.com> M.-A. Lemburg wrote: ... >> The debug-on-release recipe consists entirely of altering the >> compile_options and ldflags_shared properties of the compiler >> object. Problem is, the compiler API assumes that debug is a boolean >> flag, and AFAICT, has no access to the options the user passed in to >> whatever command is calling the compiler. As a result, it looks >> like it would be >> necessary to provide a compiler sub-class, one where specifying debug >> causes a debug-on-release set of options to be used. That seems >> silly, as it's just a feature of the MSVC compilers. Still, don't >> see any other elegant way to approach the problem. That said, this >> is a comparatively minor feature (which I'm told isn't really a >> *great* idea, no matter how practical/useful), so no big deal to keep >> having people do it with diffs. > > > Perhaps I'm missing something, but I don't really see the advantage here. > If I call > > python setup.py build --debug > > I do get proper MSVC debug builds (provided I have the Python debug > libs installed) of distutils based extensions. Sure, but if you have a project with, for instance, all of wxPython, PyOpenGL, PyPgSQL, Numpy, mxBase, and a few other sundry extensions and all you want to do is track down a shallow error in your application's tiny little extension, then that "provided" becomes a serious PITA. Many dependencies require all sorts of setup to provide resources before they can be built (jpeg and png libraries, tcl/tk installations, postgresql client libraries, etceteras). Recursively building *everything* debug through the entire dependency tree can take days (and you're pretty much certain at *some* point you're going to be linking to a non-debug library anyway, after all, AFAIK there *is* no debug version of, for instance, OpenGL or GLU on Windows). > I'm not even sure whether it's a good idea to mix debug and > non-debug builds of libs due to the different ways they do > memory allocation (but this might be a red herring). Yes, that's what people keep telling me :) . As mentioned, though, I'm neither too worried about getting *this* recipe in, nor particularly concerned with the propriety of it (since it's proved useful and practical on any number of occasions for me and I can keep patching the msvccompiler manually when I need it). I just figured there may be others out there in the same boat who'd like the functionality available w/out the patching fuss. BTW, I've never actually seen a new failure appear after switching to the debug-on-release versions of a project, but that could just be a fluke. Have fun, Mike ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com From calvin at users.sourceforge.net Tue Oct 19 19:33:35 2004 From: calvin at users.sourceforge.net (Bastian Kleineidam) Date: Tue Oct 19 19:33:44 2004 Subject: [Distutils] gcc is hardcoded in mingw32/cygwin compiler In-Reply-To: <5.1.1.6.0.20041019114841.03cb28d0@mail.telecommunity.com> References: <20041019083817.GA16046@treasure> <5.1.1.6.0.20041019114841.03cb28d0@mail.telecommunity.com> Message-ID: <20041019173335.GA18315@treasure> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Phillip, On Tue, Oct 19, 2004 at 11:50:19AM -0400, Phillip J. Eby wrote: > Sorry about this off-topic question, but are you actually successful in > building bdist_wininst from Linux this way? And if so, how do you > install/setup the compiler(s)? I'd love to be able to generate "daily > builds" of my software on Linux, targeting bdist_wininst as well as sdist. I am somewhat successful. I can build a .exe installer, and it runs ok (ie installs everything in the correct places). But the generated .pyd modules are somehow incompatible. At least on Windows 2000 I get a segfault when I try to import a .pyd module. I don't understand enough of Windows .dll internals to debug this :/ Regards, Bastian - -- ,''`. Bastian Kleineidam . calvin (at) debian.org : :' : `. `' GnuPG Schl?ssel http://kampfwurst.net/gpgkey.txt `- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBdU/veBwlBDLsbz4RAvWxAKCKV/NkHUdoMFDSlukxUkwKNWRitwCfSN6j V0Ra2ehG5z8wXOGnABKJ0jo= =+d9P -----END PGP SIGNATURE----- From theller at python.net Tue Oct 19 19:57:27 2004 From: theller at python.net (Thomas Heller) Date: Tue Oct 19 19:57:05 2004 Subject: [Distutils] MSToolkit and --debug-on-release for MSVCCompiler In-Reply-To: <41743842.4030002@rogers.com> (Mike C. Fletcher's message of "Mon, 18 Oct 2004 17:40:18 -0400") References: <41743842.4030002@rogers.com> Message-ID: "Mike C. Fletcher" writes: > The debug-on-release recipe consists entirely of altering the > compile_options and ldflags_shared properties of the compiler object. > Problem is, the compiler API assumes that debug is a boolean flag, and > AFAICT, has no access to the options the user passed in to whatever > command is calling the compiler. As a result, it looks like it would > be necessary to provide a compiler sub-class, one where specifying > debug causes a debug-on-release set of options to be used. That seems > silly, as it's just a feature of the MSVC compilers. Still, don't see > any other elegant way to approach the problem. That said, this is a > comparatively minor feature (which I'm told isn't really a *great* > idea, no matter how practical/useful), so no big deal to keep having > people do it with diffs. I think you could make a subclass of build_ext, and override the build_extensions() method. You can then replace it's self.compiler.ldflags_shared and self.compiler.compile_options, maybe depending on a new 'fake-debug' command line flag or something like that. Thomas From mal at egenix.com Wed Oct 20 15:40:51 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Oct 20 15:40:58 2004 Subject: [Distutils] MSToolkit and --debug-on-release for MSVCCompiler In-Reply-To: <41754C8E.8030108@rogers.com> References: <41743842.4030002@rogers.com> <4174C82F.9020706@egenix.com> <41754C8E.8030108@rogers.com> Message-ID: <41766AE3.7070205@egenix.com> Mike C. Fletcher wrote: > M.-A. Lemburg wrote: > ... > >>> The debug-on-release recipe consists entirely of altering the >>> compile_options and ldflags_shared properties of the compiler >>> object. Problem is, the compiler API assumes that debug is a boolean >>> flag, and AFAICT, has no access to the options the user passed in to >>> whatever command is calling the compiler. As a result, it looks >>> like it would be >>> necessary to provide a compiler sub-class, one where specifying debug >>> causes a debug-on-release set of options to be used. That seems >>> silly, as it's just a feature of the MSVC compilers. Still, don't >>> see any other elegant way to approach the problem. That said, this >>> is a comparatively minor feature (which I'm told isn't really a >>> *great* idea, no matter how practical/useful), so no big deal to keep >>> having people do it with diffs. >> >> >> >> Perhaps I'm missing something, but I don't really see the advantage here. >> If I call >> >> python setup.py build --debug >> >> I do get proper MSVC debug builds (provided I have the Python debug >> libs installed) of distutils based extensions. > > > Sure, but if you have a project with, for instance, all of wxPython, > PyOpenGL, PyPgSQL, Numpy, mxBase, and a few other sundry extensions and > all you want to do is track down a shallow error in your application's > tiny little extension, then that "provided" becomes a serious PITA. > > Many dependencies require all sorts of setup to provide resources before > they can be built (jpeg and png libraries, tcl/tk installations, > postgresql client libraries, etceteras). Recursively building > *everything* debug through the entire dependency tree can take days (and > you're pretty much certain at *some* point you're going to be linking to > a non-debug library anyway, after all, AFAIK there *is* no debug version > of, for instance, OpenGL or GLU on Windows). Ok, point taken. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 20 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From bob at redivi.com Wed Oct 20 23:56:22 2004 From: bob at redivi.com (Bob Ippolito) Date: Wed Oct 20 23:56:57 2004 Subject: [Distutils] Extending distutils with 3rd party build commands? Message-ID: I've developed two bdist commands (bdist_pkg and bdist_mpkg) for usage on OS X. These commands apply to any setup.py that supports an "install" command, similar to bdist_wininst, so it would be nice if every setup.py didn't have to explicitly import something in order to get the commands there. I know I can make it work with a pth file that imports bdist_pkg, but that seems a bit costly to do because it will end up importing a bunch of stuff (distutils, mainly). Is there another way to do it? -bob From mal at egenix.com Thu Oct 21 00:10:05 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Oct 21 00:10:26 2004 Subject: [Distutils] Extending distutils with 3rd party build commands? In-Reply-To: References: Message-ID: <4176E23D.4080700@egenix.com> Bob Ippolito wrote: > I've developed two bdist commands (bdist_pkg and bdist_mpkg) for usage > on OS X. These commands apply to any setup.py that supports an > "install" command, similar to bdist_wininst, so it would be nice if > every setup.py didn't have to explicitly import something in order to > get the commands there. > > I know I can make it work with a pth file that imports bdist_pkg, but > that seems a bit costly to do because it will end up importing a bunch > of stuff (distutils, mainly). > > Is there another way to do it? Submit them for inclusion in the standard distribution ;-) Please use a different name for bdist_pkg, though, since pkg is already used for Solaris binary packages (unless, of course, yours works for Solaris packages as well). -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 20 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From bob at redivi.com Thu Oct 21 00:38:39 2004 From: bob at redivi.com (Bob Ippolito) Date: Thu Oct 21 00:39:15 2004 Subject: [Distutils] Extending distutils with 3rd party build commands? In-Reply-To: <4176E23D.4080700@egenix.com> References: <4176E23D.4080700@egenix.com> Message-ID: On Oct 20, 2004, at 18:10, M.-A. Lemburg wrote: > Bob Ippolito wrote: >> I've developed two bdist commands (bdist_pkg and bdist_mpkg) for >> usage on OS X. These commands apply to any setup.py that supports an >> "install" command, similar to bdist_wininst, so it would be nice if >> every setup.py didn't have to explicitly import something in order to >> get the commands there. >> I know I can make it work with a pth file that imports bdist_pkg, but >> that seems a bit costly to do because it will end up importing a >> bunch of stuff (distutils, mainly). >> Is there another way to do it? > > Submit them for inclusion in the standard distribution ;-) I will, for 2.5... but there's quite some time between now and then. > Please use a different name for bdist_pkg, though, since pkg is already > used for Solaris binary packages (unless, of course, yours works for > Solaris packages as well). Well .pkg is used for Mac OS X binary packages too. Also, the only hit on google for bdist_pkg is a comment I made a couple months ago. Anyhow, the most useful command is bdist_mpkg, which builds metapackages, so I'll call it that and remove the bdist_pkg command if it makes you happy :) -bob From bob at redivi.com Thu Oct 21 00:49:52 2004 From: bob at redivi.com (Bob Ippolito) Date: Thu Oct 21 00:50:29 2004 Subject: [Distutils] Extending distutils with 3rd party build commands? In-Reply-To: References: <4176E23D.4080700@egenix.com> Message-ID: <5ADF30C8-22EA-11D9-B95B-000A95BA5446@redivi.com> On Oct 20, 2004, at 18:38, Bob Ippolito wrote: > On Oct 20, 2004, at 18:10, M.-A. Lemburg wrote: > >> Bob Ippolito wrote: >>> I've developed two bdist commands (bdist_pkg and bdist_mpkg) for >>> usage on OS X. These commands apply to any setup.py that supports >>> an "install" command, similar to bdist_wininst, so it would be nice >>> if every setup.py didn't have to explicitly import something in >>> order to get the commands there. >>> I know I can make it work with a pth file that imports bdist_pkg, >>> but that seems a bit costly to do because it will end up importing a >>> bunch of stuff (distutils, mainly). >>> Is there another way to do it? >> >> Submit them for inclusion in the standard distribution ;-) > > I will, for 2.5... but there's quite some time between now and then. Well I did find another way, thanks to PEP 302. How "evil" would it be if I had this module imported by a pth file? It does do what I want it to do, but I'm not sure if it's safe to inflict on users or not.. -- import sys import imp try: set except NameError: from sets import Set as set class DistutilsHook(object): def __init__(self, package='distutils', hooks=('py2app', 'bdist_mpkg')): self.package = package self.hooks = set(hooks) self.hooks.add(package) def find_module(self, fullname, path=None): if fullname in self.hooks: self.hooks.remove(fullname) if fullname != self.package: return None try: sys.meta_path.remove(self) except ValueError: pass try: fileobj, filename, stuff = imp.find_module(fullname, None) except ImportError: return None hooks = list(self.hooks) self.hooks.clear() return ImpLoader(fileobj, filename, stuff, hooks) class ImpLoader(object): def __init__(self, fileobj, filename, stuff, hooks): self.fileobj = fileobj self.filename = filename self.stuff = stuff self.hooks = hooks def load_module(self, fullname): mod = imp.load_module(fullname, self.fileobj, self.filename, self.stuff) if self.fileobj: self.fileobj.close() for hook in self.hooks: try: __import__(hook) except: pass return mod sys.meta_path.insert(0, DistutilsHook()) From mal at egenix.com Thu Oct 21 01:03:54 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Oct 21 01:03:58 2004 Subject: [Distutils] Extending distutils with 3rd party build commands? In-Reply-To: References: <4176E23D.4080700@egenix.com> Message-ID: <4176EEDA.7060907@egenix.com> Bob Ippolito wrote: > On Oct 20, 2004, at 18:10, M.-A. Lemburg wrote: > >> Bob Ippolito wrote: >> >>> I've developed two bdist commands (bdist_pkg and bdist_mpkg) for >>> usage on OS X. These commands apply to any setup.py that supports an >>> "install" command, similar to bdist_wininst, so it would be nice if >>> every setup.py didn't have to explicitly import something in order to >>> get the commands there. >>> I know I can make it work with a pth file that imports bdist_pkg, but >>> that seems a bit costly to do because it will end up importing a >>> bunch of stuff (distutils, mainly). >>> Is there another way to do it? >> >> >> Submit them for inclusion in the standard distribution ;-) > > > I will, for 2.5... but there's quite some time between now and then. > >> Please use a different name for bdist_pkg, though, since pkg is already >> used for Solaris binary packages (unless, of course, yours works for >> Solaris packages as well). > > > Well .pkg is used for Mac OS X binary packages too. Also, the only hit > on google for bdist_pkg is a comment I made a couple months ago. We once had a bdist_pkgtool in CVS but had to remove it again due to copyright issues. Dito for bdist_sdux: http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Lib/distutils/command/Attic/ Looks like bdist_pkg is OK after all :-) It's a long time ago I had reviewed those packages. > Anyhow, the most useful command is bdist_mpkg, which builds > metapackages, so I'll call it that and remove the bdist_pkg command if > it makes you happy :) Perhaps bdist_macpkg would be more appropriate if the format is not compatible with the pkgtool output ?! -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 20 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Oct 21 01:09:11 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Oct 21 01:09:15 2004 Subject: [Distutils] Extending distutils with 3rd party build commands? In-Reply-To: <5ADF30C8-22EA-11D9-B95B-000A95BA5446@redivi.com> References: <4176E23D.4080700@egenix.com> <5ADF30C8-22EA-11D9-B95B-000A95BA5446@redivi.com> Message-ID: <4176F017.9050804@egenix.com> Bob Ippolito wrote: > On Oct 20, 2004, at 18:38, Bob Ippolito wrote: > >> On Oct 20, 2004, at 18:10, M.-A. Lemburg wrote: >> >>> Bob Ippolito wrote: >>> >>>> I've developed two bdist commands (bdist_pkg and bdist_mpkg) for >>>> usage on OS X. These commands apply to any setup.py that supports >>>> an "install" command, similar to bdist_wininst, so it would be nice >>>> if every setup.py didn't have to explicitly import something in >>>> order to get the commands there. >>>> I know I can make it work with a pth file that imports bdist_pkg, >>>> but that seems a bit costly to do because it will end up importing a >>>> bunch of stuff (distutils, mainly). >>>> Is there another way to do it? >>> >>> >>> Submit them for inclusion in the standard distribution ;-) >> >> >> I will, for 2.5... but there's quite some time between now and then. > > > Well I did find another way, thanks to PEP 302. > > How "evil" would it be if I had this module imported by a pth file? It > does do what I want it to do, but I'm not sure if it's safe to inflict > on users or not.. Import hooks are bad. Avoid them if you can. What so bad in adding a sinlge import to all your setup.pys ? That import could then trigger the installation of the new command by importing distutils and tweaking the cmdclass in distutils, e.g. import biDistutilsExtensions > -- > > import sys > import imp > try: > set > except NameError: > from sets import Set as set > > class DistutilsHook(object): > def __init__(self, package='distutils', hooks=('py2app', > 'bdist_mpkg')): > self.package = package > self.hooks = set(hooks) > self.hooks.add(package) > > def find_module(self, fullname, path=None): > if fullname in self.hooks: > self.hooks.remove(fullname) > if fullname != self.package: > return None > try: > sys.meta_path.remove(self) > except ValueError: > pass > try: > fileobj, filename, stuff = imp.find_module(fullname, None) > except ImportError: > return None > hooks = list(self.hooks) > self.hooks.clear() > return ImpLoader(fileobj, filename, stuff, hooks) > > class ImpLoader(object): > def __init__(self, fileobj, filename, stuff, hooks): > self.fileobj = fileobj > self.filename = filename > self.stuff = stuff > self.hooks = hooks > > def load_module(self, fullname): > mod = imp.load_module(fullname, self.fileobj, self.filename, > self.stuff) > if self.fileobj: > self.fileobj.close() > for hook in self.hooks: > try: > __import__(hook) > except: > pass > return mod > > sys.meta_path.insert(0, DistutilsHook()) > > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > http://mail.python.org/mailman/listinfo/distutils-sig -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 20 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From bob at redivi.com Thu Oct 21 01:42:05 2004 From: bob at redivi.com (Bob Ippolito) Date: Thu Oct 21 01:42:42 2004 Subject: [Distutils] Extending distutils with 3rd party build commands? In-Reply-To: <4176F017.9050804@egenix.com> References: <4176E23D.4080700@egenix.com> <5ADF30C8-22EA-11D9-B95B-000A95BA5446@redivi.com> <4176F017.9050804@egenix.com> Message-ID: On Oct 20, 2004, at 19:09, M.-A. Lemburg wrote: > Bob Ippolito wrote: >> On Oct 20, 2004, at 18:38, Bob Ippolito wrote: >>> On Oct 20, 2004, at 18:10, M.-A. Lemburg wrote: >>> >>>> Bob Ippolito wrote: >>>> >>>>> I've developed two bdist commands (bdist_pkg and bdist_mpkg) for >>>>> usage on OS X. These commands apply to any setup.py that supports >>>>> an "install" command, similar to bdist_wininst, so it would be >>>>> nice if every setup.py didn't have to explicitly import something >>>>> in order to get the commands there. >>>>> I know I can make it work with a pth file that imports bdist_pkg, >>>>> but that seems a bit costly to do because it will end up importing >>>>> a bunch of stuff (distutils, mainly). >>>>> Is there another way to do it? >>>> >>>> >>>> Submit them for inclusion in the standard distribution ;-) >>> >>> >>> I will, for 2.5... but there's quite some time between now and then. >> Well I did find another way, thanks to PEP 302. >> How "evil" would it be if I had this module imported by a pth file? >> It does do what I want it to do, but I'm not sure if it's safe to >> inflict on users or not.. > > Import hooks are bad. Avoid them if you can. > > What so bad in adding a sinlge import to all your setup.pys ? > That import could then trigger the installation of the new > command by importing distutils and tweaking the cmdclass > in distutils, e.g. > > import biDistutilsExtensions Because I want to recommend that people use bdist_mpkg to install arbitrary python packages similar to the way that bdist_wininst is used. Yes, I know import hooks are bad, but I don't want people to have to go around modifying every setup.py they see. -bob From bob at redivi.com Thu Oct 21 01:58:09 2004 From: bob at redivi.com (Bob Ippolito) Date: Thu Oct 21 01:58:45 2004 Subject: [Distutils] Extending distutils with 3rd party build commands? In-Reply-To: <4176EEDA.7060907@egenix.com> References: <4176E23D.4080700@egenix.com> <4176EEDA.7060907@egenix.com> Message-ID: On Oct 20, 2004, at 19:03, M.-A. Lemburg wrote: > Bob Ippolito wrote: >> On Oct 20, 2004, at 18:10, M.-A. Lemburg wrote: >>> Bob Ippolito wrote: >>> >>>> I've developed two bdist commands (bdist_pkg and bdist_mpkg) for >>>> usage on OS X. These commands apply to any setup.py that supports >>>> an "install" command, similar to bdist_wininst, so it would be nice >>>> if every setup.py didn't have to explicitly import something in >>>> order to get the commands there. >>>> I know I can make it work with a pth file that imports bdist_pkg, >>>> but that seems a bit costly to do because it will end up importing >>>> a bunch of stuff (distutils, mainly). >>>> Is there another way to do it? >>> >>> >>> Submit them for inclusion in the standard distribution ;-) >> I will, for 2.5... but there's quite some time between now and then. >>> Please use a different name for bdist_pkg, though, since pkg is >>> already >>> used for Solaris binary packages (unless, of course, yours works for >>> Solaris packages as well). >> Well .pkg is used for Mac OS X binary packages too. Also, the only >> hit on google for bdist_pkg is a comment I made a couple months ago. > > We once had a bdist_pkgtool in CVS but had to remove it again > due to copyright issues. Dito for bdist_sdux: > > http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Lib/ > distutils/command/Attic/ > > Looks like bdist_pkg is OK after all :-) It's a long time > ago I had reviewed those packages. Well I went ahead and made the change to bdist_mpkg.. I haven't put out a release of this code yet, and I'm using subversion, so it wasn't a big deal. >> Anyhow, the most useful command is bdist_mpkg, which builds >> metapackages, so I'll call it that and remove the bdist_pkg command >> if it makes you happy :) > > Perhaps bdist_macpkg would be more appropriate if the format > is not compatible with the pkgtool output ?! Mac OS X uses two kinds of bundles[1] for installation purposes: Packages: extension of .pkg - contains an archive of files to be installed (plus metadata, bill of materials, optional scripts for preflight/upgrade/etc.), after installing a Package, a receipt (basically a copy sans the archive) is placed into a centralized installation database location (/Library/Receipts) Metapackages: extension of .mpkg - contains references to Packages and Metapackages (plus metadata, optional scripts, etc.), these may be located anywhere that can be referenced absolutely or relative to the Metapackage (including inside the Metapackage - it is just a directory) Naturally, a good choice for the bdist name would be bdist_pkg or bdist_mpkg. Since creating a bdist_mpkg is more useful (separate purelib/platlib/scripts/etc.), I've agreed to rename it to bdist_mpkg. I don't like bdist_macpkg or anything of that sort. I would like to keep it in line with one of the two extensions that it uses, like bdist_rpm (and future obvious choices like bdist_deb, bdist_msi, etc. I'm sure). It's also convenient that "m" is the first letter in Mac, and that I'm pretty sure that no other OS uses "mpkg". [1] Bundles, in Mac OS X terms, are directories of a certain hierarchy that are presented opaquely as a single object to the user from the GUI. -bob From slash at dotnetslash.net Thu Oct 21 03:14:39 2004 From: slash at dotnetslash.net (Mark W. Alexander) Date: Thu Oct 21 03:14:42 2004 Subject: [Distutils] Extending distutils with 3rd party build commands? In-Reply-To: <4176EEDA.7060907@egenix.com> References: <4176E23D.4080700@egenix.com> <4176EEDA.7060907@egenix.com> Message-ID: <20041021011438.GC2243@dotnetslash.net> On Thu, Oct 21, 2004 at 01:03:54AM +0200, M.-A. Lemburg wrote: > >Well .pkg is used for Mac OS X binary packages too. Also, the only hit > >on google for bdist_pkg is a comment I made a couple months ago. > > We once had a bdist_pkgtool in CVS but had to remove it again > due to copyright issues. Dito for bdist_sdux: > > http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Lib/distutils/command/Attic/ > > Looks like bdist_pkg is OK after all :-) It's a long time > ago I had reviewed those packages. Yes, pkgtool is the "proper" Solaris, well, package tool. And I'm +1 for _any_ additional bdist_* commands being included in mainline. Also, the issue was not copyright per se, but my employer's name on the PSF Contributor Agreement. I'm _still_ working that issue (2 years! that's depressing), however I was recently granted permission to assume maintainership of an existing Python-style licensed project (pyssh) so there is light at the end of the tunnel. (I hope it's not a train ;) But I'll offer once again advisory assistance to anyone who wants to "clean room" a bdist_pkgtool and bdist_sdux that can sign the Contributor Agreement. I strongly believe that the more native package managers Distutils supports, the easier it is to get Python into "enterprises." Based on having some approval to publish code absent my employer's name, I've considered packaging the original submissions as "Distutils Extensions" outside of mainline, since they are standalone files with no impact on or changes in any other distutils modules. What are thoughts on that approach? mwa -- Mark W. Alexander slash@dotnetslash.net The contents of this message authored by Mark W. Alexander are released under the Creative Commons Attribution-NonCommercial license. Copyright of quoted materials, if any, are retained by the original author(s). http://creativecommons.org/licenses/by-nc/2.0/ From pje at telecommunity.com Thu Oct 21 04:19:04 2004 From: pje at telecommunity.com (Phillip J. Eby) Date: Thu Oct 21 04:18:45 2004 Subject: [Distutils] Extending distutils with 3rd party build commands? In-Reply-To: <4176F017.9050804@egenix.com> References: <5ADF30C8-22EA-11D9-B95B-000A95BA5446@redivi.com> <4176E23D.4080700@egenix.com> <5ADF30C8-22EA-11D9-B95B-000A95BA5446@redivi.com> Message-ID: <5.1.1.6.0.20041020221715.02459b50@mail.telecommunity.com> At 01:09 AM 10/21/04 +0200, M.-A. Lemburg wrote: >Bob Ippolito wrote: >>On Oct 20, 2004, at 18:38, Bob Ippolito wrote: >> >>>On Oct 20, 2004, at 18:10, M.-A. Lemburg wrote: >>> >>>>Bob Ippolito wrote: >>>> >>>>>I've developed two bdist commands (bdist_pkg and bdist_mpkg) for usage >>>>>on OS X. These commands apply to any setup.py that supports an >>>>>"install" command, similar to bdist_wininst, so it would be nice if >>>>>every setup.py didn't have to explicitly import something in order to >>>>>get the commands there. >>>>>I know I can make it work with a pth file that imports bdist_pkg, but >>>>>that seems a bit costly to do because it will end up importing a bunch >>>>>of stuff (distutils, mainly). >>>>>Is there another way to do it? >>>> >>>> >>>>Submit them for inclusion in the standard distribution ;-) >>> >>> >>>I will, for 2.5... but there's quite some time between now and then. >> >>Well I did find another way, thanks to PEP 302. >>How "evil" would it be if I had this module imported by a pth file? It >>does do what I want it to do, but I'm not sure if it's safe to inflict on >>users or not.. > >Import hooks are bad. Avoid them if you can. > >What so bad in adding a sinlge import to all your setup.pys ? >That import could then trigger the installation of the new >command by importing distutils and tweaking the cmdclass >in distutils, e.g. > >import biDistutilsExtensions Another possibility: create a script that does the import, then calls execfile() on 'setup.py' in the current directory, so that you can just run that script instead of setup.py. You can then install that script, so users can run it against any setup.py. From bob at redivi.com Thu Oct 21 05:02:51 2004 From: bob at redivi.com (Bob Ippolito) Date: Thu Oct 21 05:03:26 2004 Subject: [Distutils] Extending distutils with 3rd party build commands? In-Reply-To: <5.1.1.6.0.20041020221715.02459b50@mail.telecommunity.com> References: <5ADF30C8-22EA-11D9-B95B-000A95BA5446@redivi.com> <4176E23D.4080700@egenix.com> <5ADF30C8-22EA-11D9-B95B-000A95BA5446@redivi.com> <5.1.1.6.0.20041020221715.02459b50@mail.telecommunity.com> Message-ID: On Oct 20, 2004, at 22:19, Phillip J. Eby wrote: > At 01:09 AM 10/21/04 +0200, M.-A. Lemburg wrote: >> Bob Ippolito wrote: >>> On Oct 20, 2004, at 18:38, Bob Ippolito wrote: >>> >>>> On Oct 20, 2004, at 18:10, M.-A. Lemburg wrote: >>>> >>>>> Bob Ippolito wrote: >>>>> >>>>>> I've developed two bdist commands (bdist_pkg and bdist_mpkg) for >>>>>> usage on OS X. These commands apply to any setup.py that >>>>>> supports an "install" command, similar to bdist_wininst, so it >>>>>> would be nice if every setup.py didn't have to explicitly import >>>>>> something in order to get the commands there. >>>>>> I know I can make it work with a pth file that imports bdist_pkg, >>>>>> but that seems a bit costly to do because it will end up >>>>>> importing a bunch of stuff (distutils, mainly). >>>>>> Is there another way to do it? >>>>> >>>>> >>>>> Submit them for inclusion in the standard distribution ;-) >>>> >>>> >>>> I will, for 2.5... but there's quite some time between now and then. >>> >>> Well I did find another way, thanks to PEP 302. >>> How "evil" would it be if I had this module imported by a pth file? >>> It does do what I want it to do, but I'm not sure if it's safe to >>> inflict on users or not.. >> >> Import hooks are bad. Avoid them if you can. >> >> What so bad in adding a sinlge import to all your setup.pys ? >> That import could then trigger the installation of the new >> command by importing distutils and tweaking the cmdclass >> in distutils, e.g. >> >> import biDistutilsExtensions > > Another possibility: create a script that does the import, then calls > execfile() on 'setup.py' in the current directory, so that you can > just run that script instead of setup.py. You can then install that > script, so users can run it against any setup.py. Yeah, I guess that's the only reasonable thing to do until Python 2.5 :) -bob From bob at redivi.com Thu Oct 21 06:35:17 2004 From: bob at redivi.com (Bob Ippolito) Date: Thu Oct 21 06:35:55 2004 Subject: [Distutils] ANN: py2app / bdist_mpkg 0.1.5 preview Message-ID: <9BAA7798-231A-11D9-A940-000A95BA5446@redivi.com> I've put together a little preview of py2app 0.1.5, which has MAJOR feature enhancements over 0.1.4. http://undefined.org/python/py2app-0.1.5.mpkg.zip (installer for Mac OS X 10.3) http://svn.red-bean.com/bob/py2app/trunk (source repository) http://svn.red-bean.com/pyobjc/branches/py2app-branch/ (PyObjC repository refactored to use py2app and bdist_mpkg) py2app: non-ascii application names works now (e.g. J?ger) support for non-framework builds of Python (e.g. darwinports) slightly more documentation (INSTALLING.txt, README.txt) PyPI information enhanced setup.py that can use bdist_mpkg builds and installs the py2applet tool as part of its bdist_mpkg script (to /Developer/Applications/Python Tools/py2app/) installs the examples to /Developer/Python/py2app/Examples bdist_mpkg: It's new! bdist_mpkg is a distutils command that builds a metapackage for Installer.app (or /usr/sbin/installer). It's part of the py2app suite. It should work with ANY distutils-using Python module or application that uses distutils and doesn't really screw up their "install" command When using bdist_mpkg with a framework Python, it will default the scripts installation dir to /usr/local/bin instead of the middle of nowhere inside the Python framework It installs a script, /usr/local/bin/bdist_mpkg, which you can use to build metapackages from any setup.py. When the metapackage is built, it will even open Installer for you (unless you pass it any --options, or just --). This is a great alternative to using python setup.py install. You can just customize and uncheck scripts, headers, etc. if you don't want to install them. You can subclass bdist_mpkg and make it do crazy things, like install documentation, code examples, or applications. See py2app's setup-lib/py2app_mpkg.py or PyObjC's setup-lib/pyobjc_mpkg.py (on the py2app-branch) bdist_mpkg should become the "guts" of the next generation PackageManager instead of bdist_dumb tarballs. will automatically determine if root permissions are required to install the package (make sure you haven't mucked with your permissions your build machine if you plan on distributing the metapackages) After the dust settles a bit, probably this weekend, I'll do a more official release... but I would like to get some feedback in the meantime. -bob From mal at egenix.com Thu Oct 21 09:51:50 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Oct 21 09:51:46 2004 Subject: [Distutils] Extending distutils with 3rd party build commands? In-Reply-To: References: <4176E23D.4080700@egenix.com> <5ADF30C8-22EA-11D9-B95B-000A95BA5446@redivi.com> <4176F017.9050804@egenix.com> Message-ID: <41776A96.8060903@egenix.com> Bob Ippolito wrote: > On Oct 20, 2004, at 19:09, M.-A. Lemburg wrote: >> Import hooks are bad. Avoid them if you can. >> >> What so bad in adding a sinlge import to all your setup.pys ? >> That import could then trigger the installation of the new >> command by importing distutils and tweaking the cmdclass >> in distutils, e.g. >> >> import biDistutilsExtensions > > Because I want to recommend that people use bdist_mpkg to install > arbitrary python packages similar to the way that bdist_wininst is > used. Yes, I know import hooks are bad, but I don't want people to have > to go around modifying every setup.py they see. I was talking about the packager, not the user who wants to install a package (s/he would use the output of bdist_mpkg, not the setup.py). I also assume that there will have to be other modifications to the code to make it compatible to bdist_mpkg - just like you have to provide extra options to make bdist_wininst and bdist_rpm do what you like. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 21 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Oct 21 10:25:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Oct 21 10:25:18 2004 Subject: [Distutils] Extending distutils with 3rd party build commands? In-Reply-To: <20041021011438.GC2243@dotnetslash.net> References: <4176E23D.4080700@egenix.com> <4176EEDA.7060907@egenix.com> <20041021011438.GC2243@dotnetslash.net> Message-ID: <41777269.8070600@egenix.com> Mark W. Alexander wrote: > On Thu, Oct 21, 2004 at 01:03:54AM +0200, M.-A. Lemburg wrote: > >>>Well .pkg is used for Mac OS X binary packages too. Also, the only hit >>>on google for bdist_pkg is a comment I made a couple months ago. >> >>We once had a bdist_pkgtool in CVS but had to remove it again >>due to copyright issues. Dito for bdist_sdux: >> >>http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Lib/distutils/command/Attic/ >> >>Looks like bdist_pkg is OK after all :-) It's a long time >>ago I had reviewed those packages. > > > Yes, pkgtool is the "proper" Solaris, well, package tool. And I'm +1 for > _any_ additional bdist_* commands being included in mainline. > > Also, the issue was not copyright per se, but my employer's name on the > PSF Contributor Agreement. I'm _still_ working that issue (2 years! > that's depressing), however I was recently granted permission to assume > maintainership of an existing Python-style licensed project (pyssh) so > there is light at the end of the tunnel. Hey, that'd be great ! We definitely need more of these bdist_xxx commands, e.g. one for Debian packages, MSI packages, maybe even Inno Setup packages, etc. > (I hope it's not a train ;) > > But I'll offer once again advisory assistance to anyone who wants to > "clean room" a bdist_pkgtool and bdist_sdux that can sign the > Contributor Agreement. I strongly believe that the more native package > managers Distutils supports, the easier it is to get Python into > "enterprises." > > Based on having some approval to publish code absent my employer's name, > I've considered packaging the original submissions as "Distutils > Extensions" outside of mainline, since they are standalone files with no > impact on or changes in any other distutils modules. What are thoughts > on that approach? Note that the PSF is currently working on getting a contributor agreement ready to be published (and it changed a lot since the first round of agreements were discussed). Perhaps the new version will make things easier for you ?! (I don't have a URL for it, please email the PSF about this issue.) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 21 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From calvin at users.sourceforge.net Sat Oct 16 02:53:46 2004 From: calvin at users.sourceforge.net (Bastian Kleineidam) Date: Thu Oct 21 13:28:10 2004 Subject: [Distutils] bdist_wininst under Linux with C extension modules Message-ID: <20041016005346.GA25844@treasure> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I wrote a little [1]guide how to generate a .exe installer under Linux, even if your python application has C extension modules. [1] http://kampfwurst.net/python-mingw32/ It is useful for me because I want to generate .exe installers and only have Linux installed on my machines. Perhaps other bdist_wininst/Linux fans find this useful too :) Regards, Bastian - -- ,''`. Bastian Kleineidam . calvin (at) debian.org : :' : `. `' GnuPG Schl?ssel http://kampfwurst.net/gpgkey.txt `- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBcHEaeBwlBDLsbz4RApveAJ0emBYsNIWv4HZiRq7ZgMQuTsxtzACgku71 jy7hT2qm6XUAHUYJ7Ilb66E= =n4gi -----END PGP SIGNATURE----- From trikeman at localnet.com Thu Oct 21 13:32:26 2004 From: trikeman at localnet.com (William Morrone) Date: Thu Oct 21 13:32:23 2004 Subject: [Distutils] Re: Mail Delivery (failure support@freeslide.com) Message-ID: <000501c4b761$a5ad3840$d241ca42@usmcyjl05p9g9n> I want you to stop sending me all this junk mail I have put up with it for too long now and I want it stopped.Do not send me anything else I do not wish any more email from you of any sort.Thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/distutils-sig/attachments/20041021/9d398350/attachment.htm From bob at redivi.com Thu Oct 21 14:50:27 2004 From: bob at redivi.com (Bob Ippolito) Date: Thu Oct 21 14:51:03 2004 Subject: [Distutils] Extending distutils with 3rd party build commands? In-Reply-To: <41776A96.8060903@egenix.com> References: <4176E23D.4080700@egenix.com> <5ADF30C8-22EA-11D9-B95B-000A95BA5446@redivi.com> <4176F017.9050804@egenix.com> <41776A96.8060903@egenix.com> Message-ID: On Oct 21, 2004, at 3:51, M.-A. Lemburg wrote: > Bob Ippolito wrote: >> On Oct 20, 2004, at 19:09, M.-A. Lemburg wrote: >>> Import hooks are bad. Avoid them if you can. >>> >>> What so bad in adding a sinlge import to all your setup.pys ? >>> That import could then trigger the installation of the new >>> command by importing distutils and tweaking the cmdclass >>> in distutils, e.g. >>> >>> import biDistutilsExtensions >> Because I want to recommend that people use bdist_mpkg to install >> arbitrary python packages similar to the way that bdist_wininst is >> used. Yes, I know import hooks are bad, but I don't want people to >> have to go around modifying every setup.py they see. > > I was talking about the packager, not the user who wants to install > a package (s/he would use the output of bdist_mpkg, not the > setup.py). Well, I want users to be packagers as well. Not every Python module is going to have a prebuilt .mpkg lying around, and using bdist_mpkg to install modules has its advantages over a normal setup.py install. The three big ones are: it goes into the installation database so you can remove it, you can choose what you don't want to install, and it puts scripts in a reasonable place (sys.prefix for a typical --enable-framework Python points inside a framework, so "bin" lives far away from PATH, when /usr/local/bin is almost always preferable). > I also assume that there will have to be other modifications > to the code to make it compatible to bdist_mpkg - just like you > have to provide extra options to make bdist_wininst and bdist_rpm > do what you like. Nope, it does the right thing by default, no options are necessary. Unless you want to add stuff like examples, documentation, etc. that the 'install' command wouldn't provide for you. It will automatically pick up any readme or license it finds and insert that into the installer, if not it will use long_description for the readme. -bob From pje at telecommunity.com Thu Oct 21 17:50:10 2004 From: pje at telecommunity.com (Phillip J. Eby) Date: Thu Oct 21 17:50:01 2004 Subject: [Distutils] Extending distutils with 3rd party build commands? In-Reply-To: References: <5.1.1.6.0.20041020221715.02459b50@mail.telecommunity.com> <5ADF30C8-22EA-11D9-B95B-000A95BA5446@redivi.com> <4176E23D.4080700@egenix.com> <5ADF30C8-22EA-11D9-B95B-000A95BA5446@redivi.com> <5.1.1.6.0.20041020221715.02459b50@mail.telecommunity.com> Message-ID: <5.1.1.6.0.20041021114946.021abec0@mail.telecommunity.com> At 11:02 PM 10/20/04 -0400, Bob Ippolito wrote: >On Oct 20, 2004, at 22:19, Phillip J. Eby wrote: >> >>Another possibility: create a script that does the import, then calls >>execfile() on 'setup.py' in the current directory, so that you can just >>run that script instead of setup.py. You can then install that script, >>so users can run it against any setup.py. > >Yeah, I guess that's the only reasonable thing to do until Python 2.5 :) Well, in 2.4, your script can be a module, and executed with '-m'. :) From pje at telecommunity.com Thu Oct 21 18:01:38 2004 From: pje at telecommunity.com (Phillip J. Eby) Date: Thu Oct 21 18:01:29 2004 Subject: [Distutils] bdist_wininst under Linux with C extension modules In-Reply-To: <20041016005346.GA25844@treasure> Message-ID: <5.1.1.6.0.20041021115553.0217c860@mail.telecommunity.com> At 02:53 AM 10/16/04 +0200, Bastian Kleineidam wrote: >Hi, > >I wrote a little [1]guide how to generate a .exe installer under Linux, >even if your python application has C extension modules. >[1] http://kampfwurst.net/python-mingw32/ > >It is useful for me because I want to generate .exe installers and >only have Linux installed on my machines. >Perhaps other bdist_wininst/Linux fans find this useful too :) Interesting. It looks like there are definitely some things distutils could do to make the process easier. For example, bdist_wininst could possibly sort out the install path issues on its own. Actually, as complicated as your example setup.py is, I wonder if it might not be easier to just run the Windows python under Wine, than to rewrite a setup.py to support cross compiling. From bob at redivi.com Thu Oct 21 18:16:38 2004 From: bob at redivi.com (Bob Ippolito) Date: Thu Oct 21 18:17:13 2004 Subject: [Distutils] Extending distutils with 3rd party build commands? In-Reply-To: <5.1.1.6.0.20041021114946.021abec0@mail.telecommunity.com> References: <5.1.1.6.0.20041020221715.02459b50@mail.telecommunity.com> <5ADF30C8-22EA-11D9-B95B-000A95BA5446@redivi.com> <4176E23D.4080700@egenix.com> <5ADF30C8-22EA-11D9-B95B-000A95BA5446@redivi.com> <5.1.1.6.0.20041020221715.02459b50@mail.telecommunity.com> <5.1.1.6.0.20041021114946.021abec0@mail.telecommunity.com> Message-ID: <9657912C-237C-11D9-9963-000A95BA5446@redivi.com> On Oct 21, 2004, at 11:50, Phillip J. Eby wrote: > At 11:02 PM 10/20/04 -0400, Bob Ippolito wrote: > >> On Oct 20, 2004, at 22:19, Phillip J. Eby wrote: >>> >>> Another possibility: create a script that does the import, then >>> calls execfile() on 'setup.py' in the current directory, so that you >>> can just run that script instead of setup.py. You can then install >>> that script, so users can run it against any setup.py. >> >> Yeah, I guess that's the only reasonable thing to do until Python 2.5 >> :) > > Well, in 2.4, your script can be a module, and executed with '-m'. :) From python-dev it sounded like that feature might not make it into 2.4.. I did make it a script though, I'm not sure why I didn't think of that before. #!/usr/bin/env python import sys, os import bdist_mpkg del sys.argv[0] if not sys.argv: sys.argv[:0] = ['setup.py', '--open'] elif sys.argv[0].startswith('-'): sys.argv[:0] = ['setup.py'] elif len(sys.argv) == 1: sys.argv[1:1] = ['--open'] sys.argv.insert(1, 'bdist_mpkg') if os.path.dirname(sys.argv[0]): path,name = os.path.split(sys.argv[0]) os.chdir(path) sys.argv[0] = name __file__ = sys.argv[0] execfile(sys.argv[0], globals(), locals()) -bob From slash at dotnetslash.net Fri Oct 22 00:42:47 2004 From: slash at dotnetslash.net (Mark W. Alexander) Date: Fri Oct 22 00:42:49 2004 Subject: [Distutils] Extending distutils with 3rd party build commands? In-Reply-To: <41777269.8070600@egenix.com> References: <4176E23D.4080700@egenix.com> <4176EEDA.7060907@egenix.com> <20041021011438.GC2243@dotnetslash.net> <41777269.8070600@egenix.com> Message-ID: <20041021224247.GB4648@dotnetslash.net> On Thu, Oct 21, 2004 at 10:25:13AM +0200, M.-A. Lemburg wrote: > Mark W. Alexander wrote: > >On Thu, Oct 21, 2004 at 01:03:54AM +0200, M.-A. Lemburg wrote: > > > >Also, the issue was not copyright per se, but my employer's name on the > >PSF Contributor Agreement. I'm _still_ working that issue (2 years! > >that's depressing), however I was recently granted permission to assume > >maintainership of an existing Python-style licensed project (pyssh) so > >there is light at the end of the tunnel. > > Hey, that'd be great ! > > We definitely need more of these bdist_xxx commands, e.g. > one for Debian packages, MSI packages, maybe even Inno Setup > packages, etc. I'm chomping to do a bdist_deb, but sitting on my hands hoping someone who can contribute it will do it first. If I get the go-ahead on the others, though, I'll do it. OTOH, we're deprecating HP-UX so unless I can hide a D250 under my desk I may not be able to properly maintain bdist_sdux for long. I know sourceforge has a compile farm. Does anyone know if they have HP-UX available (or am I thinking of something else?). > Note that the PSF is currently working on getting a contributor > agreement ready to be published (and it changed a lot since the > first round of agreements were discussed). > > Perhaps the new version will make things easier for you ?! > (I don't have a URL for it, please email the PSF about this > issue.) Thanks, I'll check it into it. Mark -- Mark W. Alexander slash@dotnetslash.net The contents of this message authored by Mark W. Alexander are released under the Creative Commons Attribution-NonCommercial license. Copyright of quoted materials, if any, are retained by the original author(s). http://creativecommons.org/licenses/by-nc/2.0/ From mwh at python.net Fri Oct 22 13:12:03 2004 From: mwh at python.net (Michael Hudson) Date: Fri Oct 22 13:12:06 2004 Subject: [Distutils] Extending distutils with 3rd party build commands? In-Reply-To: <20041021224247.GB4648@dotnetslash.net> (Mark W. Alexander's message of "Thu, 21 Oct 2004 18:42:47 -0400") References: <4176E23D.4080700@egenix.com> <4176EEDA.7060907@egenix.com> <20041021011438.GC2243@dotnetslash.net> <41777269.8070600@egenix.com> <20041021224247.GB4648@dotnetslash.net> Message-ID: <2m7jpjc8ho.fsf@starship.python.net> "Mark W. Alexander" writes: > OTOH, we're deprecating HP-UX so unless I can hide a D250 under my desk > I may not be able to properly maintain bdist_sdux for long. I know > sourceforge has a compile farm. Does anyone know if they have HP-UX > available (or am I thinking of something else?). HP's testdrive program has (or had, last time I looked) a bunch of HP-UX machines. I really hope they've updated GCC on the itanium/hp-ux machines since the last time I played around on them... Cheers, mwh -- The snakes are optional, as are the electrodes, the molten lead and the ritual buggering by syphilitic warthogs. -- Tanuki the Raccoon-dog, asr From fdrake at acm.org Fri Oct 22 23:18:37 2004 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Fri Oct 22 23:20:27 2004 Subject: [Distutils] Extending distutils with 3rd party build commands? In-Reply-To: References: <41776A96.8060903@egenix.com> Message-ID: <200410221718.37491.fdrake@acm.org> One thing that no one has mentioned in this thread is the "command-packages" support I added to distutils for Python 2.4. I think this supports Bob's use case well. What's needed is to install a Python package containing the new commands somewhere on the search path (preferably in .../site-packages). Then edit the Python installations distutils config file (bet you didn't know about that!) to include [global] command-packages=my.pkg The new commands will be available for all setup.py scripts. This is a documented feature; you can read more about it at http://www.python.org/dev/doc/devel/dist/node29.html -Fred -- Fred L. Drake, Jr. From bob at redivi.com Sat Oct 23 00:04:58 2004 From: bob at redivi.com (Bob Ippolito) Date: Sat Oct 23 00:05:44 2004 Subject: [Distutils] Extending distutils with 3rd party build commands? In-Reply-To: <200410221718.37491.fdrake@acm.org> References: <41776A96.8060903@egenix.com> <200410221718.37491.fdrake@acm.org> Message-ID: <6A24A8C5-2476-11D9-B689-000A95BA5446@redivi.com> On Oct 22, 2004, at 17:18, Fred L. Drake, Jr. wrote: > One thing that no one has mentioned in this thread is the > "command-packages" > support I added to distutils for Python 2.4. I think this supports > Bob's use > case well. > > What's needed is to install a Python package containing the new > commands > somewhere on the search path (preferably in .../site-packages). Then > edit > the Python installations distutils config file (bet you didn't know > about > that!) to include > > [global] > command-packages=my.pkg > > The new commands will be available for all setup.py scripts. > > This is a documented feature; you can read more about it at > > http://www.python.org/dev/doc/devel/dist/node29.html That does indeed support this use case.. I may have to move things around in the package a bit to support it, but it may just work. Now what about the "Python installations distutils config file"? Where's that located? I don't see it referenced in the documentation.. Can that file be placed somewhere on site-packages like sitecustomize (good), or does it require editing a root-owned vendor file (bad)? -bob From bob at redivi.com Sat Oct 23 00:23:51 2004 From: bob at redivi.com (Bob Ippolito) Date: Sat Oct 23 00:24:27 2004 Subject: [Distutils] Extending distutils with 3rd party build commands? In-Reply-To: <6A24A8C5-2476-11D9-B689-000A95BA5446@redivi.com> References: <41776A96.8060903@egenix.com> <200410221718.37491.fdrake@acm.org> <6A24A8C5-2476-11D9-B689-000A95BA5446@redivi.com> Message-ID: <0D191DF4-2479-11D9-B689-000A95BA5446@redivi.com> On Oct 22, 2004, at 18:04, Bob Ippolito wrote: > On Oct 22, 2004, at 17:18, Fred L. Drake, Jr. wrote: > >> One thing that no one has mentioned in this thread is the >> "command-packages" >> support I added to distutils for Python 2.4. I think this supports >> Bob's use >> case well. >> >> What's needed is to install a Python package containing the new >> commands >> somewhere on the search path (preferably in .../site-packages). Then >> edit >> the Python installations distutils config file (bet you didn't know >> about >> that!) to include >> >> [global] >> command-packages=my.pkg >> >> The new commands will be available for all setup.py scripts. >> >> This is a documented feature; you can read more about it at >> >> http://www.python.org/dev/doc/devel/dist/node29.html > > That does indeed support this use case.. I may have to move things > around in the package a bit to support it, but it may just work. > > Now what about the "Python installations distutils config file"? > Where's that located? I don't see it referenced in the > documentation.. Can that file be placed somewhere on site-packages > like sitecustomize (good), or does it require editing a root-owned > vendor file (bad)? Ok, I tracked it down to distutils.dist. Unfortunately, it looks like this feature won't be very useful for my use case after all. There are only a few locations searched for distutils configuration files: - 'distutils.cfg' must either go inside the distutils package itself (vendor files, bad) - '.pydistutils.cfg' ('pydistutils.cfg' in win32/macos classic) located in the user's home directory (per-user, bad) - 'setup.cfg' in the current directory (per-package, worse) I need an editable file in a system-wide directory such as site-packages that isn't "owned" by the Python installation. Even if this were the case, it would be a real pain to implement, because it would have to be done as a very careful postflight script that merges the user's current config file with the necessary additions (in this case, make sure to preserve anything else in the command-packages list if there is one). -bob From pje at telecommunity.com Sat Oct 23 03:14:22 2004 From: pje at telecommunity.com (Phillip J. Eby) Date: Sat Oct 23 03:14:54 2004 Subject: [Distutils] Extending distutils with 3rd party build commands? In-Reply-To: <0D191DF4-2479-11D9-B689-000A95BA5446@redivi.com> References: <6A24A8C5-2476-11D9-B689-000A95BA5446@redivi.com> <41776A96.8060903@egenix.com> <200410221718.37491.fdrake@acm.org> <6A24A8C5-2476-11D9-B689-000A95BA5446@redivi.com> Message-ID: <5.1.1.6.0.20041022211326.02a29920@mail.telecommunity.com> At 06:23 PM 10/22/04 -0400, Bob Ippolito wrote: >I need an editable file in a system-wide directory such as site-packages >that isn't "owned" by the Python installation. Even if this were the >case, it would be a real pain to implement, because it would have to be >done as a very careful postflight script that merges the user's current >config file with the necessary additions (in this case, make sure to >preserve anything else in the command-packages list if there is one). So tell your users to use the command line option, and also tell 'em about the files they can edit if they're interested. From joshua at rothbard.net Sat Oct 23 03:24:08 2004 From: joshua at rothbard.net (Joshua Kifer) Date: Sat Oct 23 03:24:47 2004 Subject: [Distutils] Re: [Pyobjc-dev] ANN: py2app / bdist_mpkg 0.1.5 preview In-Reply-To: <9BAA7798-231A-11D9-A940-000A95BA5446@redivi.com> References: <9BAA7798-231A-11D9-A940-000A95BA5446@redivi.com> Message-ID: <3CD35A49-2492-11D9-A4E4-00039398AC98@rothbard.net> Bob, I just switched over to using py2app -- and it's working great! Now I can toss all that XCode garbage. Joshua On Oct 20, 2004, at 9:35 PM, Bob Ippolito wrote: > I've put together a little preview of py2app 0.1.5, which has MAJOR > feature enhancements over 0.1.4. > http://undefined.org/python/py2app-0.1.5.mpkg.zip (installer for Mac > OS X 10.3) > > http://svn.red-bean.com/bob/py2app/trunk (source repository) > http://svn.red-bean.com/pyobjc/branches/py2app-branch/ (PyObjC > repository refactored to use py2app and bdist_mpkg) > > py2app: > non-ascii application names works now (e.g. J?ger) > support for non-framework builds of Python (e.g. darwinports) > slightly more documentation (INSTALLING.txt, README.txt) > PyPI information > enhanced setup.py that can use bdist_mpkg > builds and installs the py2applet tool as part of its bdist_mpkg > script (to /Developer/Applications/Python Tools/py2app/) > installs the examples to /Developer/Python/py2app/Examples > > bdist_mpkg: > It's new! bdist_mpkg is a distutils command that builds a > metapackage for Installer.app (or /usr/sbin/installer). It's part of > the py2app suite. > It should work with ANY distutils-using Python module or application > that uses distutils and doesn't really screw up their "install" > command > When using bdist_mpkg with a framework Python, it will default the > scripts installation dir to /usr/local/bin instead of the middle of > nowhere inside the Python framework > It installs a script, /usr/local/bin/bdist_mpkg, which you can use to > build metapackages from any setup.py. When the metapackage is built, > it will even open Installer for you (unless you pass it any --options, > or just --). This is a great alternative to using python setup.py > install. You can just customize and uncheck scripts, headers, etc. if > you don't want to install them. > You can subclass bdist_mpkg and make it do crazy things, like install > documentation, code examples, or applications. See py2app's > setup-lib/py2app_mpkg.py or PyObjC's setup-lib/pyobjc_mpkg.py (on the > py2app-branch) > bdist_mpkg should become the "guts" of the next generation > PackageManager instead of bdist_dumb tarballs. > will automatically determine if root permissions are required to > install the package (make sure you haven't mucked with your > permissions your build machine if you plan on distributing the > metapackages) > > > After the dust settles a bit, probably this weekend, I'll do a more > official release... but I would like to get some feedback in the > meantime. > > -bob > > > > ------------------------------------------------------- > This SF.net email is sponsored by: IT Product Guide on > ITManagersJournal > Use IT products in your business? Tell us what you think of them. Give > us > Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out > more > http://productguide.itmanagersjournal.com/guidepromo.tmpl > _______________________________________________ > Pyobjc-dev mailing list > Pyobjc-dev@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/pyobjc-dev From fdrake at acm.org Sat Oct 23 04:08:08 2004 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Sat Oct 23 04:08:36 2004 Subject: [Distutils] Extending distutils with 3rd party build commands? In-Reply-To: <6A24A8C5-2476-11D9-B689-000A95BA5446@redivi.com> References: <200410221718.37491.fdrake@acm.org> <6A24A8C5-2476-11D9-B689-000A95BA5446@redivi.com> Message-ID: <200410222208.08271.fdrake@acm.org> On Friday 22 October 2004 06:04 pm, Bob Ippolito wrote: > That does indeed support this use case.. I may have to move things > around in the package a bit to support it, but it may just work. It does require arranging the command classes the same way they're arranged in distutils itself, but that seemed fairly reasonable. > Now what about the "Python installations distutils config file"? > Where's that located? I don't see it referenced in the documentation.. > Can that file be placed somewhere on site-packages like sitecustomize > (good), or does it require editing a root-owned vendor file (bad)? See the distutils documentation for this as well: http://www.python.org/dev/doc/devel/inst/config-syntax.html (Yeah, I know, it's really hard to find things in the distutils documentation.) -Fred -- Fred L. Drake, Jr. From fdrake at acm.org Sat Oct 23 04:14:57 2004 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Sat Oct 23 04:16:02 2004 Subject: [Distutils] Extending distutils with 3rd party build commands? In-Reply-To: <0D191DF4-2479-11D9-B689-000A95BA5446@redivi.com> References: <6A24A8C5-2476-11D9-B689-000A95BA5446@redivi.com> <0D191DF4-2479-11D9-B689-000A95BA5446@redivi.com> Message-ID: <200410222214.57639.fdrake@acm.org> On Friday 22 October 2004 06:23 pm, Bob Ippolito wrote: > I need an editable file in a system-wide directory such as > site-packages that isn't "owned" by the Python installation. Even if > this were the case, it would be a real pain to implement, because it > would have to be done as a very careful postflight script that merges > the user's current config file with the necessary additions (in this > case, make sure to preserve anything else in the command-packages list > if there is one). Something that's supposed to affect all users should require that root set it up. I understand the issue about it being owned by the Python installation, though. Where would you suggest it be? $prefix/etc/distutils.cfg, perhaps? What about on Windows? If there's general agreement that this should move out of the Python installation itself, perhaps we can add a new location to the search for Python 2.5. -Fred -- Fred L. Drake, Jr. From bob at redivi.com Sat Oct 23 04:30:39 2004 From: bob at redivi.com (Bob Ippolito) Date: Sat Oct 23 04:31:34 2004 Subject: [Distutils] Extending distutils with 3rd party build commands? In-Reply-To: <200410222214.57639.fdrake@acm.org> References: <6A24A8C5-2476-11D9-B689-000A95BA5446@redivi.com> <0D191DF4-2479-11D9-B689-000A95BA5446@redivi.com> <200410222214.57639.fdrake@acm.org> Message-ID: <874D25BC-249B-11D9-A658-000A95BA5446@redivi.com> On Oct 22, 2004, at 22:14, Fred L. Drake, Jr. wrote: > On Friday 22 October 2004 06:23 pm, Bob Ippolito wrote: >> I need an editable file in a system-wide directory such as >> site-packages that isn't "owned" by the Python installation. Even if >> this were the case, it would be a real pain to implement, because it >> would have to be done as a very careful postflight script that merges >> the user's current config file with the necessary additions (in this >> case, make sure to preserve anything else in the command-packages list >> if there is one). > > Something that's supposed to affect all users should require that root > set it > up. I understand the issue about it being owned by the Python > installation, > though. The problem is that Python itself will be owned by the vendor. Let's say Apple, Debian, FreeBSD, etc. Anything additional to that should live somewhere else, in a location that's explicitly not controlled by the vendor. $prefix/etc creates another problem in that Python has never used $prefix/etc for anything before. It's not a general solution to this problem. In particular, the situation on OS X is such that site-packages is writable by the admin group (it's technically a symlink to somewhere else, but that's inconsequential), where the rest of the Python installation is owned by root:wheel (not writable by admins). It's of course possible for administrator users to authenticate as euid 0 and modify vendor files, but it's frowned upon and should not be done, period. > Where would you suggest it be? $prefix/etc/distutils.cfg, perhaps? > What > about on Windows? There should be a way to register new distutils functionality by way of sys.path. This allows the vendor, admins, users, and specific applications to add functionality. The performance impact is completely negligible. -bob From bob at redivi.com Sat Oct 23 04:34:48 2004 From: bob at redivi.com (Bob Ippolito) Date: Sat Oct 23 04:40:07 2004 Subject: [Distutils] Extending distutils with 3rd party build commands? In-Reply-To: <200410222208.08271.fdrake@acm.org> References: <200410221718.37491.fdrake@acm.org> <6A24A8C5-2476-11D9-B689-000A95BA5446@redivi.com> <200410222208.08271.fdrake@acm.org> Message-ID: <1BCEF5D0-249C-11D9-A658-000A95BA5446@redivi.com> On Oct 22, 2004, at 22:08, Fred L. Drake, Jr. wrote: > On Friday 22 October 2004 06:04 pm, Bob Ippolito wrote: >> That does indeed support this use case.. I may have to move things >> around in the package a bit to support it, but it may just work. > > It does require arranging the command classes the same way they're > arranged in > distutils itself, but that seemed fairly reasonable. Yeah, but not in all cases. py2exe uses py2exe.build_exe for a py2exe command. py2app does a similar thing (as it is modeled loosely on py2exe). bdist_mpkg does comply with the distutils way, though (it was loosely modeled on bdist_dumb). bdist_mpkg.bdist_mpkg.bdist_mpkg is the command class for the bdist_mpkg command. -bob From mal at egenix.com Sat Oct 23 11:20:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Oct 23 11:20:39 2004 Subject: [Distutils] Extending distutils with 3rd party build commands? In-Reply-To: <200410222214.57639.fdrake@acm.org> References: <6A24A8C5-2476-11D9-B689-000A95BA5446@redivi.com> <0D191DF4-2479-11D9-B689-000A95BA5446@redivi.com> <200410222214.57639.fdrake@acm.org> Message-ID: <417A2266.8080502@egenix.com> Fred L. Drake, Jr. wrote: > On Friday 22 October 2004 06:23 pm, Bob Ippolito wrote: > > I need an editable file in a system-wide directory such as > > site-packages that isn't "owned" by the Python installation. This already exists in the form of: """ There are three possible config files: distutils.cfg in the Distutils installation directory (ie. where the top-level Distutils __inst__.py file lives), a file in the user's home directory named .pydistutils.cfg on Unix and pydistutils.cfg on Windows/Mac, and setup.cfg in the current directory. """ -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From ronaldoussoren at mac.com Sat Oct 23 14:21:15 2004 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Sat Oct 23 14:22:29 2004 Subject: [Distutils] Extending distutils with 3rd party build commands? In-Reply-To: References: <4176E23D.4080700@egenix.com> <5ADF30C8-22EA-11D9-B95B-000A95BA5446@redivi.com> <4176F017.9050804@egenix.com> <41776A96.8060903@egenix.com> Message-ID: <0914E9E5-24EE-11D9-AB1B-000A95C77748@mac.com> On 21-okt-04, at 14:50, Bob Ippolito wrote: > Well, I want users to be packagers as well. Not every Python module > is going to have a prebuilt .mpkg lying around, and using bdist_mpkg > to install modules has its advantages over a normal setup.py install. > The three big ones are: it goes into the installation database so you > can remove it, [...] How do you uninstall an installed package? I haven't found a system tool for that yet. Ronald From slash at dotnetslash.net Sat Oct 23 14:32:18 2004 From: slash at dotnetslash.net (Mark W. Alexander) Date: Sat Oct 23 14:32:25 2004 Subject: [Distutils] Extending distutils with 3rd party build commands? In-Reply-To: <0914E9E5-24EE-11D9-AB1B-000A95C77748@mac.com> References: <4176E23D.4080700@egenix.com> <5ADF30C8-22EA-11D9-B95B-000A95BA5446@redivi.com> <4176F017.9050804@egenix.com> <41776A96.8060903@egenix.com> <0914E9E5-24EE-11D9-AB1B-000A95C77748@mac.com> Message-ID: <20041023123218.GB9027@dotnetslash.net> On Sat, Oct 23, 2004 at 02:21:15PM +0200, Ronald Oussoren wrote: > > How do you uninstall an installed package? I haven't found a system > tool for that yet. Only install using bdist_* commands so the native package manager can handle the uninstall? mwa -- Mark W. Alexander slash@dotnetslash.net The contents of this message authored by Mark W. Alexander are released under the Creative Commons Attribution-NonCommercial license. Copyright of quoted materials, if any, are retained by the original author(s). http://creativecommons.org/licenses/by-nc/2.0/ From bob at redivi.com Sat Oct 23 15:31:55 2004 From: bob at redivi.com (Bob Ippolito) Date: Sat Oct 23 15:32:30 2004 Subject: [Distutils] Extending distutils with 3rd party build commands? In-Reply-To: <0914E9E5-24EE-11D9-AB1B-000A95C77748@mac.com> References: <4176E23D.4080700@egenix.com> <5ADF30C8-22EA-11D9-B95B-000A95BA5446@redivi.com> <4176F017.9050804@egenix.com> <41776A96.8060903@egenix.com> <0914E9E5-24EE-11D9-AB1B-000A95C77748@mac.com> Message-ID: On Oct 23, 2004, at 8:21, Ronald Oussoren wrote: > > On 21-okt-04, at 14:50, Bob Ippolito wrote: > >> Well, I want users to be packagers as well. Not every Python module >> is going to have a prebuilt .mpkg lying around, and using bdist_mpkg >> to install modules has its advantages over a normal setup.py install. >> The three big ones are: it goes into the installation database so >> you can remove it, [...] > > How do you uninstall an installed package? I haven't found a system > tool for that yet. There isn't one, but the capability is designed into the system. There are 3rd party tools that do it. Basically you do a lsbom on the receipt and remove what's listed. -bob From bob at redivi.com Sat Oct 23 15:33:24 2004 From: bob at redivi.com (Bob Ippolito) Date: Sat Oct 23 15:33:28 2004 Subject: [Distutils] Extending distutils with 3rd party build commands? In-Reply-To: <417A2266.8080502@egenix.com> References: <6A24A8C5-2476-11D9-B689-000A95BA5446@redivi.com> <0D191DF4-2479-11D9-B689-000A95BA5446@redivi.com> <200410222214.57639.fdrake@acm.org> <417A2266.8080502@egenix.com> Message-ID: <1CF19B7A-24F8-11D9-A658-000A95BA5446@redivi.com> On Oct 23, 2004, at 5:20, M.-A. Lemburg wrote: > Fred L. Drake, Jr. wrote: >> On Friday 22 October 2004 06:23 pm, Bob Ippolito wrote: >> > I need an editable file in a system-wide directory such as >> > site-packages that isn't "owned" by the Python installation. > > This already exists in the form of: > > """ > There are three possible config files: distutils.cfg in the > Distutils installation directory (ie. where the top-level > Distutils __inst__.py file lives), a file in the user's home > directory named .pydistutils.cfg on Unix and pydistutils.cfg > on Windows/Mac, and setup.cfg in the current directory. > """ None of those fit the bill. The distutils package is owned by the Python installation, files in user directories or the current directory are not system-wide. -bob From ronaldoussoren at mac.com Sat Oct 23 17:40:22 2004 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Sat Oct 23 17:41:35 2004 Subject: [Distutils] Extending distutils with 3rd party build commands? In-Reply-To: References: <4176E23D.4080700@egenix.com> <5ADF30C8-22EA-11D9-B95B-000A95BA5446@redivi.com> <4176F017.9050804@egenix.com> <41776A96.8060903@egenix.com> <0914E9E5-24EE-11D9-AB1B-000A95C77748@mac.com> Message-ID: On 23-okt-04, at 15:31, Bob Ippolito wrote: > > On Oct 23, 2004, at 8:21, Ronald Oussoren wrote: > >> >> On 21-okt-04, at 14:50, Bob Ippolito wrote: >> >>> Well, I want users to be packagers as well. Not every Python module >>> is going to have a prebuilt .mpkg lying around, and using bdist_mpkg >>> to install modules has its advantages over a normal setup.py >>> install. The three big ones are: it goes into the installation >>> database so you can remove it, [...] >> >> How do you uninstall an installed package? I haven't found a system >> tool for that yet. > > There isn't one, but the capability is designed into the system. > There are 3rd party tools that do it. Basically you do a lsbom on the > receipt and remove what's listed. That should be save enough for installed python packages and some other 3th-party packages, but not in general. Some of Apple's packages replace files from other packages; you cannot see this in the BOM file and the original file is lost forever. Most, if not all, of these packages are updates/patches for installed software. Ronald From bob at redivi.com Sat Oct 23 18:09:06 2004 From: bob at redivi.com (Bob Ippolito) Date: Sat Oct 23 18:09:41 2004 Subject: [Distutils] Extending distutils with 3rd party build commands? In-Reply-To: References: <4176E23D.4080700@egenix.com> <5ADF30C8-22EA-11D9-B95B-000A95BA5446@redivi.com> <4176F017.9050804@egenix.com> <41776A96.8060903@egenix.com> <0914E9E5-24EE-11D9-AB1B-000A95C77748@mac.com> Message-ID: On Oct 23, 2004, at 11:40, Ronald Oussoren wrote: > > On 23-okt-04, at 15:31, Bob Ippolito wrote: > >> >> On Oct 23, 2004, at 8:21, Ronald Oussoren wrote: >> >>> >>> On 21-okt-04, at 14:50, Bob Ippolito wrote: >>> >>>> Well, I want users to be packagers as well. Not every Python >>>> module is going to have a prebuilt .mpkg lying around, and using >>>> bdist_mpkg to install modules has its advantages over a normal >>>> setup.py install. The three big ones are: it goes into the >>>> installation database so you can remove it, [...] >>> >>> How do you uninstall an installed package? I haven't found a system >>> tool for that yet. >> >> There isn't one, but the capability is designed into the system. >> There are 3rd party tools that do it. Basically you do a lsbom on >> the receipt and remove what's listed. > > That should be save enough for installed python packages and some > other 3th-party packages, but not in general. Some of Apple's packages > replace files from other packages; you cannot see this in the BOM file > and the original file is lost forever. Most, if not all, of these > packages are updates/patches for installed software. That's why I said "basically". In the general case, you would need to maintain a database that contained the contents of all receipts to determine such things, and state that certain changes couldn't be reverted... but that's not our job, we just need to use the installer system as documented, and that feature will happen when it happens. -bob From dairiki at dairiki.org Sat Oct 23 18:23:21 2004 From: dairiki at dairiki.org (Geoffrey T. Dairiki) Date: Sat Oct 23 18:23:25 2004 Subject: [Distutils] bdist_deb (was: Extending distutils with 3rd party build commands?) Message-ID: <1098548601.17693.14.camel@hairball.dairiki.org> On Fri Oct 22 00:42:47 CEST 2004 Mark W. Alexander wrote: > I'm chomping to do a bdist_deb, but sitting on my hands hoping someone > who can contribute it will do it first. I've got one that pretty-much works. I'd be happy to get rid of the last couple peculiarities that I know of and massage it into a patch on CVS as long as someone assures me that there's a decent chance the patch will be accepted. Best Regards, Jeff Dairiki From mal at egenix.com Sat Oct 23 19:32:53 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Oct 23 19:32:54 2004 Subject: [Distutils] Extending distutils with 3rd party build commands? In-Reply-To: <1CF19B7A-24F8-11D9-A658-000A95BA5446@redivi.com> References: <6A24A8C5-2476-11D9-B689-000A95BA5446@redivi.com> <0D191DF4-2479-11D9-B689-000A95BA5446@redivi.com> <200410222214.57639.fdrake@acm.org> <417A2266.8080502@egenix.com> <1CF19B7A-24F8-11D9-A658-000A95BA5446@redivi.com> Message-ID: <417A95C5.3090006@egenix.com> Bob Ippolito wrote: > > On Oct 23, 2004, at 5:20, M.-A. Lemburg wrote: > >> Fred L. Drake, Jr. wrote: >> >>> On Friday 22 October 2004 06:23 pm, Bob Ippolito wrote: >>> > I need an editable file in a system-wide directory such as >>> > site-packages that isn't "owned" by the Python installation. >> >> >> This already exists in the form of: >> >> """ >> There are three possible config files: distutils.cfg in the >> Distutils installation directory (ie. where the top-level >> Distutils __inst__.py file lives), a file in the user's home >> directory named .pydistutils.cfg on Unix and pydistutils.cfg >> on Windows/Mac, and setup.cfg in the current directory. >> """ > > None of those fit the bill. The distutils package is owned by the > Python installation, files in user directories or the current directory > are not system-wide. I don't know what you mean by "owned". If you'd rather have the distutils.cfg file live in /etc/ why not create it there and add a symbolic link to the Python site-packages dir ?! Note that Python itself will never ship with a distutils.cfg file. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From bob at redivi.com Sat Oct 23 19:45:22 2004 From: bob at redivi.com (Bob Ippolito) Date: Sat Oct 23 19:45:57 2004 Subject: [Distutils] Extending distutils with 3rd party build commands? In-Reply-To: <417A95C5.3090006@egenix.com> References: <6A24A8C5-2476-11D9-B689-000A95BA5446@redivi.com> <0D191DF4-2479-11D9-B689-000A95BA5446@redivi.com> <200410222214.57639.fdrake@acm.org> <417A2266.8080502@egenix.com> <1CF19B7A-24F8-11D9-A658-000A95BA5446@redivi.com> <417A95C5.3090006@egenix.com> Message-ID: <50040189-251B-11D9-8318-000A95BA5446@redivi.com> On Oct 23, 2004, at 13:32, M.-A. Lemburg wrote: > Bob Ippolito wrote: >> On Oct 23, 2004, at 5:20, M.-A. Lemburg wrote: >>> Fred L. Drake, Jr. wrote: >>> >>>> On Friday 22 October 2004 06:23 pm, Bob Ippolito wrote: >>>> > I need an editable file in a system-wide directory such as >>>> > site-packages that isn't "owned" by the Python installation. >>> >>> >>> This already exists in the form of: >>> >>> """ >>> There are three possible config files: distutils.cfg in the >>> Distutils installation directory (ie. where the top-level >>> Distutils __inst__.py file lives), a file in the user's home >>> directory named .pydistutils.cfg on Unix and pydistutils.cfg >>> on Windows/Mac, and setup.cfg in the current directory. >>> """ >> None of those fit the bill. The distutils package is owned by the >> Python installation, files in user directories or the current >> directory are not system-wide. > > I don't know what you mean by "owned". > > If you'd rather have > the distutils.cfg file live in /etc/ why not create it there > and add a symbolic link to the Python site-packages dir ?! Can't do that, distutils doesn't look in site-packages (this is the problem). > Note that Python itself will never ship with a distutils.cfg > file. I'd rather have the distutils.cfg file live in $prefix/lib/pythonX.X/site-packages than $prefix/anythingelse. This is not possible with the current version of distutils UNLESS distutils lives in site-packages, which is also not possible because site-packages comes after the standard library in sys.path. The only location in the Python installation tree that's explicitly marked for modification is site-packages, yet in this case another location is being used instead. This doesn't really make much sense, unless distutils is going to become separate from the standard library. distutils.cfg should be treated in the same way as sitecustomize.py (not expected to be distributed with Python, therefore sys.path is searched). -bob From ronaldoussoren at mac.com Sun Oct 24 11:27:18 2004 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Sun Oct 24 11:28:37 2004 Subject: [Distutils] Extending distutils with 3rd party build commands? In-Reply-To: <417A95C5.3090006@egenix.com> References: <6A24A8C5-2476-11D9-B689-000A95BA5446@redivi.com> <0D191DF4-2479-11D9-B689-000A95BA5446@redivi.com> <200410222214.57639.fdrake@acm.org> <417A2266.8080502@egenix.com> <1CF19B7A-24F8-11D9-A658-000A95BA5446@redivi.com> <417A95C5.3090006@egenix.com> Message-ID: On 23-okt-04, at 19:32, M.-A. Lemburg wrote: > Bob Ippolito wrote: >> On Oct 23, 2004, at 5:20, M.-A. Lemburg wrote: >>> Fred L. Drake, Jr. wrote: >>> >>>> On Friday 22 October 2004 06:23 pm, Bob Ippolito wrote: >>>> > I need an editable file in a system-wide directory such as >>>> > site-packages that isn't "owned" by the Python installation. >>> >>> >>> This already exists in the form of: >>> >>> """ >>> There are three possible config files: distutils.cfg in the >>> Distutils installation directory (ie. where the top-level >>> Distutils __inst__.py file lives), a file in the user's home >>> directory named .pydistutils.cfg on Unix and pydistutils.cfg >>> on Windows/Mac, and setup.cfg in the current directory. >>> """ >> None of those fit the bill. The distutils package is owned by the >> Python installation, files in user directories or the current >> directory are not system-wide. > > I don't know what you mean by "owned". He means that ${prefix} is in a part of the filesystem that is claimed by the OS vendor (Apple). Apple could wipe that part of the file system and recreate it when you install an OS patch. Apple has make special arrangements to move site-packages outside of "their" part of the filesystem: site-packages is in /Library/Python/2.3, which is "owned" by the system administrator. Ronald From Joanne3151 at aol.com Sun Oct 24 17:05:47 2004 From: Joanne3151 at aol.com (Joanne3151@aol.com) Date: Sun Oct 24 17:05:53 2004 Subject: [Distutils] Re: Mail Delivery (failure support@freeslide.com) Message-ID: <102.52b72f53.2ead1ecb@aol.com> Good Morning: I am very disappointed with your organization! I wrote to Geliva and they said that you people offered the free camera with the coffee program?????????? Does this organization do promotions and not follow up? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/distutils-sig/attachments/20041024/7e2b7b25/attachment.html From mal at egenix.com Mon Oct 25 10:46:01 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Oct 25 10:46:04 2004 Subject: [Distutils] Extending distutils with 3rd party build commands? In-Reply-To: References: <6A24A8C5-2476-11D9-B689-000A95BA5446@redivi.com> <0D191DF4-2479-11D9-B689-000A95BA5446@redivi.com> <200410222214.57639.fdrake@acm.org> <417A2266.8080502@egenix.com> <1CF19B7A-24F8-11D9-A658-000A95BA5446@redivi.com> <417A95C5.3090006@egenix.com> Message-ID: <417CBD49.8050502@egenix.com> Ronald Oussoren wrote: > > On 23-okt-04, at 19:32, M.-A. Lemburg wrote: > >> Bob Ippolito wrote: >> >>> On Oct 23, 2004, at 5:20, M.-A. Lemburg wrote: >>> >>>> Fred L. Drake, Jr. wrote: >>>> >>>>> On Friday 22 October 2004 06:23 pm, Bob Ippolito wrote: >>>>> > I need an editable file in a system-wide directory such as >>>>> > site-packages that isn't "owned" by the Python installation. >>>> >>>> >>>> >>>> This already exists in the form of: >>>> >>>> """ >>>> There are three possible config files: distutils.cfg in the >>>> Distutils installation directory (ie. where the top-level >>>> Distutils __inst__.py file lives), a file in the user's home >>>> directory named .pydistutils.cfg on Unix and pydistutils.cfg >>>> on Windows/Mac, and setup.cfg in the current directory. >>>> """ >>> >>> None of those fit the bill. The distutils package is owned by the >>> Python installation, files in user directories or the current >>> directory are not system-wide. >> >> >> I don't know what you mean by "owned". > > > He means that ${prefix} is in a part of the filesystem that is claimed > by the OS vendor (Apple). Apple could wipe that part of the file system > and recreate it when you install an OS patch. > > Apple has make special arrangements to move site-packages outside of > "their" part of the filesystem: site-packages is in /Library/Python/2.3, > which is "owned" by the system administrator. Thanks for the explanation. This makes things a lot easier to understand :-) Perhaps we should make the site-packages dir a standard place for site-wide Python configuration files ?! (the current scheme for distutils.cfg is more than odd, IMHO) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 25 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Oct 25 10:47:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Oct 25 10:47:43 2004 Subject: [Distutils] bdist_deb (was: Extending distutils with 3rd party build commands?) In-Reply-To: <1098548601.17693.14.camel@hairball.dairiki.org> References: <1098548601.17693.14.camel@hairball.dairiki.org> Message-ID: <417CBDAD.9050505@egenix.com> Geoffrey T. Dairiki wrote: > On Fri Oct 22 00:42:47 CEST 2004 Mark W. Alexander wrote: > >>I'm chomping to do a bdist_deb, but sitting on my hands hoping someone >>who can contribute it will do it first. > > > I've got one that pretty-much works. I'd be happy to get rid > of the last couple peculiarities that I know of and massage > it into a patch on CVS as long as someone assures me that > there's a decent chance the patch will be accepted. That would be great. The only thing to remember is that the patch will have to be Python 2.1 compatible. Do we have Debian folks in the Python-Dev team that could review the patch from a Debian point of view ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 25 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Alexandre.Fayolle at logilab.fr Mon Oct 25 13:23:33 2004 From: Alexandre.Fayolle at logilab.fr (Alexandre) Date: Mon Oct 25 13:23:40 2004 Subject: [Distutils] bdist_deb (was: Extending distutils with 3rd party build commands?) In-Reply-To: <417CBDAD.9050505@egenix.com> References: <1098548601.17693.14.camel@hairball.dairiki.org> <417CBDAD.9050505@egenix.com> Message-ID: <20041025112333.GC14871@crater.logilab.fr> On Mon, Oct 25, 2004 at 10:47:41AM +0200, M.-A. Lemburg wrote: > Geoffrey T. Dairiki wrote: > >On Fri Oct 22 00:42:47 CEST 2004 Mark W. Alexander wrote: > > > >>I'm chomping to do a bdist_deb, but sitting on my hands hoping someone > >>who can contribute it will do it first. > > > > > >I've got one that pretty-much works. I'd be happy to get rid > >of the last couple peculiarities that I know of and massage > >it into a patch on CVS as long as someone assures me that > >there's a decent chance the patch will be accepted. > > That would be great. > > The only thing to remember is that the patch will have > to be Python 2.1 compatible. > > Do we have Debian folks in the Python-Dev team that could > review the patch from a Debian point of view ? If nobody else is available I can do that, but I'm not part of python-dev, and have a very busy schedule during the next two weeks. You may want to ask some feedback on debian-python@debian.org too. -- Alexandre Fayolle LOGILAB, Paris (France). http://www.logilab.com http://www.logilab.fr http://www.logilab.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://mail.python.org/pipermail/distutils-sig/attachments/20041025/50996985/attachment.pgp From ressl at geocities.com Mon Oct 25 14:44:00 2004 From: ressl at geocities.com (ressl@geocities.com) Date: Mon Oct 25 14:44:03 2004 Subject: [Distutils] Yahoo! Auto Response Message-ID: <20041025124402.06AEE1E4002@bag.python.org> A non-text attachment was scrubbed... Name: not available Type: text Size: 1533 bytes Desc: not available Url : http://mail.python.org/pipermail/distutils-sig/attachments/20041025/19083dce/attachment.ksh From dairiki at gmail.com Mon Oct 25 17:03:37 2004 From: dairiki at gmail.com (Jeff Dairiki) Date: Mon Oct 25 17:03:39 2004 Subject: [Distutils] bdist_deb (was: Extending distutils with 3rd party build commands?) In-Reply-To: <417CBDAD.9050505@egenix.com> References: <1098548601.17693.14.camel@hairball.dairiki.org> <417CBDAD.9050505@egenix.com> Message-ID: <4063f01204102508035ea127c5@mail.gmail.com> Marc-Andre wrote: > The only thing to remember is that the patch will have > to be Python 2.1 compatible. Comments in the source code for, e.g. bdist_rpm suggest that things should remain compatible with Python 1.5. Is that right, or is 1.5 no longer supported? Alexandre wrote: > You may want to ask some feedback on debian-python@debian.org too. Okay. I'll get the patch together and posted (hopefully by sometime tomorrow), so that it's available for perusal, then I'll post a note on debian-python. I've been pretty careful about reading and obeying debian-policy and python-policy, and have been running the bdist_deb generated packages through lintian for testing. Thanks for the comments! Jeff From symbiont at berlios.de Mon Oct 25 17:25:49 2004 From: symbiont at berlios.de (Jeff Pitman) Date: Mon Oct 25 17:25:58 2004 Subject: [Distutils] bdist_deb (was: Extending distutils with 3rd party build commands?) In-Reply-To: <4063f01204102508035ea127c5@mail.gmail.com> References: <1098548601.17693.14.camel@hairball.dairiki.org> <417CBDAD.9050505@egenix.com> <4063f01204102508035ea127c5@mail.gmail.com> Message-ID: <200410252325.49949.symbiont@berlios.de> On Monday 25 October 2004 23:03, Jeff Dairiki wrote: > Marc-Andre wrote: > > The only thing to remember is that the patch will have > > to be Python 2.1 compatible. > > Comments in the source code for, e.g. bdist_rpm suggest that things > should remain compatible with Python 1.5. ?Is that right, or is > 1.5 no longer supported? http://mail.python.org/pipermail/distutils-sig/2004-September/004168.html -- -jeff From jafo at tummy.com Tue Oct 26 03:23:04 2004 From: jafo at tummy.com (Sean Reifschneider) Date: Tue Oct 26 03:23:11 2004 Subject: [Distutils] bdist_deb (was: Extending distutils with 3rd party build commands?) In-Reply-To: <417CBDAD.9050505@egenix.com> References: <1098548601.17693.14.camel@hairball.dairiki.org> <417CBDAD.9050505@egenix.com> Message-ID: <20041026012304.GA30638@tummy.com> On Mon, Oct 25, 2004 at 10:47:41AM +0200, M.-A. Lemburg wrote: >Do we have Debian folks in the Python-Dev team that could >review the patch from a Debian point of view ? I can look at it. Please copy me directly on the patch and/or put it in the Python sourceforge tracker assigned to me, I only check this list infrequently. Thanks, Sean -- Thieves broke into Scotland Yard yesterday and stole all the toilets. Detectives say they have nothing to go on. Sean Reifschneider, Member of Technical Staff tummy.com, ltd. - Linux Consulting since 1995. Qmail, Python, SysAdmin From slash at dotnetslash.net Tue Oct 26 04:45:44 2004 From: slash at dotnetslash.net (Mark W. Alexander) Date: Tue Oct 26 04:45:47 2004 Subject: [Distutils] bdist_deb (was: Extending distutils with 3rd party build commands?) In-Reply-To: <20041026012304.GA30638@tummy.com> References: <1098548601.17693.14.camel@hairball.dairiki.org> <417CBDAD.9050505@egenix.com> <20041026012304.GA30638@tummy.com> Message-ID: <20041026024544.GE17849@dotnetslash.net> On Mon, Oct 25, 2004 at 07:23:04PM -0600, Sean Reifschneider wrote: > On Mon, Oct 25, 2004 at 10:47:41AM +0200, M.-A. Lemburg wrote: > >Do we have Debian folks in the Python-Dev team that could > >review the patch from a Debian point of view ? > > I can look at it. Please copy me directly on the patch and/or put it in > the Python sourceforge tracker assigned to me, I only check this list > infrequently. Put it in the tracker and I'll steal^W take a look too. I take it you're looking for Debian Policy conformance, or is something else concerning you? If the former, I believe that's only a concern for "official" packages, although the closer you get the better. mwa -- Mark W. Alexander slash@dotnetslash.net The contents of this message authored by Mark W. Alexander are released under the Creative Commons Attribution-NonCommercial license. Copyright of quoted materials, if any, are retained by the original author(s). http://creativecommons.org/licenses/by-nc/2.0/ From mal at egenix.com Tue Oct 26 09:38:58 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Oct 26 09:38:54 2004 Subject: [Distutils] bdist_deb (was: Extending distutils with 3rd party build commands?) In-Reply-To: <20041026024544.GE17849@dotnetslash.net> References: <1098548601.17693.14.camel@hairball.dairiki.org> <417CBDAD.9050505@egenix.com> <20041026012304.GA30638@tummy.com> <20041026024544.GE17849@dotnetslash.net> Message-ID: <417DFF12.5020108@egenix.com> Mark W. Alexander wrote: > On Mon, Oct 25, 2004 at 07:23:04PM -0600, Sean Reifschneider wrote: > >>On Mon, Oct 25, 2004 at 10:47:41AM +0200, M.-A. Lemburg wrote: >> >>>Do we have Debian folks in the Python-Dev team that could >>>review the patch from a Debian point of view ? >> >>I can look at it. Please copy me directly on the patch and/or put it in >>the Python sourceforge tracker assigned to me, I only check this list >>infrequently. > > > Put it in the tracker and I'll steal^W take a look too. I take it you're > looking for Debian Policy conformance, or is something else concerning > you? If the former, I believe that's only a concern for "official" > packages, although the closer you get the better. I don't "live" in the Debian space, but since every community has its standards I would just like to see the generated Debian packages conform to these standards. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 26 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From dairiki at dairiki.org Wed Oct 27 02:57:27 2004 From: dairiki at dairiki.org (Geoffrey T. Dairiki) Date: Wed Oct 27 02:57:37 2004 Subject: [Distutils] bdist_deb patches In-Reply-To: <417DFF12.5020108@egenix.com> References: <1098548601.17693.14.camel@hairball.dairiki.org> <417CBDAD.9050505@egenix.com> <20041026012304.GA30638@tummy.com> <20041026024544.GE17849@dotnetslash.net> <417DFF12.5020108@egenix.com> Message-ID: <1098838647.17693.25.camel@hairball.dairiki.org> Marc-Andre, Mark, Sean, I've posted my bdist_deb patches to the SF tracker: http://sourceforge.net/tracker/index.php?func=detail&aid=1054967&group_id=5470&atid=305470 There's a slightly detailed README.bdist_deb included within the patch. I'm open to all comments. Thanks for taking a look! Jeff Dairiki From jafo at tummy.com Wed Oct 27 05:48:52 2004 From: jafo at tummy.com (Sean Reifschneider) Date: Wed Oct 27 05:49:00 2004 Subject: [Distutils] Re: bdist_deb patches In-Reply-To: <1098838647.17693.25.camel@hairball.dairiki.org> References: <1098548601.17693.14.camel@hairball.dairiki.org> <417CBDAD.9050505@egenix.com> <20041026012304.GA30638@tummy.com> <20041026024544.GE17849@dotnetslash.net> <417DFF12.5020108@egenix.com> <1098838647.17693.25.camel@hairball.dairiki.org> Message-ID: <20041027034852.GD4826@tummy.com> I'm just doing a review of this code. A couple of things: There's been some concern expressed about get_default_maintainer. Namely, that if debchange changes it's algorithm, it won't be reflected in this code. It seems like one possible way around that would be to build a directory with a "debian" directory under it, a fake "changelog", and then call debchange to write the data out, and parse it. Too bad there's not a direct hook into debchange to get that information. Can _formatdate, if email doesn't exist, use rfc822.formatdate()? Ditto for _parseaddr? It looks pretty good. However, when trying to build a .deb of my jotweb2 package, it's failing with: [...] dh_testdir dh_testroot dh_installchangelogs dh_installdocs cp: cannot stat `doc': No such file or directory dh_installdocs: command returned error code 256 [...] I'm not sure exactly why. I do have a "doc" directory in my main package directory, but I don't reference to it in my setup.py or MANIFEST. Adding it to the MANIFEST doesn't seem to help this. You can try picking up the jotweb code from ftp.tummy.com:/pub/tummy/jotweb/ and pick up the 1.05 tar file. Sean -- Put out fires during the daytime. Do your real work at night. Sleep is just an addiction. -- Dieter Muller Sean Reifschneider, Member of Technical Staff tummy.com, ltd. - Linux Consulting since 1995. Qmail, Python, SysAdmin From mal at egenix.com Wed Oct 27 10:26:43 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Oct 27 10:26:46 2004 Subject: [Distutils] bdist_deb patches In-Reply-To: <1098838647.17693.25.camel@hairball.dairiki.org> References: <1098548601.17693.14.camel@hairball.dairiki.org> <417CBDAD.9050505@egenix.com> <20041026012304.GA30638@tummy.com> <20041026024544.GE17849@dotnetslash.net> <417DFF12.5020108@egenix.com> <1098838647.17693.25.camel@hairball.dairiki.org> Message-ID: <417F5BC3.3070608@egenix.com> Geoffrey T. Dairiki wrote: > Marc-Andre, Mark, Sean, > > I've posted my bdist_deb patches to the SF tracker: > > http://sourceforge.net/tracker/index.php?func=detail&aid=1054967&group_id=5470&atid=305470 > > There's a slightly detailed README.bdist_deb included within the patch. > > I'm open to all comments. Thanks for taking a look! I think you should rename the "debianize" command to something like "bdist_deb_prepare" or the like. Maybe even make it a bdist_deb subcommand. The reason is that this command is likely only going to be used together with bdist_deb unless I misunderstood its purpose. Perhaps we need a new class of commands like "aux_deb", "aux_rpm", etc. that add auxiliary directories and files to a package ?! -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Oct 27 12:25:54 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Oct 27 12:25:58 2004 Subject: [Distutils] SourceForge.net: Project Info - Windows Installer XML (WiX) toolset Message-ID: <417F77B2.1070507@egenix.com> Just came across this (first MS OSS) project which allows building MSI packages from XML package descriptions: This sounds like a good tool to use as basis for a bdist_msi. FWIW, this project does the other direction: MSI -> XML http://msi2xml.sourceforge.net/ -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From dairiki at dairiki.org Wed Oct 27 19:50:42 2004 From: dairiki at dairiki.org (Geoffrey T. Dairiki) Date: Wed Oct 27 19:50:49 2004 Subject: [Distutils] Re: bdist_deb patches In-Reply-To: <20041027034852.GD4826@tummy.com> References: <1098548601.17693.14.camel@hairball.dairiki.org> <417CBDAD.9050505@egenix.com> <20041026012304.GA30638@tummy.com> <20041026024544.GE17849@dotnetslash.net> <417DFF12.5020108@egenix.com> <1098838647.17693.25.camel@hairball.dairiki.org> <20041027034852.GD4826@tummy.com> Message-ID: <1098899442.17693.98.camel@hairball.dairiki.org> Thanks for the comments, Sean. On Tue, 2004-10-26 at 20:48, Sean Reifschneider wrote: > There's been some concern expressed about get_default_maintainer. > Namely, that if debchange changes it's algorithm, it won't be > reflected in this code. It seems like one possible way around that > would be to build a directory with a "debian" directory under it, a > fake "changelog", and then call debchange to write the data out, and > parse it. That seems like a lot of work. Is it really worth it? A (similar) alternative would be to use debchange to generate the real debian/changelog. Since debchange fails to work unless there's already a non-empty changelog, that entails creating an initial changelog with a dummy entry, running debchange, and then cleaning up the dummy entry --- also kind of messy. > Can _formatdate, if email doesn't exist, use rfc822.formatdate()? rfc822.formatdate is broken in my (Debian's) python2.1 and python2.2 in that it uses strftime (and thus day and month names might come out in a language other than English). Also they do not include a numeric timezone designation. (They use 'GMT' rather than '-0000'). Debian policy specifies that the zone designation "should be" numeric. I'm not sure whether it causes problems if it's not, but I suspect it might. (I've just noticed that dpkg-dev includes an '822-date' program, which could be used in lieu of formatdate, I guess.) > Ditto for _parseaddr? Yes, rfc822.parseaddr will work. Though now you've prompted me to take a look at how debchange parses email addresses, and it's considerably dumber than either rfc822.parseaddr or email.Utils.parseaddr. To wit: ... $env{'DEBEMAIL'} =~ /^(.*)\s+<(.*)>$/ ... Using debchange to generate the changelog entry would eliminate the need for parseaddr and formatdate altogether, so perhaps that is the best way to go. Comments? > ... when trying to build a .deb of my > jotweb2 package, it's failing with: > > [...] > dh_installdocs > cp: cannot stat `doc': No such file or directory > dh_installdocs: command returned error code 256 > [...] > > I'm not sure exactly why. I do have a "doc" directory in my main > package directory, but I don't reference to it in my setup.py or > MANIFEST. Adding it to the MANIFEST doesn't seem to help this. It looks like you don't use sdist to build your source distribution, since it includes files which aren't in the MANIFEST. (What's happening is that bdist_deb sees the 'doc' directory and adds it to the default value for it's --doc-files option, but the sdist command doesn't include the doc subdirectory in the source distribution. You would have to add at least one file from the doc subdirectory to MANIFEST to fix this, I think. A better solution might be to add 'graft doc' to MANIFEST.in. You could also, of course, explicitly set the --doc-files option, e.g. 'python setup.py bdist_deb --doc-files=README'.) Overnight, I've come to believe that bdist_deb is being overly aggressive about guessing default values for --doc-files. I guess, at the least, that I need to make sure the assumed doc files are in fact present in the source distribution. (At one point, I did try using sdist --manifest-only to generate a MANIFEST, then picking doc-files out of the MANIFEST, however this bug was causing problems with that:) http://sourceforge.net/tracker/index.php?func=detail&aid=1052827&group_id=5470&atid=105470 As far as I can tell, README and README.txt are the only doc-type files that distutils treats specially. (They automatically get added to the MANIFEST.) Are there any PEPs or other standards which suggest other standard names for doc files? Currently, to compute the default value for --doc-files, bdist_deb looks for the following files or directories: README, README.txt, CHANGES, CHANGES.txt, NEWS, NEWS.txt, CREDITS, COPYING, AUTHORS, changelog, ChangeLog, and doc After sleeping on it, my current thinking is to drop 'doc' from the list, and only look for files (not directories). After seeing jotweb2, I'm think of adding 'LICENSE' and 'LICENCE' to the list. Comments? (This turned out to be rather a longer reply than I intended. Thanks for sticking it out to the end.) Jeff From dairiki at dairiki.org Wed Oct 27 20:22:56 2004 From: dairiki at dairiki.org (Geoffrey T. Dairiki) Date: Wed Oct 27 20:23:00 2004 Subject: [Distutils] bdist_deb patches In-Reply-To: <417F5BC3.3070608@egenix.com> References: <1098548601.17693.14.camel@hairball.dairiki.org> <417CBDAD.9050505@egenix.com> <20041026012304.GA30638@tummy.com> <20041026024544.GE17849@dotnetslash.net> <417DFF12.5020108@egenix.com> <1098838647.17693.25.camel@hairball.dairiki.org> <417F5BC3.3070608@egenix.com> Message-ID: <1098901376.17693.129.camel@hairball.dairiki.org> On Wed, 2004-10-27 at 01:26, M.-A. Lemburg wrote: > I think you should rename the "debianize" command to something > like "bdist_deb_prepare" or the like. Maybe even make it a > bdist_deb subcommand. What if I rename 'debianize' to 'dh_make'? That should look attractive only to Debian hackers --- and should instantly convey the commands purpose to them as well. > The reason is that this command is likely only going to be > used together with bdist_deb unless I misunderstood its > purpose. The 'debianize' command is intended to be used _instead_ of bdist_deb. I see two separate classes of debian packers: 1. Those who just want a binary package, so that they can install it on their Debian machines, taking advantage of Debian's package control. This is the target audience for bdist_deb. 2. Those (either the package author/maintainer himself or a downstream Debian packager) who want to package the python package for inclusion in a/the Debian package repository. It will be tricky for a bdist_deb-like distutils command to make these people happy. Older entries in the debian/changelog need to be maintained (this could be arranged somehow, I guess). But also, it is likely that any automatically-generated set of debian/ files is going to need to be hand-tweaked a bit. The 'debianize' command is intended for this case. It is intended that it be run only once. Thereafter the debian subdirectory is maintained, either as part of the source distribution, or as part of the Debian source package. It is intended that after running 'debianize' (and probably hand-editing the results) the Debian packages are build the Debian way (e.g. using debuild.) Clear? Jeff From trentm at activestate.com Wed Oct 27 21:03:07 2004 From: trentm at activestate.com (Trent Mick) Date: Wed Oct 27 21:09:31 2004 Subject: [Distutils] SourceForge.net: Project Info - Windows Installer XML (WiX) toolset In-Reply-To: <417F77B2.1070507@egenix.com> References: <417F77B2.1070507@egenix.com> Message-ID: <417FF0EB.4030902@activestate.com> M.-A. Lemburg wrote: > Just came across this (first MS OSS) project which allows > building MSI packages from XML package descriptions: > > > > This sounds like a good tool to use as basis for a bdist_msi. > > FWIW, this project does the other direction: MSI -> XML > > http://msi2xml.sourceforge.net/ > WiX will do MSI->XML as well. Trent -- Trent Mick trentm@activestate.com From mal at egenix.com Wed Oct 27 21:54:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Oct 27 21:54:52 2004 Subject: [Distutils] SourceForge.net: Project Info - Windows Installer XML (WiX) toolset In-Reply-To: <417FF0EB.4030902@activestate.com> References: <417F77B2.1070507@egenix.com> <417FF0EB.4030902@activestate.com> Message-ID: <417FFD08.5050906@egenix.com> Trent Mick wrote: > M.-A. Lemburg wrote: > >> Just came across this (first MS OSS) project which allows >> building MSI packages from XML package descriptions: >> >> >> >> This sounds like a good tool to use as basis for a bdist_msi. >> >> FWIW, this project does the other direction: MSI -> XML >> >> http://msi2xml.sourceforge.net/ >> > > WiX will do MSI->XML as well. Looking more closely at the msi2xml project page it seems to do XML -> MSI direction as well. Trent, do you have experience with one of them ? Which is more usable ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From trentm at activestate.com Thu Oct 28 01:43:04 2004 From: trentm at activestate.com (Trent Mick) Date: Thu Oct 28 02:09:36 2004 Subject: [Distutils] SourceForge.net: Project Info - Windows Installer XML (WiX) toolset In-Reply-To: <417FFD08.5050906@egenix.com> References: <417F77B2.1070507@egenix.com> <417FF0EB.4030902@activestate.com> <417FFD08.5050906@egenix.com> Message-ID: <41803288.1040804@activestate.com> M.-A. Lemburg wrote: > Looking more closely at the msi2xml project page it seems > to do XML -> MSI direction as well. > > Trent, do you have experience with one of them ? Which is > more usable ? WiX was built and is maintained by Microsoft guys (mainly Robert Menching) and is, they say, heavily used inside Microsoft for putting there installer packages together. I've played a little bit with WiX and probably intend to use it for ActivePython (and other installers I author at work) eventually but haven't started really using it yet. I'm pretty confident that WiX is a good way to go. I haven't used msi2xml at all so I can't compare them technically, but the Microsoft usage stories makes me more confident in WiX. A quick look at the msi2xml XML schema gives me the impression that msi2xml would feel a lot more raw where as WiX attempts to put a slight nicer face on the authoring of the database tables that make up an MSI package -- for better or worse. (ASIDE: MySQL is now using WiX for their installers.) WiX blog: http://blogs.msdn.com/robmen/category/4625.aspx Rob's personal blog: http://blogs.msdn.com/robmen/ Cheers, Trent -- Trent Mick trentm@activestate.com From Ferg.Stephen at bls.gov Thu Oct 28 18:14:28 2004 From: Ferg.Stephen at bls.gov (Ferg, Stephen - BLS) Date: Thu Oct 28 18:14:36 2004 Subject: [Distutils] printable docs on distutils? Message-ID: Is there some printable documentation on distutils? I'd like to print off some paper documentation on distutils, installing modules using distutils, etc. I'm looking for, say, a PDF file. I don't especially want to go flipping through the HTML pages, printing them off one at a time. -- Steve Stephen Ferg ferg_s@bls.gov 202-691-7257
Bureau of Labor Statistics, Room 5110 2 Mass. Ave. NE Washington, DC 20212-0001 USA
From fdrake at acm.org Thu Oct 28 18:32:57 2004 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Thu Oct 28 18:33:06 2004 Subject: [Distutils] printable docs on distutils? In-Reply-To: References: Message-ID: <200410281232.57955.fdrake@acm.org> On Thursday 28 October 2004 12:14 pm, Ferg, Stephen - BLS wrote: > Is there some printable documentation on distutils? Yes. The two manuals included in the online documentation are also available in the typeset versions of the documentation. You can find this at http://docs.python.org/download.html -Fred -- Fred L. Drake, Jr. From calvin at users.sourceforge.net Thu Oct 28 18:40:20 2004 From: calvin at users.sourceforge.net (Bastian Kleineidam) Date: Thu Oct 28 18:40:30 2004 Subject: [Distutils] printable docs on distutils? In-Reply-To: References: Message-ID: <20041028164020.GA18995@treasure> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, at http://docs.python.org/download.html you'll find PDF and Postscript formats of the Python documentation. Hope this helps, Bastian On Thu, Oct 28, 2004 at 12:14:28PM -0400, Ferg, Stephen - BLS wrote: > Is there some printable documentation on distutils? > > I'd like to print off some paper documentation on distutils, installing > modules using distutils, etc. I'm looking for, say, a PDF file. I don't > especially want to go flipping through the HTML pages, printing them off one > at a time. - -- ,''`. Bastian Kleineidam . calvin (at) debian.org : :' : `. `' GnuPG Schl?ssel http://kampfwurst.net/gpgkey.txt `- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBgSD0eBwlBDLsbz4RAg20AJkBdkj8IzMXO1m+L9zLGkZU4I7RLQCeP3q3 oy94jXz8CPC2pbmverRxQrw= =KKv5 -----END PGP SIGNATURE----- From dairiki at dairiki.org Fri Oct 29 22:02:33 2004 From: dairiki at dairiki.org (Geoffrey T. Dairiki) Date: Fri Oct 29 22:02:39 2004 Subject: [Distutils] Re: bdist_deb patches In-Reply-To: <1098899442.17693.98.camel@hairball.dairiki.org> References: <1098548601.17693.14.camel@hairball.dairiki.org> <417CBDAD.9050505@egenix.com> <20041026012304.GA30638@tummy.com> <20041026024544.GE17849@dotnetslash.net> <417DFF12.5020108@egenix.com> <1098838647.17693.25.camel@hairball.dairiki.org> <20041027034852.GD4826@tummy.com> <1098899442.17693.98.camel@hairball.dairiki.org> Message-ID: <1099080153.17693.154.camel@hairball.dairiki.org> Thanks to all for their comments. I've got a second attempt at a bdist_deb ready. If put a new set of patches up at: http://sourceforge.net/tracker/index.php?func=detail&aid=1054967&group_id=5470&atid=305470 I've renamed the 'debianize' command to 'dh_make', added a better test script, and it now work on woody. A more detailed changelog is included in README.bdist_deb which is included within the patch set. As always, comments would be appreciated. Jeff From calvin at users.sourceforge.net Mon Oct 25 12:15:41 2004 From: calvin at users.sourceforge.net (Bastian Kleineidam) Date: Thu Nov 4 15:31:09 2004 Subject: [Distutils] bdist_deb (was: Extending distutils with 3rd party build commands?) In-Reply-To: <417CBDAD.9050505@egenix.com> References: <1098548601.17693.14.camel@hairball.dairiki.org> <417CBDAD.9050505@egenix.com> Message-ID: <20041025101540.GA14892@treasure> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, On Mon, Oct 25, 2004 at 10:47:41AM +0200, M.-A. Lemburg wrote: > Do we have Debian folks in the Python-Dev team that could > review the patch from a Debian point of view ? I could review it. Is the patch available somewhere? Regards, Bastian - -- ,''`. Bastian Kleineidam . calvin (at) debian.org : :' : `. `' GnuPG Schl?ssel http://kampfwurst.net/gpgkey.txt `- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBfNJMeBwlBDLsbz4RAreEAKCq+F8BdLP1jUEt3sRXg55qxlOi+gCeMVn3 mpoOBDWf2NA7ynXteLtPL3E= =dw3Q -----END PGP SIGNATURE-----