Distutils 0.9.1 Making setup scripts for all my old modules, I see: warning: build_ext: old-style (ext_name, build_info) tuple found in ext_modules for extension '(module_name)'-- please convert to Extension instance Say what? I don't remember this on the list, and I can't find any docs, so I decipher distutils extension.py and make something like: myExt=Extension('module_name', ['path/source.c'], libraries=['mylib']) and then I get: Traceback (most recent call last): File "setup.py", line 64, in ? ext_modules=prpwdExtension File "/opt/python-1.6b1/lib/python1.6/distutils/core.py", line 112, in setup dist.run_commands () File "/opt/python-1.6b1/lib/python1.6/distutils/dist.py", line 776, in run_commands self.run_command (cmd) File "/opt/python-1.6b1/lib/python1.6/distutils/dist.py", line 797, in run_command cmd_obj.run () File "/opt/python-1.6b1/lib/python1.6/distutils/command/build.py", line 116, in run if self.distribution.has_ext_modules(): File "/opt/python-1.6b1/lib/python1.6/distutils/dist.py", line 807, in has_ext_modules return self.ext_modules and len (self.ext_modules) > 0 AttributeError: 'Extension' instance has no attribute '__len__' I went back to the "old-style" way since it works, but I'd like to buy a clue on how to properly use an Extension instance. Anyone have a link to a doc or a list message somewhere? Thanks, Mark Alexander mwa@gate.net
On Thu, Aug 24, 2000 at 01:42:40PM -0400, Mark W. Alexander wrote:
ext_modules=prpwdExtension
I believe this should be a list, so try ext_modules = [prpwdExtension]. The Distutils code should probably check for common errors like this and print friendlier error messages. --amk
Oops, I left out some info. prpwdExtension is set as: prpwdExtension = [('shadowpwd.prpwd._prpwd', {'sources':['shadowpwd/prpwd/prpwd_wrap.c'], 'libraries': ['sec'] } )] So it is a list when I get the warning. It also works fine, but the warning implies that I should be using the Extension class instead of the list. Mark Alexander mwa@gate.net On Thu, 24 Aug 2000, Andrew Kuchling wrote:
Date: Thu, 24 Aug 2000 14:00:36 -0400 From: Andrew Kuchling <akuchlin@mems-exchange.org> To: distutils-sig@python.org Subject: Re: [Distutils] Was I asleep? (Extension instance message)
On Thu, Aug 24, 2000 at 01:42:40PM -0400, Mark W. Alexander wrote:
ext_modules=prpwdExtension
I believe this should be a list, so try ext_modules = [prpwdExtension]. The Distutils code should probably check for common errors like this and print friendlier error messages.
--amk
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://www.python.org/mailman/listinfo/distutils-sig
On 24 August 2000, Mark W. Alexander said:
warning: build_ext: old-style (ext_name, build_info) tuple found in ext_modules for extension '(module_name)'-- please convert to Extension instance
Say what?
I don't remember this on the list, and I can't find any docs, so I decipher distutils extension.py and make something like:
Hmm, I *thought* I mentioned it on the list. There was no great hue and cry, so I didn't think it was a big deal. It is documented, but only in the CVS docs -- I am still trying to work up the courage to beat Perl and LaTeX2HTML into submission. Take a look in any of the example setup scripts in examples, eg. examples/xml_setup.py has: ext_modules = [Extension('sgmlop', ['extensions/sgmlop.c']), Extension('xml.unicode.wstrop', ['extensions/wstrop.c']), Extension('xml.parsers.pyexpat', ['extensions/pyexpat.c', 'extensions/expat/xmltok/xmltok.c', 'extensions/expat/xmltok/xmlrole.c', 'extensions/expat/xmlwf/xmlfile.c', 'extensions/expat/xmlwf/xmlwf.c', 'extensions/expat/xmlwf/codepage.c', 'extensions/expat/xmlparse/xmlparse.c', 'extensions/expat/xmlparse/hashtable.c', FILEMAP_SRC,], define_macros = [('XML_NS', None)], include_dirs = [ 'extensions/expat/xmltok', 'extensions/expat/xmlparse' ], ) ] which I think you'll agree is a lot more readable (and writeable) than the old hairy list-of-tuples-of-dicts (or whatever it was) mess. Greg -- Greg Ward - Unix nerd gward@python.net http://starship.python.net/~gward/ What happens if you touch these two wires tog--
Hmm.... First, thanks! Second, I swear this is exactly what I did and it didn't work. Just now I went back and commented out the "old-style" and uncommented my Extension class attempt and it worked just fine. Must of been a brain fart.... Third, yes it's alot cleaner and clearer. And finally....Documentation. What's with perl and LaTeX2HTML? My need for documentation is growing since I'm trying to do bdist_pkgtool and bdist_sdux in, well let's just say a less casual approach. bdist_pkgtool has stuff hard-coded ("build/lib", etc) because I didn't have time to really figure out the correct ways to find information. Is there any hacker's guide to distutils info any where (beside's the source, of course!). Especially what bdist_* has available.... Mark Alexander mwa@gate.net On Thu, 24 Aug 2000, Greg Ward wrote:
Date: Thu, 24 Aug 2000 22:45:29 -0400 From: Greg Ward <gward@python.net> To: distutils-sig@python.org Subject: Re: [Distutils] Was I asleep? (Extension instance message)
On 24 August 2000, Mark W. Alexander said:
warning: build_ext: old-style (ext_name, build_info) tuple found in ext_modules for extension '(module_name)'-- please convert to Extension instance
Say what?
I don't remember this on the list, and I can't find any docs, so I decipher distutils extension.py and make something like:
Hmm, I *thought* I mentioned it on the list. There was no great hue and cry, so I didn't think it was a big deal. It is documented, but only in the CVS docs -- I am still trying to work up the courage to beat Perl and LaTeX2HTML into submission.
Take a look in any of the example setup scripts in examples, eg. examples/xml_setup.py has:
ext_modules = [Extension('sgmlop', ['extensions/sgmlop.c']), Extension('xml.unicode.wstrop', ['extensions/wstrop.c']), Extension('xml.parsers.pyexpat', ['extensions/pyexpat.c', 'extensions/expat/xmltok/xmltok.c', 'extensions/expat/xmltok/xmlrole.c', 'extensions/expat/xmlwf/xmlfile.c', 'extensions/expat/xmlwf/xmlwf.c', 'extensions/expat/xmlwf/codepage.c', 'extensions/expat/xmlparse/xmlparse.c', 'extensions/expat/xmlparse/hashtable.c', FILEMAP_SRC,], define_macros = [('XML_NS', None)], include_dirs = [ 'extensions/expat/xmltok', 'extensions/expat/xmlparse' ], ) ]
which I think you'll agree is a lot more readable (and writeable) than the old hairy list-of-tuples-of-dicts (or whatever it was) mess.
Greg -- Greg Ward - Unix nerd gward@python.net http://starship.python.net/~gward/ What happens if you touch these two wires tog--
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://www.python.org/mailman/listinfo/distutils-sig
Attached is the first pass of bdist_sdux.py for making binary packages for HP-UX Software distributor (SD-UX). I took a little more time on this than on bdist_pkgtool, but not much, and I still claim very little knowledge about how I'm "supposed" to be doing this, so anyone who has time to take a look and advise me on better ways please (PLEASE!) do so. Anyway, this creates relocatable packages for HP, although they install by default into the site-packages path as discovered on the BUILD machine. The quick way to get proper re-location on the install machine would be to provide a shell wrapper with the package that would find the proper install directory and relocate the package appropriately. Or, just make the admin tell it to go elsewhere manually. The problem with this is HP's concept of a "depot" allows for the creation of a repository somewhere on the network where packages can be installed from. To use this effectively, packages should just do the right thing whenever they can. So... bdist_sdux created packages can't be put in a depot unless all machines installed python in the same place. I'm still trying to figure out a gracefull way to trick SD-UX into putting them in the right place, maybe making a pseudo-package that installs the python package and then uninstalls itself. Any HP users out there with ideas, please email me. For now, my choice is to just cope ;| Although I'm not totally satisfied with the state of either bdist-pkgtool or bdist_sdux, they sufficiently "scratch my itch" for now, so I'm not likely to make any changes of my own accord for some time. If anyone else start's using them, (or even reading them) however, I'll work any bugs or suggestions for improvement. Mark mwa@gate.net
On 25 August 2000, Mark W. Alexander said:
And finally....Documentation. What's with perl and LaTeX2HTML?
Perl's not so bad, it's LaTeX2HTML. You can extend it by writing Perl subroutines -- not so bad if you know Perl, *except* that the interface is bizarre, undocumented, and subject to random changes. I think it boils down to this: to process the Python docs, you need to be using a specific beta version of LaTeX2HTML from mid-1998, which in turn necessitates using Perl 5.005 -- L2H, or at least this specific beta from mid-1998, bombs under Perl 5.6. At least, I think that's what the situation is.
My need for documentation is growing since I'm trying to do bdist_pkgtool and bdist_sdux in, well let's just say a less casual approach. bdist_pkgtool has stuff hard-coded ("build/lib", etc) because I didn't have time to really figure out the correct ways to find information. Is there any hacker's guide to distutils info any where (beside's the source, of course!). Especially what bdist_* has available....
Alas, there is no guide to the internals. ;-( Use The Source, Luke. Spend some time with bdist_dumb; it's much simpler than bdist_rpm, and was mainly written 1) to demonstrate that built distributions were indeed possible, and 2) as an example to authors of new bdist_* commands. Greg -- Greg Ward - programmer-at-large gward@python.net http://starship.python.net/~gward/ This message transmitted with 100% recycled electrons.
Greg Ward writes:
On 25 August 2000, Mark W. Alexander said:
And finally....Documentation. What's with perl and LaTeX2HTML?
Perl's not so bad, it's LaTeX2HTML. You can extend it by writing Perl
LaTeX2HTML is *really* bad to deal with. Ross refuses to document the API used in creating extensions because then he'd have to freeze the API -- obviously legacy code isn't worth much to him, or it would be frozen, or at least change in more planned ways. So the reality is that "anything goes" for extensions which makes it even harder than to work with a changing but documented API. And we do some pretty serious under-the-hood stuff.
subroutines -- not so bad if you know Perl, *except* that the interface is bizarre, undocumented, and subject to random changes. I think it boils down to this: to process the Python docs, you need to be using a specific beta version of LaTeX2HTML from mid-1998, which in turn necessitates using Perl 5.005 -- L2H, or at least this specific beta from mid-1998, bombs under Perl 5.6.
To use the docs and tools from the CVS repository, you need LaTeX2HTML 99.2 beta 8; I'm not sure what the restrictions on the Perl version are, but 5.6 works. On the other hand, there are still things that don't work with the newer version of LaTeX2HTML that used to work. Like the list of module synopses at the beginnings of chapters in the library reference, and the Module Index. I'll get these working by the time Python 2.0 is released.
Alas, there is no guide to the internals. ;-( Use The Source, Luke.
Now, didn't I tell you you needed to write this? ;)
Spend some time with bdist_dumb; it's much simpler than bdist_rpm, and was mainly written 1) to demonstrate that built distributions were indeed possible, and 2) as an example to authors of new bdist_* commands.
I hope it's well commented! -Fred -- Fred L. Drake, Jr. <fdrake at beopen.com> BeOpen PythonLabs Team Member
participants (4)
-
Andrew Kuchling -
Fred L. Drake, Jr. -
Greg Ward -
Mark W. Alexander