From mal@lemburg.com Wed Jan 1 11:33:02 2003 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed Jan 1 11:33:02 2003 Subject: [Distutils] swig 1.3.x In-Reply-To: References: <3E10B2F4.7090901@lbl.gov> Message-ID: <3E1317DD.70702@lemburg.com> Paul Moore wrote: > Keith Jackson writes: > > >>What are folks feelings about supporting recent versions of swig in >>distutils? I'd be willing to do the changes to get this working >>again, but only if people are interested. Right now I just use my >>own run_swig method, but I'd rather have this work as a core part of >>distutils. > > > I think this is probably a good idea. SWIG 1.1 is pretty much > unmaintained these days, and 1.3 is the de facto current version (even > if it's theoretically not yet designated as stable). > > But my interest is purely theoretical. I don't have any code which > uses SWIG at the moment, and there may well be people out there > currently using the Distutils/SWIG 1.1 support, and who can't make the > necessary changes to go to SWIG 1.3 (the two versions aren't > compatible). > > If you want to support a gradual migration, maybe it would pe possible > to have SWIG support which recognises a swig_version argument > somewhere, which could be set to 1.1 or 1.3. What changes would have to be implemented in distutils for swig 1.3 ? If it's just the names of a few options I'd suggest to make the swig support smart enough to support both versions as Keith suggests. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From krjackson@lbl.gov Thu Jan 2 19:03:00 2003 From: krjackson@lbl.gov (Keith Jackson) Date: Thu Jan 2 19:03:00 2003 Subject: [Distutils] swig 1.3.x References: <3E10B2F4.7090901@lbl.gov> <3E1317DD.70702@lemburg.com> Message-ID: <3E14D331.9090301@lbl.gov> M.-A. Lemburg wrote: > What changes would have to be implemented in distutils > for swig 1.3 ? If it's just the names of a few options > I'd suggest to make the swig support smart enough to support > both versions as Keith suggests. I think the only changes are in the options. Everything else should stay the same. I'm currently planning on making 1.3 the default version, and requiring an explicit swig_version option to revert to 1.1. --keith ---------------------------------------------------------------- Keith R. Jackson KRJackson@lbl.gov Grid Technology Group (510) 486-4401 Lawrence Berkeley National Laboratory http://www-itg.lbl.gov/~kjackson/ From krjackson@lbl.gov Thu Jan 2 20:54:03 2003 From: krjackson@lbl.gov (Keith Jackson) Date: Thu Jan 2 20:54:03 2003 Subject: [Distutils] swig 1.3.x References: <3E10B2F4.7090901@lbl.gov> <3E1317DD.70702@lemburg.com> <3E14D331.9090301@lbl.gov> Message-ID: <3E14ED6D.5020503@lbl.gov> I think I'd like to include an "extra_swig_args=" option that would allow users to pass in a string that would be passed directly to the swig command line before the "-o" option. Thoughts? --keith ---------------------------------------------------------------- Keith R. Jackson KRJackson@lbl.gov Grid Technology Group (510) 486-4401 Lawrence Berkeley National Laboratory http://www-itg.lbl.gov/~kjackson/ From krjackson@lbl.gov Thu Jan 2 23:36:03 2003 From: krjackson@lbl.gov (Keith Jackson) Date: Thu Jan 2 23:36:03 2003 Subject: [Distutils] swig 1.3.x References: <3E10B2F4.7090901@lbl.gov> <3E1317DD.70702@lemburg.com> <3E14D331.9090301@lbl.gov> <3E14ED6D.5020503@lbl.gov> Message-ID: <3E151361.1090100@lbl.gov> I've run into a bit of a problem in getting swig 1.3.x working with distutils. Running swig on an interface file now produces two files by default; a python shadow class file and the C/C++ wrap file. For example: swig -python example.i produces example_wrap.c and example.py. It then expects that the generated .so will be _example.so. The problem is with the generated python file. How would we get it added into the python modules. It looks like build_py runs before build_ext, and even if they didn't there isn't a communication mechanism to have one Command sub-class add information into another Command sub-class. Any thoughts about how this might be addressed? If this can be solved, everything else seems to be working fine. Everything works fine for generating my modules since I don't use the automated shadow class generation of swig. Getting this working for both 1.1.x and 1.3.x required minimal changes to the build_ext class. --keith ---------------------------------------------------------------- Keith R. Jackson KRJackson@lbl.gov Grid Technology Group (510) 486-4401 Lawrence Berkeley National Laboratory http://www-itg.lbl.gov/~kjackson/ From mal@lemburg.com Fri Jan 3 06:40:01 2003 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri Jan 3 06:40:01 2003 Subject: [Distutils] swig 1.3.x In-Reply-To: <3E14D331.9090301@lbl.gov> References: <3E10B2F4.7090901@lbl.gov> <3E1317DD.70702@lemburg.com> <3E14D331.9090301@lbl.gov> Message-ID: <3E157623.209@lemburg.com> Keith Jackson wrote: > M.-A. Lemburg wrote: > >> What changes would have to be implemented in distutils >> for swig 1.3 ? If it's just the names of a few options >> I'd suggest to make the swig support smart enough to support >> both versions as Keith suggests. > > > I think the only changes are in the options. Everything else should stay > the same. I'm currently planning on making 1.3 the default version, and > requiring an explicit swig_version option to revert to 1.1. Isn't there a way to tell the SWIG version by calling swig itself ? I think distutils should figure this one out by itself. Alas, the program you're compiling probably is bound to a specific SWIG version anyway, so maybe we need a helper which people can call in their setup.py files to check, e.g. swig_version(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal@lemburg.com Fri Jan 3 06:40:04 2003 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri Jan 3 06:40:04 2003 Subject: [Distutils] swig 1.3.x In-Reply-To: <3E14ED6D.5020503@lbl.gov> References: <3E10B2F4.7090901@lbl.gov> <3E1317DD.70702@lemburg.com> <3E14D331.9090301@lbl.gov> <3E14ED6D.5020503@lbl.gov> Message-ID: <3E15763D.4000809@lemburg.com> Keith Jackson wrote: > I think I'd like to include an "extra_swig_args=" option that would allow > users to pass in a string that would be passed directly to the swig command > line before the "-o" option. Thoughts? Sounds like a plan. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal@lemburg.com Fri Jan 3 06:45:02 2003 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri Jan 3 06:45:02 2003 Subject: [Distutils] swig 1.3.x In-Reply-To: <3E151361.1090100@lbl.gov> References: <3E10B2F4.7090901@lbl.gov> <3E1317DD.70702@lemburg.com> <3E14D331.9090301@lbl.gov> <3E14ED6D.5020503@lbl.gov> <3E151361.1090100@lbl.gov> Message-ID: <3E157778.9010406@lemburg.com> Keith Jackson wrote: > I've run into a bit of a problem in getting swig 1.3.x working with > distutils. Running swig on an interface file now produces two files > by default; a python shadow class file and the C/C++ wrap file. > > For example: > swig -python example.i > produces example_wrap.c and example.py. > It then expects that the generated .so will be _example.so. > > The problem is with the generated python file. How would we get it > added into the python modules. It looks like build_py runs before > build_ext, and even if they didn't there isn't a communication mechanism > to have one Command sub-class add information into another Command > sub-class. Any thoughts about how this might be addressed? There is: you have to reinitialize the command and then refinalize it, e.g. # Reinitialize build_ext command with extra defines build_ext = self.distribution.reinitialize_command('build_ext') build_ext.ensure_finalized() However, this doesn't rerun the command. That should be doable with self.distribution.run_command('build_py') though. > If this can be solved, everything else seems to be working fine. > Everything works fine for generating my modules since I don't use the > automated shadow class generation of swig. Getting this working for both > 1.1.x and 1.3.x required minimal changes to the build_ext class. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From bhoel@web.de Fri Jan 3 07:50:02 2003 From: bhoel@web.de (Berthold =?iso-8859-1?q?H=F6llmann?=) Date: Fri Jan 3 07:50:02 2003 Subject: [Distutils] Re: swig 1.3.x In-Reply-To: <3E157623.209@lemburg.com> References: <3E10B2F4.7090901@lbl.gov> <3E1317DD.70702@lemburg.com> <3E14D331.9090301@lbl.gov> <3E157623.209@lemburg.com> Message-ID: "M.-A. Lemburg" writes: > Keith Jackson wrote: > > M.-A. Lemburg wrote: > > ... > > Isn't there a way to tell the SWIG version by calling swig itself ? > I think distutils should figure this one out by itself. There is of course a way to get the swig version: ~/ [1]>/usr/bin/swig -version SWIG Version 1.3.13u-20020910-1829 Copyright (c) 1995-1998 University of Utah and the Regents of the University of California Copyright (c) 1998-2001 University of Chicago Compiled with CC ~/ [1]>/usr/local/bin/swig -version SWIG Version 1.1 (Build 786) Copyright (c) 1995-98 University of Utah and the Regents of the University of California Compiled with g++ > Alas, the program you're compiling probably is bound to a specific SWIG > version anyway, so maybe we need a helper which people can call > in their setup.py files to check, e.g. swig_version(). Maybe there should also be a way to select a special swig executable like "--swig=swig1.1" to be able to have several swig exectables at the same time, and switch to another version if needed. The alternative would be to have several "swig"s and to fiddle with the PATH, but an option would probably be easier for some OSs. Greetings Berthold -- bhoel@web.de / http://starship.python.net/crew/bhoel/ It is unlawful to use this email address for unsolicited ads (USC Title 47 Sec.227). I will assess a US$500 charge for reviewing and deleting each unsolicited ad. From akuchlin@mems-exchange.org Fri Jan 3 11:03:11 2003 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Fri Jan 3 11:03:11 2003 Subject: [Distutils] PEP 301 implementation checked in Message-ID: I've checked in Richard Jones's patches, so those of you who follow the Python CVS trunk can now play with the PEP 301 implementation. Changes: * The DistributionMetadata object and the setup() function now support 'classifiers' as a keyword. * The 'register' distutil command has been added to upload a package's metadata to the PyPI server. The registry is still running on my web server at amk.ca, a bandwidth-limited DSL line, but it'll be moved to something at python.org before too long. (Certainly before 2.3final ships!) Please bang on the distutils code in any way you can think of, filing bug reports and offering comments, so we can be sure that it's solid. You can comment on the web site, too, but the site can be updated independently of the Python code so there's less pressure to get it finished before 2.3final. Here's an example of how the new code works. A setup.py file can now contain a 'classifiers' argument listing Trove-style classifiers: setup (name = "Quixote", version = "0.5.1", description = "A highly Pythonic Web application framework", ... classifiers= ['Topic :: Internet :: WWW/HTTP :: Dynamic Content', 'Environment :: No Input/Output (Daemon)', 'Intended Audience :: Developers'], ... ) I can then run 'python setup.py register' to upload an entry to the package index, which is browseable at http://www.amk.ca/cgi-bin/pypi.cgi . ('register --list-classifiers' will output a list of legal classifiers.) See PEP 301 for more details. --amk (www.amk.ca) OLIVIA: Why, this is very midsummer madness. -- _Twelfth Night_, III, iv From krjackson@lbl.gov Fri Jan 3 16:17:02 2003 From: krjackson@lbl.gov (Keith Jackson) Date: Fri Jan 3 16:17:02 2003 Subject: [Distutils] swig 1.3.x References: <3E10B2F4.7090901@lbl.gov> <3E1317DD.70702@lemburg.com> <3E14D331.9090301@lbl.gov> <3E157623.209@lemburg.com> Message-ID: <3E15FDF5.2090404@lbl.gov> M.-A. Lemburg wrote: > Isn't there a way to tell the SWIG version by calling swig itself ? > I think distutils should figure this one out by itself. > Sounds good. > Alas, the program you're compiling probably is bound to a specific SWIG > version anyway, so maybe we need a helper which people can call > in their setup.py files to check, e.g. swig_version(). Ok, that sounds pretty useful. --keith ---------------------------------------------------------------- Keith R. Jackson KRJackson@lbl.gov Grid Technology Group (510) 486-4401 Lawrence Berkeley National Laboratory http://www-itg.lbl.gov/~kjackson/ From krjackson@lbl.gov Fri Jan 3 17:31:32 2003 From: krjackson@lbl.gov (Keith Jackson) Date: Fri Jan 3 17:31:32 2003 Subject: [Distutils] Re: swig 1.3.x References: <3E10B2F4.7090901@lbl.gov> <3E1317DD.70702@lemburg.com> <3E14D331.9090301@lbl.gov> <3E157623.209@lemburg.com> Message-ID: <3E160F5F.4090201@lbl.gov> Berthold H=F6llmann wrote: > "M.-A. Lemburg" writes: >>Keith Jackson wrote: >>>M.-A. Lemburg wrote: > There is of course a way to get the swig version: >=20 > ~/ [1]>/usr/bin/swig -version >=20 > SWIG Version 1.3.13u-20020910-1829 > Copyright (c) 1995-1998 > University of Utah and the Regents of the University of California > Copyright (c) 1998-2001 > University of Chicago >=20 > Compiled with CC > ~/ [1]>/usr/local/bin/swig -version >=20 > SWIG Version 1.1 (Build 786) > Copyright (c) 1995-98 > University of Utah and the Regents of the University of California What is the right non-platform specific way to execute a command, and=20 get the output back? The distutils spawn command doesn't return the=20 output, and popen doesn't exist on Macs. I don't normally work with=20 Macs, so any suggestions would be appreciated. > Maybe there should also be a way to select a special swig executable > like "--swig=3Dswig1.1" to be able to have several swig exectables at > the same time, and switch to another version if needed. The > alternative would be to have several "swig"s and to fiddle with the > PATH, but an option would probably be easier for some OSs. That sounds like a good idea. --keith ---------------------------------------------------------------- Keith R. Jackson KRJackson@lbl.gov Grid Technology Group (510) 486-4401 Lawrence Berkeley National Laboratory http://www-itg.lbl.gov/~kjackson/ From Jack.Jansen@cwi.nl Mon Jan 6 12:05:51 2003 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Mon Jan 6 12:05:51 2003 Subject: [Distutils] Re: swig 1.3.x In-Reply-To: <3E160F5F.4090201@lbl.gov> Message-ID: <06F8C412-2175-11D7-BA8A-0030655234CE@cwi.nl> On Friday, Jan 3, 2003, at 23:31 Europe/Amsterdam, Keith Jackson wrote: > > What is the right non-platform specific way to execute a command, and > get the output back? The distutils spawn command doesn't return the > output, and popen doesn't exist on Macs. I don't normally work with > Macs, so any suggestions would be appreciated. You won't get this to work on MacOS9. The best solution is probably to tell the user what the unix command line would have been (preferably in a dialog, but a print is probably okay too) and exit. -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From corydodt@yahoo.com Wed Jan 8 12:24:06 2003 From: corydodt@yahoo.com (Cory Dodt) Date: Wed Jan 8 12:24:06 2003 Subject: [Distutils] --post-install on win32 Message-ID: <20030108172336.11068.qmail@web10007.mail.yahoo.com> I have been working with the --post-install option to bdist_wininst and have noticed the following behavior, which appears to be a bug or possibly a misdesign. The consequence of this behavior is at the end, it will take some explaining to get there... I'm going to use the following terms: pre-build time: the moment you issue the command C:\...\>setup.py bdist_wininst --install-script=x build time: while build_* is happening post-install time: after you've run the bdist_wininst installer and gone through the wizard; the very last page of the wizard, when it runs the post-install script. post-install-arg: what you gave as an argument to --install-script=... The argument to --install-script at pre-build time has to match an entry in setup_args['scripts'], that is, if you have { ... 'scripts': ['my-postinstall.py'] } You have to provide --install-script=my-postinstall.py but if you have { ... 'scripts': ['win32/my-postinstall.py'] } You have to provide --install-script=win32\my-postinstall.py If they don't match, bdist_wininst gives up with the error "install_script 'my-postinstall.py' not found in scripts". At install time, the basename part of gets copied to C:\python22\scripts, regardless of where it was found at pre-build-time, so you always have C:\python22\scripts\my-postinstall.py. But at post-install time, the installer looks for C:\python22\scripts\. That is: --install-script= where it searches --------------------------- ----------------- my-postinstall.py C:\python22\scripts\my-postinstall.py win32\my-postinstall.py C:\python22\scripts\win32\my-postinstall.py (I have verified this with filemon.exe.) But C:\python22\scripts\win32\my-postinstall.py doesn't exist in the post-installation filesystem, because all scripts were copied into c:\python22\scripts, as I already mentioned. In consequence, you have to keep your post-install script in the same directory setup.py is in, or the installer won't be able to find it. As a workaround for this behavior, I keep my postinstall script where I want to but have setup.py copy it to '.' at pre-build time. This is a kludge, and I'm wondering if there's a better way, or if I may be seeing behavior that the distutils masters didn't intend. __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com From theller@python.net Thu Jan 9 03:14:02 2003 From: theller@python.net (Thomas Heller) Date: Thu Jan 9 03:14:02 2003 Subject: [Distutils] --post-install on win32 In-Reply-To: <20030108172336.11068.qmail@web10007.mail.yahoo.com> References: <20030108172336.11068.qmail@web10007.mail.yahoo.com> Message-ID: Cory Dodt writes: > I have been working with the --post-install option to bdist_wininst and > have noticed the following behavior, which appears to be a bug or possibly > a misdesign. The consequence of this behavior is at the end, it will take > some explaining to get there... > > I'm going to use the following terms: > > pre-build time: the moment you issue the command > C:\...\>setup.py bdist_wininst --install-script=x > build time: while build_* is happening > post-install time: after you've run the bdist_wininst installer and gone > through the wizard; the very last page of the wizard, when it runs the > post-install script. > post-install-arg: what you gave as an argument to --install-script=... > > The argument to --install-script at pre-build time has to match an entry > in setup_args['scripts'], that is, if you have > { ... 'scripts': ['my-postinstall.py'] } > You have to provide --install-script=my-postinstall.py but if you have > { ... 'scripts': ['win32/my-postinstall.py'] } > You have to provide --install-script=win32\my-postinstall.py > > If they don't match, bdist_wininst gives up with the error "install_script > 'my-postinstall.py' not found in scripts". > > At install time, the basename part of gets copied to > C:\python22\scripts, regardless of where it was found at pre-build-time, > so you always have C:\python22\scripts\my-postinstall.py. > > But at post-install time, the installer looks for > C:\python22\scripts\. That is: > > --install-script= where it searches > --------------------------- ----------------- > my-postinstall.py C:\python22\scripts\my-postinstall.py > win32\my-postinstall.py C:\python22\scripts\win32\my-postinstall.py > (I have verified this with filemon.exe.) I thought I fixed this bug before Python 2.3a0, but it seems it's not. Which version are you using? Thomas From corydodt@yahoo.com Thu Jan 9 17:04:08 2003 From: corydodt@yahoo.com (Cory Dodt) Date: Thu Jan 9 17:04:08 2003 Subject: [Distutils] --post-install on win32 Message-ID: <20030109180220.97409.qmail@web10008.mail.yahoo.com> With today's distutils I have verified that this bug was already fixed. Sorry for bothering the list! --- Cory Dodt wrote: > Possibly it was fixed. I am using a fairly stale CVS copy. > > I'll try again with today's. > > --- Thomas Heller wrote: > > Cory Dodt writes: > > > > I thought I fixed this bug before Python 2.3a0, but it seems it's not. > > Which version are you using? > > > > Thomas __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com From corydodt@yahoo.com Thu Jan 9 17:49:00 2003 From: corydodt@yahoo.com (Cory Dodt) Date: Thu Jan 9 17:49:00 2003 Subject: [Distutils] --post-install on win32 In-Reply-To: Message-ID: <20030109174422.90763.qmail@web10007.mail.yahoo.com> Possibly it was fixed. I am using a fairly stale CVS copy. I'll try again with today's. --- Thomas Heller wrote: > Cory Dodt writes: > > > I have been working with the --post-install option to bdist_wininst > and > > have noticed the following behavior, which appears to be a bug or > possibly > > a misdesign. The consequence of this behavior is at the end, it will > take > > some explaining to get there... > > > > I'm going to use the following terms: > > > > pre-build time: the moment you issue the command > > C:\...\>setup.py bdist_wininst --install-script=x > > build time: while build_* is happening > > post-install time: after you've run the bdist_wininst installer and > gone > > through the wizard; the very last page of the wizard, when it runs the > > post-install script. > > post-install-arg: what you gave as an argument to --install-script=... > > > > The argument to --install-script at pre-build time has to match an > entry > > in setup_args['scripts'], that is, if you have > > { ... 'scripts': ['my-postinstall.py'] } > > You have to provide --install-script=my-postinstall.py but if you have > > { ... 'scripts': ['win32/my-postinstall.py'] } > > You have to provide --install-script=win32\my-postinstall.py > > > > If they don't match, bdist_wininst gives up with the error > "install_script > > 'my-postinstall.py' not found in scripts". > > > > At install time, the basename part of gets copied > to > > C:\python22\scripts, regardless of where it was found at > pre-build-time, > > so you always have C:\python22\scripts\my-postinstall.py. > > > > But at post-install time, the installer looks for > > C:\python22\scripts\. That is: > > > > --install-script= where it > searches > > --------------------------- > ----------------- > > my-postinstall.py > C:\python22\scripts\my-postinstall.py > > win32\my-postinstall.py > C:\python22\scripts\win32\my-postinstall.py > > (I have verified this with filemon.exe.) > > I thought I fixed this bug before Python 2.3a0, but it seems it's not. > Which version are you using? > > Thomas > __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com From anthony@interlink.com.au Mon Jan 13 01:12:01 2003 From: anthony@interlink.com.au (Anthony Baxter) Date: Mon Jan 13 01:12:01 2003 Subject: [Distutils] installing both packages and (sometimes) modules Message-ID: <200301130610.h0D6A9x16163@localhost.localdomain> For the spambayes project, I have a distutils setup that installs the 'spambayes' package. I also (for 2.2) want it to install copies of 'sets.py' and 'heapq.py' modules into site-packages. Unfortunately distutils will let me have a 'packages' line, or a 'py_modules' line, but not both. Is there an easy way to do this that doesn't involve subclassing a distutils command? Anthony -- Anthony Baxter It's never too late to have a happy childhood. From theller@python.net Mon Jan 13 03:22:02 2003 From: theller@python.net (Thomas Heller) Date: Mon Jan 13 03:22:02 2003 Subject: [Distutils] installing both packages and (sometimes) modules In-Reply-To: <200301130610.h0D6A9x16163@localhost.localdomain> References: <200301130610.h0D6A9x16163@localhost.localdomain> Message-ID: <1y3he9yy.fsf@python.net> Anthony Baxter writes: > For the spambayes project, I have a distutils setup that installs > the 'spambayes' package. I also (for 2.2) want it to install copies > of 'sets.py' and 'heapq.py' modules into site-packages. Unfortunately > distutils will let me have a 'packages' line, or a 'py_modules' line, > but not both. Is there an easy way to do this that doesn't involve > subclassing a distutils command? Not that I know of, but why not use a sublass: ---------- from distutils.command import build_py class my_build_py(build_py.build_py): def run (self): if not self.py_modules and not self.packages: return if self.py_modules: self.build_modules() if self.packages: self.build_packages() self.byte_compile(self.get_outputs(include_bytecode=0)) # run () if __name__ == '__main__': setup(... cmdclass = {"build_py": my_build_py}, ...) ---------- Thomas From just@letterror.com Mon Jan 13 03:48:02 2003 From: just@letterror.com (Just van Rossum) Date: Mon Jan 13 03:48:02 2003 Subject: [Distutils] installing both packages and (sometimes) modules In-Reply-To: <200301130610.h0D6A9x16163@localhost.localdomain> Message-ID: Anthony Baxter wrote: > For the spambayes project, I have a distutils setup that installs > the 'spambayes' package. I also (for 2.2) want it to install copies > of 'sets.py' and 'heapq.py' modules into site-packages. Unfortunately > distutils will let me have a 'packages' line, or a 'py_modules' line, > but not both. Is there an easy way to do this that doesn't involve > subclassing a distutils command? I managed to do something like that by doing this: packages = package_dir = if : packages.append('') package_dir[''] = 'DirContainingExtraTopLevelModules' setup( ... packages = packages, package_dir = package_dir, ) It's still a kludge, as you can only have one such directory. Just From webmaster@pferdemarkt.ws Wed Jan 15 07:29:03 2003 From: webmaster@pferdemarkt.ws (webmaster@pferdemarkt.ws) Date: Wed Jan 15 07:29:03 2003 Subject: [Distutils] Pferdemarkt.ws informiert! Newsletter 01/2003 Message-ID: <200301151223.EAA01042@eagle.he.net> http://www.pferdemarkt.ws Wir sind in 2003 erfolgreich in des neue \"Pferdejahr 2003 gestartet. Für den schnellen Erfolg unseres Marktes möchten wir uns bei Ihnen bedanken. Heute am 15. Januar 2003 sind wir genau 14 Tage Online! Täglich wächst unsere Datenbank um ca. 30 neue Angebote. Stellen auch Sie als Privatperson Ihre zu verkaufenden Pferde direkt und vollkommen Kostenlos ins Internet. Zur besseren Sichtbarmachung Ihrer Angebote können SIe bis zu ein Bild zu Ihrer Pferdeanzeige kostenlos einstellen! Klicken Sie hier um sich direkt einzuloggen http://www.Pferdemarkt.ws Kostenlos Anbieten, Kostenlos Suchen! Direkt von Privat zu Privat! Haben Sie noch Fragen mailto: webmaster@pferdemarkt.ws From distutils-sig@python.org Fri Jan 31 17:24:56 2003 From: distutils-sig@python.org (Albert Chin) Date: Fri Jan 31 17:24:56 2003 Subject: [Distutils] How do I build C++ modules Message-ID: <20030131222137.GB87462@spuckler.il.thewrittenword.com> I built Python with 'cc'. The corresponding C++ compiler is 'CC'. The 'cc' compiler cannot take .cpp (C++) files as input. How do I force disutils to build a module with 'CC' even though Python was built with 'cc'? I'm using Python 2.1.2 and 2.2.2. -- albert chin (china@thewrittenword.com) From knight@baldmt.com Fri Jan 31 23:31:15 2003 From: knight@baldmt.com (Steven Knight) Date: Fri Jan 31 23:31:15 2003 Subject: [Distutils] extended options not overriding user-specified values Message-ID: I'm trying to extend the install, install_lib and install_scripts commands in distutils to support some extra options that, when specified, will let me select some intelligent defaults for attributes like install_lib and install_scripts. I've figured out that I can extend the recognized options by subclassing the command classes along the following lines: class install(distutils.command.install.install): boolean_options = _install.boolean_options + [ 'my-new-option' ] def initialize_options(self): _install.initialize_options(self) self.my_new_option = 0 def finalize_options(self): _install.finalize_options(self) # manipulate attributes based on my_new_option But here's the part that has me baffled: Since the point of "my_new_option" above is to select intelligent defaults for install_lib and install_scripts, I *don't* want to override the user who explicitly specifies "--install-{lib,scripts}=/some/dir" on the command line. So... is there any way can I tell, in my finalize_options(), whether install_lib and install_scripts were set by the user or not? I've picked my way through the code, but I don't see anything that seems to support this directly. Perhaps there's a way I could use parse_command_line() or _parse_command_opts() to figure this out? If not, I suppose I could always do it by hand, too... I'd rather not code up one solution only to find that I just didn't grok that there was a better one staring me in the face. Any advice or pointers would be appreciated. Thanks! --SK