From cwteoh at tm.net.my Tue Sep 2 20:50:09 2003 From: cwteoh at tm.net.my (PAUL YOUNG) Date: Tue Sep 2 07:59:25 2003 Subject: [Distutils] you r sending this on purpose or your pc got virus? please scan your pc References: <0HKJ00GZCJFN72@imta2.tm.net.my> Message-ID: <013d01c37149$7fdd80c0$0300000a@homerpcpoxxbh6> ----- Original Message ----- From: To: Sent: Monday, September 01, 2003 11:09 PM Subject: Re: Re: My details > See the attached file for details > From r.hogendoorn at hitt.nl Fri Sep 5 15:10:53 2003 From: r.hogendoorn at hitt.nl (Hogendoorn, Rene) Date: Fri Sep 5 08:12:15 2003 Subject: [Distutils] Compiling C++ extensions with python2.3 distutils/mingw32 fails Message-ID: <8C6ADF4772B7D511A3E40008C7BB878A0167A7C3@chopin.hitt.nl> The distutils, distributed with python 2.3, try to recognize the language (c or c++) and set the linker executable as appropriate. With cygwin and mingw32, the resulting linker is 'cc.exe', because the CygwinCompiler class fails to provide a definition for compiler_cxx. A solution is to patch the call to self.set_executables: # Hard-code GCC because that's what this is all about. # XXX optimization, warnings etc. should be customizable. self.set_executables(compiler='gcc -mcygwin -O -Wall', compiler_so='gcc -mcygwin -mdll -O -Wall', compiler_cxx='g++ -mcygwin -O -Wall', <========== linker_exe='gcc -mcygwin', linker_so=('%s -mcygwin %s' % (self.linker_dll, shared_option))) Regards, Ren? Hogendoorn -- HITT Traffic Oude Apeldoornseweg 41-45 P.O. Box 717 NL-7300 AS, APELDOORN The Netherlands Telephone +31-55-543 2559 Mobile +31-610 925 412 Fax +31-55-543 2553 E-mail r.hogendoorn@hitt.nl From seefeld at sympatico.ca Wed Sep 10 12:59:18 2003 From: seefeld at sympatico.ca (Stefan Seefeld) Date: Wed Sep 10 11:58:48 2003 Subject: [Distutils] installation paths when using 'bdist_wininst' Message-ID: <4b1cd5072d43de388aa7675f9c4a72ba3f5f4838@Orthosoft.ca> hi there, I'm trying to package a tool that uses some data files. As the 'install_data' command is used to install these files. As the exact location of these data files is only known at installation time, I extended that command to generate a 'config.py' module containing the correct path which the other modules then can use to find the data. This approach is quite common with build systems based on make/autoconf, so I'm adopting it to a python project, too. That seems to work fine when I run 'python setup.py install'. However, I just tried the 'bdist_wininst' command and it stops working: it appears the 'bdist_wininst' calls the 'install' command with the 'install_data' argument set to a temporary path, i.e. one that is only used during the packaging, but which is not the ultimate location of the data files after installation via the windows installer. This brings up a couple of questions: * how does the windows installer determine where to install the package's files ? * how can I generate my 'config.py' file such that it correctly points to that location ? * are there other ways to find out this location ? Thanks for any help, Stefan From hoel at gl-group.com Thu Sep 11 12:39:06 2003 From: hoel at gl-group.com (=?iso-8859-15?Q?Berthold_H=F6llmann?=) Date: Thu Sep 11 05:39:12 2003 Subject: [Distutils] Hack for runtime_library_dir_option Message-ID: Hello, Using scipy distutils under Solaris I stumbled over a problem in distutils unixccompiler. In runtime_library_dir_option the C compiler name is used to determine whether to a use "-Wl,-R" or "-R". I use the Sun Fortran compiler together with gcc. Now when linking an extension module that uses "runtime_library_dirs" and the fortran compiler for linking I get an error message because of the usage of "-Wl.-R" instead of "-R". I rewrote the routine a little bit: def runtime_library_dir_option(self, dir): # XXX Hackish, at the very least. See Python bug #445902: # http://sourceforge.net/tracker/index.php # ?func=detail&aid=445902&group_id=5470&atid=105470 # Linkers on different platforms need different options to # specify that directories need to be added to the list of # directories searched for dependencies when a dynamic library # is sought. GCC has to be told to pass the -R option through # to the linker, whereas other compilers just know this. # Other compilers may need something slightly different. At # this time, there's no way to determine this information from # the configuration data stored in the Python installation, so # we use this hack. linker = self.linker_so if sys.platform[:6] == "darwin": # MacOSX's linker doesn't understand the -R flag at all return "-L" + dir elif sys.platform[:5] == "hp-ux": return "+s -L" + dir elif linker[:3] == "gcc" or linker[:3] == "g++" or linker[:3] == "g77": return "-Wl,-R" + dir else: return "-R" + dir and now it works for me. Shall I issue a but report on this or is my usage to exotic? Kind regards Berthold H?llmann -- Germanischer Lloyd AG CAE Development Vorsetzen 35 20459 Hamburg Phone: +49(0)40 36149-7374 Fax: +49(0)40 36149-7320 e-mail: hoel@gl-group.com Internet: http://www.gl-group.com **************************************************** Please notice: We would like to inform you that the e-mail address of Germanischer Lloyd as well as our internet address had been changed to gl-group.com with effect from 1st March 2003. This means that the previous address shortmark@germanlloyd.org will be replaced by shortmark@gl-group.com. From now on the GL homepage can be accessed at the address 'http://www.gl-group.com'. The old addresses remain valid for a transitional period. **************************************************** This e-mail contains confidential information for the exclusive attention of the intended addressee. Any access of third parties to this e-mail is unauthorised. Any use of this e-mail by unintended recipients such as copying, distribution, disclosure etc. is prohibited and may be unlawful. When addressed to our clients the content of this e-mail is subject to the General Terms and Conditions of GL's Group of Companies applicable at the date of this e-mail. GL's Group of Companies does not warrant and/or guarantee that this message at the moment of receipt is authentic, correct and its communication free of errors, interruption etc. From judson at mcs.anl.gov Thu Sep 11 12:12:21 2003 From: judson at mcs.anl.gov (Ivan R. Judson) Date: Thu Sep 11 12:12:32 2003 Subject: [Distutils] Automated, or non-gui installer? Message-ID: <008801c3787f$7b693ce0$7612dd8c@mcs.anl.gov> If I wanted to install a bunch of python modules as part of a bigger package, could I build python modules installers with distutils that would not need user input or create windows? --Ivan From pete at shinners.org Thu Sep 11 23:36:05 2003 From: pete at shinners.org (Pete Shinners) Date: Fri Sep 12 01:50:34 2003 Subject: [Distutils] Re: Automated, or non-gui installer? In-Reply-To: <008801c3787f$7b693ce0$7612dd8c@mcs.anl.gov> References: <008801c3787f$7b693ce0$7612dd8c@mcs.anl.gov> Message-ID: Ivan R. Judson wrote: > If I wanted to install a bunch of python modules as part of a bigger > package, could I build python modules installers with distutils that would > not need user input or create windows? distutils can create zip files, which can be easily installed. although you may want to check the zipfile it creates. i remember long ago the files in the zip would have strange absolute paths, making it hard to unzip them anywhere specific. From seefeld at sympatico.ca Wed Sep 17 10:00:02 2003 From: seefeld at sympatico.ca (Stefan Seefeld) Date: Wed Sep 17 10:00:18 2003 Subject: [Distutils] more clashes between 'build' and 'bdist_wininst' Message-ID: <4313b411a412fb451ebc6cfcab9832423f6865df@Orthosoft.ca> hi there, I'v run into a new problem using the 'bdist_wininst' command: the 'build_scripts' command inspects the first line of my scripts, and, if it finds 'python' there, replaces it with the python command used during the build. If for example my script's first line reads '#! /usr/bin/env python', and if I use '/usr/local/bin/python' during compilation, the first line of my script will be replaced yielding '#! /usr/local/bin/python'. That works find as long as the final interpreter coincides with the one used for building. When using 'bdist_wininst' however, the 'real' interpreter is determined during the execution of the windows installer only. I would thus expect the installer to do the same trick again, i.e. modifying the first line of my scripts to point to the right interpreter, not the one used during the build. Am I missing something ? Is this a bug ? Regards, Stefan From Paul.Moore at atosorigin.com Wed Sep 17 10:01:33 2003 From: Paul.Moore at atosorigin.com (Moore, Paul) Date: Wed Sep 17 10:05:44 2003 Subject: [Distutils] more clashes between 'build' and 'bdist_wininst' Message-ID: <16E1010E4581B049ABC51D4975CEDB8802C0976A@UKDCX001.uk.int.atosorigin.com> From: Stefan Seefeld [mailto:seefeld@sympatico.ca] > I would thus expect the installer to do the same trick again, > i.e. modifying the first line of my scripts to point to > the right interpreter, not the one used during the build. > Am I missing something ? Is this a bug ? The #! line is not relevant on Windows, and so its contents don't really matter. Paul. From seefeld at sympatico.ca Wed Sep 17 10:30:37 2003 From: seefeld at sympatico.ca (Stefan Seefeld) Date: Wed Sep 17 10:30:46 2003 Subject: [Distutils] more clashes between 'build' and 'bdist_wininst' References: <16E1010E4581B049ABC51D4975CEDB8802C0976A@UKDCX001.uk.int.atosorigin.com> Message-ID: Moore, Paul wrote: > From: Stefan Seefeld [mailto:seefeld@sympatico.ca] > >>I would thus expect the installer to do the same trick again, >>i.e. modifying the first line of my scripts to point to >>the right interpreter, not the one used during the build. > > >>Am I missing something ? Is this a bug ? > > > The #! line is not relevant on Windows, and so its contents don't > really matter. Hmm, I was confused, sorry. I'm trying to run the script from within cygwin, so it *does* matter. However, I can't run the script from cygwin as is anyways, as the very mechanism of finding the interpreter, and passing it the file name, doesn't work because the file name would need to be translated via 'cygpath' first anyways. It seems I need a wrapper script in any case. Thanks, Stefan From judson at mcs.anl.gov Wed Sep 17 10:33:47 2003 From: judson at mcs.anl.gov (Ivan R. Judson) Date: Wed Sep 17 10:33:55 2003 Subject: [Distutils] more clashes between 'build' and 'bdist_wininst' In-Reply-To: <16E1010E4581B049ABC51D4975CEDB8802C0976A@UKDCX001.uk.int.atosorigin.com> Message-ID: <002e01c37d28$b48dc6a0$7b12dd8c@mcs.anl.gov> I'm new to the list, but I would argue that if the line doesn't functionally matter then the next important point is user/developer expectation (ie, I *expect* that line to point to something relevant, or it shouldn't be there). Therefore, I'd propose the behavior change on windows to either: 1) point to the correct python, or 2) be removed so it's not confusing. --Ivan > -----Original Message----- > From: distutils-sig-bounces@python.org > [mailto:distutils-sig-bounces@python.org] On Behalf Of Moore, Paul > Sent: Wednesday, September 17, 2003 9:02 AM > To: Stefan Seefeld; Distutils-Sig@Python.Org > Subject: RE: [Distutils] more clashes between 'build' and > 'bdist_wininst' > > > From: Stefan Seefeld [mailto:seefeld@sympatico.ca] > > I would thus expect the installer to do the same trick again, i.e. > > modifying the first line of my scripts to point to the right > > interpreter, not the one used during the build. > > > Am I missing something ? Is this a bug ? > > The #! line is not relevant on Windows, and so its contents > don't really matter. > > Paul. > > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > http://mail.python.org/mailman/listinfo/distut> ils-sig > From jessehammons at yahoo.com Thu Sep 18 14:53:14 2003 From: jessehammons at yahoo.com (Jesse Hammons) Date: Thu Sep 18 14:53:19 2003 Subject: [Distutils] distributing a large python application Message-ID: <20030918185314.56689.qmail@web41212.mail.yahoo.com> I am looking for advice on how to trip down the size of a monothic application I am building with python/wxPython. This project involves the python code from python, wxPython significant amounts of C and C++ code from wxPython, PyOpenGL and the underlying application functionality, which is largely a set of unix commands implemented in C. My question is: what strategies are there for doing a more traditional linking stage for the final application bundle? As it stands, I packaged up python, wxPython and PyOpenGL with my app and it came to a 100Meg binary. I use only a small portion of the funcionality of those packages (e.g. site-packages from python) but the wxPython and OpenGL extensions are done as shared libraries which means the whole thing goes out. I have tried freeze.py and similar, but that just seems to make things bigger. Are there tools that do a static analysis of python code to list which packages are actually used? What about a dynamic analysis (I run my app, then dump the list of loaded modules and just ship those). For the C/C++ code, I am thinking of just statically linking the extensions into a python exectable and letting the linker strip dead code. Advice or pointers to other groups appreciated. Thanks, -Jesse __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com From theller at python.net Thu Sep 18 15:17:27 2003 From: theller at python.net (Thomas Heller) Date: Thu Sep 18 15:17:14 2003 Subject: [Distutils] more clashes between 'build' and 'bdist_wininst' In-Reply-To: <002e01c37d28$b48dc6a0$7b12dd8c@mcs.anl.gov> (Ivan R. Judson's message of "Wed, 17 Sep 2003 09:33:47 -0500") References: <002e01c37d28$b48dc6a0$7b12dd8c@mcs.anl.gov> Message-ID: "Ivan R. Judson" writes: > I'm new to the list, but I would argue that if the line doesn't functionally > matter then the next important point is user/developer expectation (ie, I > *expect* that line to point to something relevant, or it shouldn't be > there). Therefore, I'd propose the behavior change on windows to either: > > 1) point to the correct python, or > 2) be removed so it's not confusing. Sounds sensible. Does anyone care enough to write a patch? Thomas From theller at python.net Thu Sep 18 15:21:32 2003 From: theller at python.net (Thomas Heller) Date: Thu Sep 18 15:21:17 2003 Subject: [Distutils] distributing a large python application In-Reply-To: <20030918185314.56689.qmail@web41212.mail.yahoo.com> (Jesse Hammons's message of "Thu, 18 Sep 2003 11:53:14 -0700 (PDT)") References: <20030918185314.56689.qmail@web41212.mail.yahoo.com> Message-ID: Jesse Hammons writes: > I am looking for advice on how to trip down the size of a monothic > application I am building with python/wxPython. > [...] > > I have tried freeze.py and similar, but that just seems to make things > bigger. > > Are there tools that do a static analysis of python code to list which > packages are actually used? Yes, used by freeze, for example. It's the modulefinder script, which is now (2.3) also in the standard library. > What about a dynamic analysis (I run my > app, then dump the list of loaded modules and just ship those). See sys.modules. Thomas From seefeld at sympatico.ca Thu Sep 18 15:29:31 2003 From: seefeld at sympatico.ca (Stefan Seefeld) Date: Thu Sep 18 15:29:23 2003 Subject: [Distutils] distributing a large python application References: <20030918185314.56689.qmail@web41212.mail.yahoo.com> Message-ID: <9bd9f67b65491169a2abf30448e0fd7a3f6a04b3@Orthosoft.ca> Jesse Hammons wrote: > I am looking for advice on how to trip down the size of a monothic > application I am building with python/wxPython. > > This project involves the python code from python, wxPython significant > amounts of C and C++ code from wxPython, PyOpenGL and the underlying > application functionality, which is largely a set of unix commands > implemented in C. > > My question is: what strategies are there for doing a more traditional > linking stage for the final application bundle? As it stands, I > packaged up python, wxPython and PyOpenGL with my app and it came to a > 100Meg binary. I use only a small portion of the funcionality of those > packages (e.g. site-packages from python) but the wxPython and OpenGL > extensions are done as shared libraries which means the whole thing > goes out. > > I have tried freeze.py and similar, but that just seems to make things > bigger. hmm, sounds as if the size is more determined by the shared lirbaries you depend on (wxWindows, GL, etc.) rather than the python wrappers. > Are there tools that do a static analysis of python code to list which > packages are actually used? What about a dynamic analysis (I run my > app, then dump the list of loaded modules and just ship those). > > For the C/C++ code, I am thinking of just statically linking the > extensions into a python exectable and letting the linker strip dead > code. yeah. But that doesn't help you strip down the C++ libraries. For those you have to repackage the original libs (or at least use static libs whenever you can). Regards, Stefan From seefeld at sympatico.ca Sat Sep 20 10:47:30 2003 From: seefeld at sympatico.ca (Stefan Seefeld) Date: Sat Sep 20 10:49:58 2003 Subject: [Distutils] distutils extension commands and option passing Message-ID: <3F6C6882.4020407@sympatico.ca> hi there, one of the things I like most about distutils is the compositional approach to the build system, i.e. commands such as 'bdist' being defined independently of 'build', so as soon as I have a working 'build' command, 'bdist' (and its variants) will work out-of-the-box most of the time. However, I'v now run into an issue with this very approach, and I wonder how to deal with that: As the 'build_ext' command shipped with distutils isn't powerful enough for my extensions, I'v written one myself. It's basically a wrapper around a call to 'make -C ...'. That is accompagnied by a 'config' command, doing, what else, a 'configure' call... I'v added various options to the config command to be able to enable/disable the various extensions that can be supported. But there doesn't seem to be a way to call 'python setup.py bdist_rpm' (say) and somehow pass options that are really meant for the config command, or is there ? That means I have to write my 'config' command such that the default is the desired configuration for the rpm. Right ? Any tips are highly appreciated, Stefan From seefeld at sympatico.ca Sat Sep 20 12:16:12 2003 From: seefeld at sympatico.ca (Stefan Seefeld) Date: Sat Sep 20 12:18:38 2003 Subject: [Distutils] distutils extension commands and option passing In-Reply-To: References: <3F6C6882.4020407@sympatico.ca> Message-ID: <3F6C7D4C.1030001@sympatico.ca> Hi Thomas, thanks for the reply. It's really a pitty that these things are not documented... Thomas Heller wrote: > There are three ways that I know of: > > On the command line (undocumented, AFAIK): > > python setup.py build_ext bdist_rpm interesting ! However, this doesn't really work in my case since the bdist_rpm command generates a script that is calling 'python setup.py install', so the above options aren't passed (i.e. the problem is that bdist_rpm would need a way to 'pass through' stuff without interpretation. > In the setup.cfg file (documented): > > [build_ext] > opt_1 = value_1 > opt_2 = value_2 > > [bdist_rpm] > opt_A = value_A > opt_B = value_B good, however, this would apply to every build then, right ? What I was looking for was a way to call 'python setup.py bdist_rpm --foo' and 'python setup.py bdist_rpm --bar' and have both build *different* rpms. And that is hard to achieve as bdist_rpm only has a fixed set of params and extending it is very hard. > And finally, you can pass a nested dictionary of options to the setup > script (aldo undocumented, AFAIK): > > options = {"build_exe": {"opt1": "value1", "opt2": "value2"} > "bdist_rpm": {"opta": "valuea", "optb": "valueb"}} hmm, that looks best, but it requires some top-level parameter processing to yield the flexibility I desire, i.e. before calling setup() I'd have to process the parameters myself and then fill these dictionaries appropriately. Looking into the code I see how the default commands do what I want: snippet from bdist_rpm: sdist = self.reinitialize_command('sdist') if self.use_bzip2: sdist.formats = ['bztar'] else: sdist.formats = ['gztar'] self.run_command('sdist') i.e. commands can communicate among each other through the 'distribution' object. Of course, that's quite fragile as it requires these commands to know each other, so setting or modifying another command's option 'in memory' has to be done with care. > IMO, patches for the docs would be appreciated. Hmm, is *anybody* actively working on distutils ? Of course, documenting existing code / practice would be a good start. But at some point I'd like to provide patches that enhance distutils, but for that I'd prefer to have a clear idea of the mental model the developers have (had ?) when working out the framework. There are notably two places I think would be worth enhancing: * a much enhanced 'config' command that provides functions to test platform specifics, similar to autoconf. * a much more flexible (and extensible !) way to deal with 'Extensions' Regards, Stefan From theller at python.net Sat Sep 20 11:32:00 2003 From: theller at python.net (Thomas Heller) Date: Sat Sep 20 22:01:00 2003 Subject: [Distutils] distutils extension commands and option passing In-Reply-To: <3F6C6882.4020407@sympatico.ca> (Stefan Seefeld's message of "Sat, 20 Sep 2003 10:47:30 -0400") References: <3F6C6882.4020407@sympatico.ca> Message-ID: Stefan Seefeld writes: > hi there, > > one of the things I like most about distutils is the compositional > approach to the build system, i.e. commands such as 'bdist' being > defined independently of 'build', so as soon as I have a working 'build' > command, 'bdist' (and its variants) will work out-of-the-box most > of the time. > > However, I'v now run into an issue with this very approach, and I > wonder how to deal with that: > > As the 'build_ext' command shipped with distutils isn't powerful > enough for my extensions, I'v written one myself. It's basically > a wrapper around a call to 'make -C ...'. That is accompagnied > by a 'config' command, doing, what else, a 'configure' call... > > I'v added various options to the config command to be able to > enable/disable the various extensions that can be supported. > > But there doesn't seem to be a way to call 'python setup.py bdist_rpm' > (say) and somehow pass options that are really meant for the config > command, or is there ? There are three ways that I know of: On the command line (undocumented, AFAIK): python setup.py build_ext bdist_rpm In the setup.cfg file (documented): [build_ext] opt_1 = value_1 opt_2 = value_2 [bdist_rpm] opt_A = value_A opt_B = value_B And finally, you can pass a nested dictionary of options to the setup script (aldo undocumented, AFAIK): options = {"build_exe": {"opt1": "value1", "opt2": "value2"} "bdist_rpm": {"opta": "valuea", "optb": "valueb"}} IMO, patches for the docs would be appreciated. Thomas From nkomcgysn at bigfoot.com Mon Sep 22 15:39:13 2003 From: nkomcgysn at bigfoot.com (Kip Waters) Date: Sun Sep 21 22:35:48 2003 Subject: [Distutils] new Sexual attractant jqnyqyywchayyla Message-ID: <5ffr4pc-j0v8s-$nta--$t$s32k-19@lsf3qt1.go1> An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/distutils-sig/attachments/20030922/22528443/attachment.html From amk at amk.ca Mon Sep 22 08:22:28 2003 From: amk at amk.ca (amk@amk.ca) Date: Mon Sep 22 08:22:34 2003 Subject: [Distutils] Attempt at writing bdist_dpkg Message-ID: <20030922122228.GC14051@rogue.amk.ca> I've found myself making a lot of Debian packages for various Python modules, so I've started working on a bdist_dpkg.py module for Distutils. Currently it's in nondist/sandbox/Lib/ in the Python CVS; you can download a copy from http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/nondist/sandbox/Lib/bdist_dpkg.py . When you run it, it creates a debian/ subdirectory containing a dummy changelog and default versions of control and rules. prerm and postinst are also created to compile .py files to .pyc and to remove them. Generated debian/ files contain a special marker and only files containing this marker will be overwritten, so if you have a custom rules or preinst file it won't be stomped on. Issues: * I can't figure out a way to put the marker in the 'control' and 'changelog' files, because their formats don't seem to support comments. * Right now the .deb for a packaged "foo" is named "foo"; it should be pythonX.Y-foo or whatever the Debian convention is. * The bdist_dpkg command needs to grow many options (e.g. setting the package name, using a particular file as the change log, etc.) Suggestions are welcome. If you have CVS access, feel free to modify the code and check in your changes. --amk From andreas.held at smi-grp.com Tue Sep 23 07:41:56 2003 From: andreas.held at smi-grp.com (andreas.held@smi-grp.com) Date: Tue Sep 23 07:42:00 2003 Subject: [Distutils] Customizing for MinGW Message-ID: Hi I am distributing an extension that can be built either using MinGW or MSVC on Windows. However, the extension must link against some additional libraries, whose name change depending on the compiler that was used to build them. For instance, using MSVC I have # module declarations module1 = Extension('_MyModule', libraries=ExtLib_One) and for MinGW I have # module declarations module1 = Extension('_MyModule', libraries=ExtLibOne) Unfortunately, I do not have any influence on the naming of those libraries and I wondered whether I can customize distutils to account for this. Basically, what I want is the follwoing if sys.platform=='win32': if compiler=='mingw32': libnames= ExtLibOne else: libnames=ExtLib_One How can I obtain the information on what compiler the script was invoked with, e.g. I would need the value of the command line switch '--compiler'? Can this be done at all? Thanks for your help Regards Andreas Held pyfltk.sourceforge.net From Alexandre.Fayolle at logilab.fr Thu Sep 25 04:40:09 2003 From: Alexandre.Fayolle at logilab.fr (Alexandre Fayolle) Date: Thu Sep 25 04:40:23 2003 Subject: [Distutils] MANIFEST generation Message-ID: <20030925084009.GI28349@calvin> Hi, I have the feeling that the MANIFEST file is not always generated from the MANIFEST.in, especially if MANIFEST.in has not changed since the previous generation. Is this the right behaviour? I was recently bitten by this when shipping a bugfix release: new files had been added which should have made it to the tarball, but since the MANIFEST file was not regenerated, this did not happen. Is regenerating the MANIFEST file so expensive that this tiny optimisation is necessary? My experience with most package is that the time gained is not that big -- especially compared to the time spent tracking the missing files ;o) -- Alexandre Fayolle LOGILAB, Paris (France). http://www.logilab.com http://www.logilab.fr http://www.logilab.org D?veloppement logiciel avanc? - Intelligence Artificielle - Formations From mal at lemburg.com Thu Sep 25 04:50:56 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Sep 25 04:51:01 2003 Subject: [Distutils] MANIFEST generation In-Reply-To: <20030925084009.GI28349@calvin> References: <20030925084009.GI28349@calvin> Message-ID: <3F72AC70.4010406@lemburg.com> Alexandre Fayolle wrote: > Hi, > > I have the feeling that the MANIFEST file is not always generated from > the MANIFEST.in, especially if MANIFEST.in has not changed since the > previous generation. Is this the right behaviour? > > I was recently bitten by this when shipping a bugfix release: new files > had been added which should have made it to the tarball, but since the > MANIFEST file was not regenerated, this did not happen. > > Is regenerating the MANIFEST file so expensive that this tiny > optimisation is necessary? My experience with most package is that the > time gained is not that big -- especially compared to the time spent > tracking the missing files ;o) I always delete the MANIFEST before building a new release. That seems to do the trick. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Sep 25 2003) >>> Python/Zope Products & Consulting ... http://www.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 Thu Sep 25 05:31:21 2003 From: Alexandre.Fayolle at logilab.fr (Alexandre Fayolle) Date: Thu Sep 25 05:31:36 2003 Subject: [Distutils] MANIFEST generation In-Reply-To: <3F72AC70.4010406@lemburg.com> References: <20030925084009.GI28349@calvin> <3F72AC70.4010406@lemburg.com> Message-ID: <20030925093121.GM28349@calvin> On Thu, Sep 25, 2003 at 10:50:56AM +0200, M.-A. Lemburg wrote: > > I always delete the MANIFEST before building a new release. That > seems to do the trick. Of course, this does the trick. But doing so also feels a lot like working around a bug or an unwanted feature. If people agree on that, I can work on a patch to change this behaviour. Unless of course some distutil users actually rely on this. -- Alexandre Fayolle LOGILAB, Paris (France). http://www.logilab.com http://www.logilab.fr http://www.logilab.org D?veloppement logiciel avanc? - Intelligence Artificielle - Formations From R.Liebscher at gmx.de Thu Sep 25 05:48:59 2003 From: R.Liebscher at gmx.de (Rene Liebscher) Date: Thu Sep 25 05:49:08 2003 Subject: [Distutils] MANIFEST generation In-Reply-To: <20030925093121.GM28349@calvin> Message-ID: On Thu, 25 Sep 2003, Alexandre Fayolle wrote: > On Thu, Sep 25, 2003 at 10:50:56AM +0200, M.-A. Lemburg wrote: > > > > I always delete the MANIFEST before building a new release. That > > seems to do the trick. > > Of course, this does the trick. But doing so also feels a lot like > working around a bug or an unwanted feature. > > If people agree on that, I can work on a patch to change this behaviour. > Unless of course some distutil users actually rely on this. > > -- > Alexandre Fayolle The sdist command has an option --force-manifest http://www.python.org/doc/current/dist/source-dist.html#SECTION000520000000000000000 You could write it in one of your prefered config files for distutils http://www.python.org/doc/current/inst/config-syntax.html So there is no need to make a patch for it. (Except maybe to better document this option so people find it better ;-) Kind regards Rene Liebscher From Alexandre.Fayolle at logilab.fr Thu Sep 25 06:01:55 2003 From: Alexandre.Fayolle at logilab.fr (Alexandre Fayolle) Date: Thu Sep 25 06:02:00 2003 Subject: [Distutils] MANIFEST generation In-Reply-To: References: <20030925093121.GM28349@calvin> Message-ID: <20030925100155.GQ28349@calvin> On Thu, Sep 25, 2003 at 11:48:59AM +0200, Rene Liebscher wrote: > The sdist command has an option --force-manifest > http://www.python.org/doc/current/dist/source-dist.html#SECTION000520000000000000000 > > You could write it in one of your prefered config files for distutils > http://www.python.org/doc/current/inst/config-syntax.html > > So there is no need to make a patch for it. (Except maybe to better > document this option so people find it better ;-) My sincerest apologies for not having reread the fine manual, and thanks a lot for pointing this out to me. I still think that the default behaviour is not the best one, but being able to write a setup.cfg file and forget about it is an acceptable trade off. -- Alexandre Fayolle LOGILAB, Paris (France). http://www.logilab.com http://www.logilab.fr http://www.logilab.org D?veloppement logiciel avanc? - Intelligence Artificielle - Formations From pgardell at bbn.com Thu Sep 25 10:12:44 2003 From: pgardell at bbn.com (Paul Gardella) Date: Thu Sep 25 10:13:24 2003 Subject: [Distutils] py2exe question Message-ID: <004001c3836f$235f1bf0$ce0aa8c0@PGARDELL> Hi, Not sure if it's appropriate to post py2exe questions here, so my first question is: is it OK? If not, is there a place where I can post py2exe questions? The py2exe question: When I run: python setup.py py2exe with the below setup.py, it just tells me: running py2exe error: Nothing to do The setup.py file: from distutils.core import setup import py2exe setup(name = "csmarter", version = "1.0", description="CSMARTer Society Editing Tool for Cougaar", author=, author_email=, url="http://www.cougaar.org", packages = ["csmarter", "csmarter.CSMARTer", "csmarter.ACMEPy"], data_files=[] ) This setup.py works great when I just run distutils on it. But when I run py2exe, I get the msg shown above. Something to note: the distribution root (where setup.py is located) contains no Python scripts (other than setup.py), but it does contain a subdirectory ("csmarter") which is a Python package (i.e., it has an __init__.py). This csmarter package contains no Python scripts itself (other than the __init__.py), but only two subdirectories/subpackages (CSMARTer and ACMEPy) which contain all the .py files. Is py2exe telling me there's nothing to do because there are no Python scripts in the distribution root or is there some other reason? Thanks. Paul Gardella From theller at python.net Thu Sep 25 11:55:02 2003 From: theller at python.net (Thomas Heller) Date: Thu Sep 25 11:55:15 2003 Subject: [Distutils] py2exe question In-Reply-To: <004001c3836f$235f1bf0$ce0aa8c0@PGARDELL> (Paul Gardella's message of "Thu, 25 Sep 2003 10:12:44 -0400") References: <004001c3836f$235f1bf0$ce0aa8c0@PGARDELL> Message-ID: "Paul Gardella" writes: > Hi, > > Not sure if it's appropriate to post py2exe questions here, so my first > question is: is it OK? If not, is there a place where I can post py2exe > questions? I recommend to use python-list (aka comp.lang.python). > The py2exe question: When I run: > > python setup.py py2exe > > with the below setup.py, it just tells me: > > running py2exe > error: Nothing to do > > > The setup.py file: > > from distutils.core import setup > import py2exe > > setup(name = "csmarter", version = "1.0", > description="CSMARTer Society Editing Tool for Cougaar", > author=, > author_email=, > url="http://www.cougaar.org", > packages = ["csmarter", "csmarter.CSMARTer", "csmarter.ACMEPy"], > data_files=[] > ) > > This setup.py works great when I just run distutils on it. But when I run > py2exe, I get the msg shown above. > > Something to note: the distribution root (where setup.py is located) > contains no Python scripts (other than setup.py), but it does contain a > subdirectory ("csmarter") which is a Python package (i.e., it has an > __init__.py). This csmarter package contains no Python scripts itself > (other than the __init__.py), but only two subdirectories/subpackages > (CSMARTer and ACMEPy) which contain all the .py files. > > Is py2exe telling me there's nothing to do because there are no Python > scripts in the distribution root or is there some other reason? Thanks. The former. py2exe converts the Python scripts specified in the 'scripts=["a.py", "b.py"]' argument to the setup function into exe-files. What did you expect the py2exe command to do? Thomas From pgardell at bbn.com Thu Sep 25 13:32:41 2003 From: pgardell at bbn.com (Paul Gardella) Date: Thu Sep 25 13:33:36 2003 Subject: [Distutils] py2exe question In-Reply-To: Message-ID: <004901c3838b$065432e0$ce0aa8c0@PGARDELL> py2exe converts the Python scripts specified in the 'scripts=["a.py", "b.py"]' argument to the setup function into exe-files. What did you expect the py2exe command to do? I expected py2exe to convert my entire application, not just individual scripts, to an exe. Distutils doesn't require a 'scripts=["a.py", "b.py"]' arg in setup.py. It could instead be a 'packages=["pkg-a", "pkg-b"]' arg, which mine is, so I don't have a 'scripts=["a.py"]' arg. I restructured my directories and moved setup.py into a dir containing .py files and ran 'python setup.py py2exe' from inside that dir, but still got an "error: Nothing to do" msg. (Continuing this thread on distutils-sig, but will move to comp.lang.python in the future -- thanks.) Paul From njriley at uiuc.edu Thu Sep 25 17:54:42 2003 From: njriley at uiuc.edu (Nicholas Riley) Date: Thu Sep 25 17:54:50 2003 Subject: [Distutils] clean -b argument ignored; set_undefined_options doesn't Message-ID: <20030925215441.GA9137@uiuc.edu> Hi, Here's something that I think should work: % python setup.py --help clean [...] Options for 'clean' command: --build-base (-b) base build directory (default: 'build.build-base') % python setup.py clean -b ../builds running clean Nothing happens. This works, however: % python setup.py build -b ../builds clean running build running build_py running build_ext running config gcc -E -I/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3 -o_configtest.i _configtest.c removing: _configtest.c _configtest.i running clean removing '../builds/temp.darwin-6.8-Power_Macintosh-2.3' (and everything under it) The logic to set build_temp from build_base (-b) is only present in the build command, not in the clean command. The code to set this option runs from clean.set_undefined_options. But it's clean's build_base option which is set at the time, not build's, so it propagates an empty path. The test command class I found posted to this mailing list has a workaround for the above problem, which looks like this: def finalize_options(self): build = self.distribution.get_command_obj('build') build_options = ('build_base', 'build_purelib', 'build_platlib') for option in build_options: setattr(build, option, getattr(self, option)) build.ensure_finalized() for option in build_options: setattr(self, option, getattr(build, option)) and doesn't call self.set_undefined_options at all, though the last three lines could be replaced by it. There are several solutions I can think of: - set_undefined_options should be changed to propagate set options to the source command object before calling src_cmd_obj.ensure_finalized. - another method should be added to the cmd class, which does the above propagation then calls set_undefined_options. - a workaround such as the one above should be placed in the distutils.command.clean.clean class. Does this make sense? Unless there's a huge compatibility issue, I'd favor the first option, but my experience with distutils is limited. -- =Nicholas Riley | From njriley at uiuc.edu Thu Sep 25 18:00:54 2003 From: njriley at uiuc.edu (Nicholas Riley) Date: Thu Sep 25 18:01:13 2003 Subject: [Distutils] Workarounds for C++ module linking issues - OK? Message-ID: <20030925220054.GB9137@uiuc.edu> Hi, It's me again. With the exception of the clean problem in my previous email, I think I've got my distutils-based setup script working properly. To do so, I've needed to add a few workarounds where distutils wasn't doing the right thing, and I couldn't convince it to do so by ordinary means. The changes revolve around the fact that the module is written in C++, and I want to provide support back to Python 1.5.2. They are as follows. class build_mkext(build_ext): # force use of C++ compiler (helps on some platforms) def finalize_options(self): self.run_command('config') import os cc = os.environ.get('CXX', sysconfig.get_config_var('CXX')) if not cc: cc = sysconfig.get_config_var('CCC') # Python 1.5.2 if cc: os.environ['CC'] = cc build_ext.finalize_options(self) def build_extension(self, ext): # work around linker problem with MacPython 2.3 if sys.platform == 'darwin': try: self.compiler.linker_so.remove("-Wl,-x") except: pass # work around linker problem with Linux, Python 2.2 and earlier: # despite setting $CC above, still uses Python compiler if sys.platform == 'linux2': try: ext.libraries.append("stdc++") except: pass [...] Does this all look OK? I realize it's not the cleanest thing in the world, but such workarounds seldom are. I just don't want to do something that will break in the near future, and this is the first distutils setup script I've written. :-) If you need to see the rest of the file, it's at: Thanks, -- =Nicholas Riley | From jeremy at alum.mit.edu Fri Sep 26 22:31:08 2003 From: jeremy at alum.mit.edu (Jeremy Hylton) Date: Fri Sep 26 22:31:53 2003 Subject: [Distutils] MANIFEST generation In-Reply-To: <20030925100155.GQ28349@calvin> References: <20030925093121.GM28349@calvin> <20030925100155.GQ28349@calvin> Message-ID: <1064629868.19498.65.camel@localhost.localdomain> On Thu, 2003-09-25 at 06:01, Alexandre Fayolle wrote: > I still think that the default behaviour is not the best one, but being > able to write a setup.cfg file and forget about it is an acceptable > trade off. It agree that the default behavior seems problematic. I always use sdist --force-manifest when building a release. What's the use case for ignoring files in a source distribution that would otherwise be included? It doesn't sound like an obvious default. Jeremy From dave at boost-consulting.com Sat Sep 27 10:37:29 2003 From: dave at boost-consulting.com (David Abrahams) Date: Sat Sep 27 11:30:24 2003 Subject: [Distutils] [bug] -lutil in get_config_var('LIBS') on cywgin Message-ID: $ python Python 2.3 (#1, Aug 1 2003, 15:01:23) [GCC 3.2 20020927 (prerelease)] on cygwin Type "help", "copyright", "credits" or "license" for more information. >>> from distutils import sysconfig >>> print sysconfig.get_config_var('LIBS') -lutil Cygwin doesn't have any libutil, so this causes problems for anything which takes distutils' word about which libraries are needed. http://synopsis.sf.net is one example. -- Dave Abrahams Boost Consulting www.boost-consulting.com From dave at boost-consulting.com Sat Sep 27 11:58:58 2003 From: dave at boost-consulting.com (David Abrahams) Date: Sat Sep 27 11:59:11 2003 Subject: [Distutils] walking for sub-packages Message-ID: I just added the following to a setup.py: # # Find all the sub-packages of Synopsis # def add_package(found_packages, directory, local_names): if '__init__.py' in local_names: found_packages.append( re.sub('.*Synopsis', 'Synopsis', directory) .replace(os.path.sep, '.') ) else: local_names = [] py_packages = [] os.path.walk('Synopsis', add_package, py_packages) # sanity check assert 'Synopsis.Core' in py_packages Then naturally, I call setup with packages=py_packages. Is something like that capability built into distutils? If not, shouldn't it be? -- Dave Abrahams Boost Consulting www.boost-consulting.com From benoit.regrain at creatis.insa-lyon.fr Mon Sep 29 05:40:36 2003 From: benoit.regrain at creatis.insa-lyon.fr (Benoit Regrain) Date: Mon Sep 29 05:35:54 2003 Subject: [Distutils] [python2.2.2 + RedHat9] setup.py doesn't work correctly Message-ID: <000801c3866d$bccf10f0$d06cdcc3@pcregrain> Hi, I have problem to package my library using the setup.py. This package contains soome python modules and C++ code that must be compiled. Before, I was under RedHat7.3 and I had no problem to create my package. I have moved under RedHat9 ; and now, I obtain an assertion failure when I have the part concerning the compilation (ext_modules parameter of the setup method) The assertion failure appears after the compilation of C++ code. And the error message is : [...] File "/usr/lib/python2.2/distutils/command/bdist_rpm.py", line 314, in run assert len(rpms) == 1, \ AssertionError: unexpected number of RPM files found: ['build/bdist.linux-i686/rpm/RPMS/i386/DaVaW-1.2-1.i386.rpm', 'build/bdist.linux-i686/rpm/RPMS/i386/DaVaW-debuginfo-1.2-1.i386.rpm'] Greatings for your help ----------------------------------------------------------------- Benoit Regrain Ing?nieur d'?tudes CNRS (Creatis) email : regrain@creatis.insa-lyon.fr phone : (+33) (0) 4.72.43.82.58 fax : (+33) (0) 4.72.43.85.26 INSA - B?timent Blaise Pascal 7, avenue Jean Capelle F - 69621 Villeurbanne Cedex ----------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/distutils-sig/attachments/20030929/67a36974/attachment.html From ncabral at terra.com.br Mon Sep 29 09:58:53 2003 From: ncabral at terra.com.br (=?iso-8859-1?Q?Ricardo_Niederberger_Cabral?=) Date: Mon Sep 29 09:59:01 2003 Subject: =?iso-8859-1?Q?Re:[Distutils]_[python2.2.2_+_RedHat9]_setup.py_doesn't_work_correctly?= Message-ID: [...] > I have moved under RedHat9 ; and now, I obtain an assertion failure when I have [...] > File "/usr/lib/python2.2/distutils/command/bdist_rpm.py", line 314, in run > assert len(rpms) == 1, \ > AssertionError: unexpected number of RPM files found: ['build/bdist.linux-i686/rpm/RPMS/i386/DaVaW-1.2-1.i386.rpm', > 'build/bdist.linux-i686/rpm/RPMS/i386/DaVaW-debuginfo-1.2-1.i386.rpm'] I had the same problem, so i made a patch to remove that warning so bdist_rpm moves all RPMs to the 'dist' dir properly. See the attachment at: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731328&group_id=5470 Best regards, -- Ricardo Niederberger Cabral From amk at amk.ca Mon Sep 29 10:39:14 2003 From: amk at amk.ca (amk@amk.ca) Date: Mon Sep 29 10:39:19 2003 Subject: [Distutils] [python2.2.2 + RedHat9] setup.py doesn't work correctly In-Reply-To: <000801c3866d$bccf10f0$d06cdcc3@pcregrain> References: <000801c3866d$bccf10f0$d06cdcc3@pcregrain> Message-ID: <20030929143914.GA14470@rogue.amk.ca> On Mon, Sep 29, 2003 at 11:40:36AM +0200, Benoit Regrain wrote: > AssertionError: unexpected number of RPM files found: ['build/bdist.linux-i686/rpm/RPMS/i386/DaVaW-1.2-1.i386.rpm', > 'build/bdist.linux-i686/rpm/RPMS/i386/DaVaW-debuginfo-1.2-1.i386.rpm'] Interesting. It looks like RPM now builds two RPMs, one with debugging information and one without it. Is the resulting DaVaW-debuginfo-1.2-1.i386.rpm RPM file actually correct? That is, does it contain debugging versions of all .so files, plus whatever .py/data files are to be installed? If the debugging RPM is correct, then the assertion should be removed and both RPM files should be copied to dist/. If the debugging RPM is wrong, then its generation should be suppressed. I think this would be done by including '%debug_package %{nil}' in the .spec file that bdist_rpm generates. --amk From mss at mawhrin.net Mon Sep 29 14:17:36 2003 From: mss at mawhrin.net (Mikhail Sobolev) Date: Mon Sep 29 14:17:40 2003 Subject: [Distutils] "maintainer" definition Message-ID: <20030929181736.GA29441@mawhrin.net> I have a quick question regarding the maintainer{,_email} fields. Who exactly is supposed to be mentioned here? I checked the documentation and did not find anything on this topic. "Distributing Python Modules" just mentiones that you can also add this information to the setup.py file, while "tasks and roles" document uses a completely different terminology. So is there anything like a description of a maintainer? Thanks -- Misha -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mail.python.org/pipermail/distutils-sig/attachments/20030929/5ffe4be4/attachment.bin From amk at amk.ca Tue Sep 30 08:03:43 2003 From: amk at amk.ca (amk@amk.ca) Date: Tue Sep 30 08:03:49 2003 Subject: [Distutils] "maintainer" definition In-Reply-To: <20030929181736.GA29441@mawhrin.net> References: <20030929181736.GA29441@mawhrin.net> Message-ID: <20030930120343.GA19041@rogue.amk.ca> On Mon, Sep 29, 2003 at 07:17:36PM +0100, Mikhail Sobolev wrote: > I have a quick question regarding the maintainer{,_email} fields. Who > exactly is supposed to be mentioned here? I checked the documentation The author is the person who originally wrote a piece of software; the maintainer is the person who's actually maintaining it. For example, Sam Rushing is the author of Medusa, but I'm the current maintainer. --amk From mss at mawhrin.net Tue Sep 30 08:38:41 2003 From: mss at mawhrin.net (Mikhail Sobolev) Date: Tue Sep 30 08:38:48 2003 Subject: [Distutils] "maintainer" definition In-Reply-To: <20030930120343.GA19041@rogue.amk.ca> References: <20030929181736.GA29441@mawhrin.net> <20030930120343.GA19041@rogue.amk.ca> Message-ID: <20030930123841.GA1583@mawhrin.net> On Tue, Sep 30, 2003 at 08:03:43AM -0400, amk@amk.ca wrote: > On Mon, Sep 29, 2003 at 07:17:36PM +0100, Mikhail Sobolev wrote: > > I have a quick question regarding the maintainer{,_email} fields. Who > > exactly is supposed to be mentioned here? I checked the documentation > > The author is the person who originally wrote a piece of software; the > maintainer is the person who's actually maintaining it. For example, Sam > Rushing is the author of Medusa, but I'm the current maintainer. So in case the original author still works on this piece of software, the maintainer field won't be filled? Do I understand right that at the moment both author and maintainer are "single entity" parameters? The case when there are several authors/maintainers cannot be directly described in setup.py file? -- Misha -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mail.python.org/pipermail/distutils-sig/attachments/20030930/f274ddf7/attachment.bin From andy at nospam.com Tue Sep 30 17:43:08 2003 From: andy at nospam.com (Andy Sy) Date: Tue Sep 30 17:36:08 2003 Subject: [Distutils] Spawning Swig fails if not installed in C:\ Message-ID: <3F79F8EC.7080108@nospam.com> In build_ext.py, we see the following code: elif os.name == "nt": # Look for SWIG in its standard installation directory on # Windows (or so I presume!). If we find it there, great; SEE ---> # if not, act like Unix and assume it's in the PATH. for vers in ("1.3", "1.2", "1.1"): fn = os.path.join("c:\\swig%s" % vers, "swig.exe") if os.path.isfile(fn): return fn else: return "swig.exe" However, it doesn't really work because in spawn.py: if not dry_run: SEE ---># spawn for NT requires a full path to the .exe try: rc = os.spawnv(os.P_WAIT, executable, cmd) except OSError, exc: # this seems to happen when the command isn't found raise DistutilsExecError, \ "command '%s' failed: %s" % (cmd[0], exc[-1]) if rc != 0: # and this reflects the command running but failing raise DistutilsExecError, \ "command '%s' failed with exit status %d" % (cmd[0], rc) Thus, if Swig is installed in any place other than c:\, the first code will not be smart enough to make things work. -- ========================================= reply-to: a n d y @ n e t f x p h . c o m From seberino at spawar.navy.mil Tue Sep 30 19:50:25 2003 From: seberino at spawar.navy.mil (seberino@spawar.navy.mil) Date: Tue Sep 30 19:50:29 2003 Subject: [Distutils] newbie distutils questions *please*... Message-ID: <20030930235025.GA9930@spawar.navy.mil> I had some newbie distutils I wanted to humbly ask if you don't mind. I read distutils docs on python.org but still had some basic questions... 1. What goes into __init__.py files??? I know what setup.py contents are but I don't recall seeing advice on what to put in __init__.py. 2. I have a ton of data files to list in setup(...) with the data_files switch. Can I avoid listing EVERY file somehow??? Can I use a wildcard in the filename???? 3. Will bdist_rpm install JUST pyc files (bytecode)??? Will sdist install JUST py (source) files??? What about installing source and bytecode?? (py and pyc)?? How do that and is THAT a good idea??? 4. If I tell setup(...) I have a package somewhere with packages = ["..."] does that mean it will get ALL files in that directory without me having to specify them individually?? What if I want to OMIT a file like the CVS directory?!?! Thanks! Chris -- _______________________________________ Christian Seberino, Ph.D. SPAWAR Systems Center San Diego Code 2872 49258 Mills Street, Room 158 San Diego, CA 92152-5385 U.S.A. Phone: (619) 553-9973 Fax : (619) 553-6521 Email: seberino@spawar.navy.mil _______________________________________ From jeremy at alum.mit.edu Tue Sep 30 22:49:30 2003 From: jeremy at alum.mit.edu (Jeremy Hylton) Date: Tue Sep 30 22:50:37 2003 Subject: [Distutils] newbie distutils questions *please*... In-Reply-To: <20030930235025.GA9930@spawar.navy.mil> References: <20030930235025.GA9930@spawar.navy.mil> Message-ID: <1064976570.2750.13.camel@localhost.localdomain> On Tue, 2003-09-30 at 19:50, seberino@spawar.navy.mil wrote: > 1. What goes into __init__.py files??? I know what setup.py contents are > but I don't recall seeing advice on what to put in __init__.py. You don't need to put anything into __init__.py files. They are necessary to make Python recognize a directory as a package, but they can be empty. If you put code in __init__.py, it is executed when the package is imported, including the first time a submodule of a package is imported. It is sometimes useful to execute code here, but that's up to you. > 2. I have a ton of data files to list in setup(...) with the > data_files switch. Can I avoid listing EVERY file somehow??? > Can I use a wildcard in the filename???? It can be tedious to list all the data files. The setup.py script is a regular Python script, though, so you can compute the full list from the wildcard. The glob module might do what you want or you can search for files using os.path.walk. > 3. Will bdist_rpm install JUST pyc files (bytecode)??? > Will sdist install JUST py (source) files??? > What about installing source and bytecode?? (py and pyc)?? > How do that and is THAT a good idea??? The bdist and sdist commands do not install anything. They generate distributions that can be used to install software. You probably know that, but I want to make sure we're on the same page. An sdist distribution contains only .py files. The source distribution could work with many versions of Python, but .pyc files are tied to a particular version. The source distribution generates .pyc files when a user unpacks it and runs "python setup.py install". I believe a bdist command will have the same effect. I'm not sure about bdist_rpm, but bdist_wininst only puts source files in the distribution. > 4. If I tell setup(...) I have a package somewhere with > packages = ["..."] > does that mean it will get ALL files in that directory without > me having to specify them individually?? It means all .py files. It will ignore any other file in the directory. Note that you have to explicitly include subpackages in the list. > What if I want to OMIT a file like the CVS directory?!?! It gets skipped, because it isn't listed as a package. If you tried to list it as a package, it still wouldn't contain any .py files. Note that it is a little tedious to get non-Python files installed with a package. If you want a data file to be included next to the .py file, you've got to go to a lot of trouble. Jeremy