From gward@python.net Wed Aug 2 02:33:45 2000 From: gward@python.net (Greg Ward) Date: Tue, 1 Aug 2000 21:33:45 -0400 Subject: [Distutils] Re: CygwinCCompiler, msvc hack, BCPPCompiler In-Reply-To: <398014F5.728445EE@gmx.de>; from R.Liebscher@gmx.de on Thu, Jul 27, 2000 at 12:54:45PM +0200 References: <000401bfe1ed$0d778a60$2937ba8c@nhv> <20000629191650.D682@beelzebub> <395CB802.7CE487C@gmx.de> <20000704101613.A1881@beelzebub> <396465FC.3FD96CAD@gmx.de> <20000708212019.A4248@beelzebub> <396C71A1.198D8C2C@gmx.de> <397A344D.E3837BD6@gmx.de> <20000726210640.A1506@beelzebub> <398014F5.728445EE@gmx.de> Message-ID: <20000801213345.A600@beelzebub> On 27 July 2000, Rene Liebscher said: > * msvc.patch: changes msvccompiler.py and build_ext.py > (You need its changes in build_ext.py to get the > other two compilers work properly after applying their patches.) OK, I've checked that one in. One problem: I don't like the fact that Extension.ext_symbols can now be None -- you took away the "or []" in the constructor, which is inconsistent with every other attribute of Extension. Since this class is just a pile of data without much behaviour, I value convenience -- don't have to check for None, just assume everything is a list -- over completeness. And I really dislike the inconsistency you've introduced. I can see why None-ness is needed, though: in build_ext.get_export_symbols(), you can tell if 'export_symbols' was supplied at all by looking for None. But if an empty list was supplied, isn't that wrong? If export_symbols is an empty list, then we'll go ahead and build the .pyd with nothing in the export list, not even "init" + module_name. In the general-purpose library-building code (msvccompiler.py), this would be right: but this code is geared towards building Python extensions, and if a Python extension doesn't export its init function, what's the point? I suggest changing build_ext.get_export_symbols() from this: if ext.export_symbols is None: return [] else: return ext.export_symbols to this: initfunc_name = "init" + string.split(ext.name,'.')[-1] if initfunc_name not in ext.export_symbols: ext.export_symbols.append(initfunc_name) which of course assumes that ext.export_symbols is a list, which will be valid as long as we put back the "or []" in Extension's constructor. Sound reasonable? > * bcpp.patch: changes bcppcompiler.py OK, I'm going over this one now. > # either exchange python15.lib in the python libs directory against > # a Borland-like one, or create one with name bcpp_python15.lib > # there and remove the pragmas from config.h > #libraries.append ('mypylib') > libraries.append ('import32') > libraries.append ('cw32mt') I don't understand. You commented out the use of 'mypylib' and added the comment. Can you explain what's going on here, please? If we need to make changes in Python (1.6 or 2.0!) to support Borland C++ better, now's the time to do it. > ld_args.extend([',',output_filename]) > # no map file > ld_args.extend([',']) > # start libraries > ld_args.extend([',']) This code seems fishy to me. First of all, why are you using 'extend([x])' when 'append(x)' would do the same thing? And second, are those commas really supposed to be whole words in the arg list? I don't know how things work in Windows, but in Unix doing that would mean that the compiler's argv list would look like [..., ',', 'foo.pyd', ',', ',', ...] which is really strange. I suspect that really should be coded as ld_args.append(",%s,," % output_filename) which would make an argv of [..., ',foo.pyd,,', ...] which seems a) more sensible, and b) looks like the Borland C++ command lines I remember from 7-8 years ago. So: which arguments really have to be separate words (ie. separate elements of the argv[] array that BCPP will ultimately have to process)? Does this question even make sense on a DOS/Windows environment, ie. is the argument delineation implicit in the 'spawn()' call preserved in the child process? > - def find_library_file (self, dirs, lib): > - > + def find_library_file (self, dirs, lib, debug=0): > + # find library file Umm, the 'debug' flag is not part of the official CCompiler interface to 'find_library_file()'. Is this really necessary? Should MSVCCompiler do it as well? If so, then the interface should change. Looks like 'find_library_file()' is used in BCPPCompiler to give preference to bcpp_xxx.lib; is this really important? Where does it arise? Is this a common convention, or a Python-only convention? (Or a Liebscher-only convention? ;-) I also note some lines of code > 80 columns in this file. Please keep all code under 75 columns! > * cygwin.patch: the latest version of cygwinccompiler.py, > some changes in spawn.py (I moved a port of spawn_nt() > in a separate function find_executable(), I use this > in my compiler class) and it removes from sysconfig.py > g['CC'] = "cc" and this other stuff which UnixCCompiler > needed in its old version. In future, please supply a checkin comment for cygwinccompiler.py -- I'll figure out this time myself, but as long as the code is your responsibility, so too are the checkin messages. Other comments... * why are {gcc,ld,dllwrap}_version class attributes? They are derived from the particular compiler used by a particular instance of the class, and when you set them in the constructor they become instance attributes. So why even define them as class attrs? * 'check_config_h()' really should return meaningful strings instead of magic numbers. Comment or no, any occurence of a bare integer in non-arithmetic circumstances is a magic number in my book, and I don't like magic numbers. * again, there are lines > 80 columns! (I've fixed most of these.) * you shouldn't write to stdout or stderr in a compiler class -- use the 'announce()' method. I should really add a 'debug_print()' method; that would be handy. * I don't like using 'list(foo)' to make a copy of a list 'foo' -- either 'foo[:]' or 'copy(foo)' (from the standard copy module) is acceptable. * when assigning to a tuple, please use parens: (a, b) = ... not a, b = ... OK, I've checked it in with a few tweaks (fixed long lines and tuple assignments, mostly). Please submit a new patch fixing the above problems. > And some cosmetic changes: > Almost all messages start with a verb, but this one in install_lib.py > starts with a noun. [...] > - skip_msg = "byte-compilation of %s skipped" % f > + skip_msg = "skipping byte-compilation of %s" % f Thanks! At the cost of one extra character, I'll take it. That has been a very teeny tiny irritant for a while now. Greg -- Greg Ward - Linux geek gward@python.net http://starship.python.net/~gward/ I don't understand the HUMOUR of the THREE STOOGES!! From gward@python.net Wed Aug 2 02:39:38 2000 From: gward@python.net (Greg Ward) Date: Tue, 1 Aug 2000 21:39:38 -0400 Subject: [Distutils] sdist.py::findall chokes on broken links In-Reply-To: ; from calvin@cs.uni-sb.de on Thu, Jul 27, 2000 at 12:51:15PM +0200 References: <20000726215129.D1506@beelzebub> Message-ID: <20000801213938.B600@beelzebub> On 27 July 2000, Bastian Kleineidam said: > if the Distutils bail out on broken links we will run into problems with > Debian packages. I am calling the dh_undocumented script which generates > the link > debian/tmp/usr/share/man/man1/linkchecker.1.gz -> ../man7/undocumented.7.gz > which is broken only temporarily, but not after installing the generated > .deb package. Oh, bother! OK, I'll try to come up with a decent fix for this. Now that the "grope about the filesystem looking for stuff" code has been factored out of sdist.py, I think this is the place to detect broken links. Then it's just a question of making sure the "find all modules in package X" code in build_py.py uses file_list.py. I think this will have to wait until after 0.9.1, unless someone presents me with an irresistably perfect patch in the next 24 hours. Greg -- Greg Ward - geek-on-the-loose gward@python.net http://starship.python.net/~gward/ I just heard the SEVENTIES were over!! And I was just getting in touch with my LEISURE SUIT!! From gward@python.net Wed Aug 2 03:03:49 2000 From: gward@python.net (Greg Ward) Date: Tue, 1 Aug 2000 22:03:49 -0400 Subject: [Distutils] New code snapshot In-Reply-To: ; from cwebster@nevada.edu on Mon, Jul 31, 2000 at 05:39:52PM -0700 References: <20000729215720.A1465@beelzebub> Message-ID: <20000801220349.B1034@beelzebub> [cc'd to the distutils-sig: Corran and I have exchanged private email about Distutils on the Mac in the past; in fact, all the Mac-supporting code currently in the Distutils is thanks to Corran. I think it's worth violating netiquette a bit to inform the rest of the sig that Corran is working on Distutils-on-Mac support, to see if there are any other Mac people lurking out there, wishing Distutils worked on Mac OS. Please speak up!] On 31 July 2000, Corran Webster said: > I've finally gotten back to a position where I can spend a little time > looking at distutils for the macintosh again. I took this snapshot an > dtried a simple install as a first step to getting things going again. Excellent! > There were a few bugs, one of which is serious, and I don't know what the > solution is. > > Firstly an easy bug: on line 80 of sysconfig.py, "platform_specific" needs > to be changed to "plat_specific". Yep, too easy. Fixed -- thanks. > The major bug has to do with macintosh paths. The notation to indicate > that you move up one level in the directory heirarchy on Mac OS is a double > colon, ie. > > dir1:dir2::dir3:file > > is the same as "dir1:dir3:file" in the same way that > "dir1/dir2/../dir3/file" is the same as "dir1/dir3/file" on posix systems. > This is important, because sometimes macintosh paths are specified with a > trailing ":" if it is a directory, and sometimes they are not. For > example, on my system, Interesting. "Trailing slash means directory" is a (weak) convention on Unix as well, but I've avoided it in the Distutils because it breaks on Windows. (In particular: if os.path.isdir("\\foo\\bar") is true, os.path.isdir("\\foo\\bar\\") is not. ISTR that this may be fixed in the current CVS Python, but don't remember for sure.) > >>> import sys > >>> sys.prefix > 'Macintosh HD:Applications:Python 1.5.2c1:' > >>> sys.path > ['Macintosh HD:Applications:Python 1.5.2c1:', 'Macintosh > HD:Applications:Python 1.5.2c1:', 'Macintosh HD:Applications:Python > 1.5.2c1:Lib', 'Macintosh HD:Applications:Python 1.5.2c1:Lib:site-packages', > 'Macintosh HD:Applications:Python 1.5.2c1:Lib:lib-tk', ... etc ] Well, one thing I learn from this is that you really ought to upgrade to 1.5.2final. ;-) > Notice how sometimes the paths have trailing ":" and sometimes they don't. I guess the convention is a weak one in Mac OS too. > While os.path.join does the right thing no matter how the paths end, but > os.path.normpath does not do anything, one way or the other. This leads to > two problems: > > 1. with the install schemes of the install.py module, you get something like: > > "$base:Libs" expanding to "Macintosh HD:Applications:Python 1.5.2c1::Libs" > > which is the same as "Macintosh HD:Applications:Libs", ie. very much the > wrong place. Ahh, I see. You can be lazy on Unix, because "foo//bar" is the same as "foo/bar" (except in Emacs!). If I understand correctly, on Mac OS it's as though "foo//bar" was the same as "foo/../bar", which makes life a bit harder. I try hard not to rely on the collapsibility of "//" though -- just seems a bit dodgy (and kernel-dependent). Note that on Unix: >>> os.path.normpath("foo//bar") 'foo/bar' >>> os.path.normpath("foo//bar/") 'foo/bar' which argues in favour of fixing normpath to strip trailing colons on Mac OS. > 2. I hacked a fix for 1 (see below), but this led to a second problem: just > because you do os.path.normpath, you still can't assume that two different > paths aren't really the same. The result of this was having install.py > tell me that distutils wasn't installed somewhere in sys.path, when in fact > it was. This may have other consequences where distutils compares paths to > each other. Ick! The whole point of normpath, as I see it, is to guarantee that string equality means filesystem equality. If it doesn't do that on Mac OS, then it's broken. Offhand, I can't think of other places where Distutils compares paths. Maybe the code that excludes setup.py from the modules to install -- that's in build_py.py; see the 'find_package_modules()' method. > (a) The simple hack I used to get around problem 1 was simply to expand the > variable substitution system to accept "${base}Lib". The problem with this > is that we can't guarantee that base will end with ":", so we could still > get mangled pathnames. Yup. > (b) A more robust solution is probebly to write a normpath for distutils > which guarantees that pathnames either do or do not end in a ":" on the > mac. Not sure the best place to put it, or how much code this is going to > affect, but it could be a real pain to get right. > > (c) Lobby for normpath to be "fixed" on the mac - almost certainly doable, > but leaves the problem of 1.5.* versions not working properly. I think we can do both (b) and (c). Eg. somewhere we'd say: if python < 1.6 and Mac OS: # maybe 2.0 def normpath (...): ... os.path.normpath = normpath and hopefully the "Distutils-specific" normpath would be right there in macpath.py in 2.0 (maybe 1.6). Can you whip up a patch to macpath.py and submit it to the SourceForge patch manager? (Or just mail it to me if you don't want to deal with SF.) Make sure you add a test too! > (d) Some change to the install scheme mechanism so that it uses > os.path.join(). For example, use a list or tuple of strings, rather than a > single string: > > 'mac': { > 'purelib': ('$base', 'Lib'), > 'platlib': ('$base', 'Mac', 'PlugIns'), > 'headers': ('$base', 'Include', '$dist_name'), > 'scripts': ('$base', 'Scripts'), > 'data' : ('$base',), > } I'm not keen on that -- getting that stuff working was fairly tricky (although not nearly as tricky as designing it!), and I really don't want to revisit it. Greg -- Greg Ward - Unix bigot gward@python.net http://starship.python.net/~gward/ I'd like some JUNK FOOD ... and then I want to be ALONE -- From gward@python.net Wed Aug 2 03:12:15 2000 From: gward@python.net (Greg Ward) Date: Tue, 1 Aug 2000 22:12:15 -0400 Subject: [Distutils] Another snapshot! Message-ID: <20000801221215.A1183@beelzebub> New code snapshot available at http://starship.python.net/~gward/python/distutils.html This adds Rene Liebscher's patches to the DOS/Windows compiler classes and build_ext.py. Please try these out -- there are some small but far-reaching changes in there! Also a few tiny bugs fixed. Greg -- Greg Ward - Linux weenie gward@python.net http://starship.python.net/~gward/ Could I have a drug overdose? From cwebster@nevada.edu Wed Aug 2 07:33:11 2000 From: cwebster@nevada.edu (Corran Webster) Date: Tue, 1 Aug 2000 23:33:11 -0700 Subject: [Distutils] New code snapshot In-Reply-To: <20000801220349.B1034@beelzebub> References: ; from cwebster@nevada.edu on Mon, Jul 31, 2000 at 05:39:52PM -0700 <20000729215720.A1465@beelzebub> Message-ID: --============_-1246924501==_============ Content-Type: text/plain; charset="us-ascii" At 10:03 PM -0400 1/8/00, Greg Ward wrote: > [cc'd to the distutils-sig: Corran and I have exchanged private email > about Distutils on the Mac in the past; in fact, all the Mac-supporting > code currently in the Distutils is thanks to Corran. I think it's worth > violating netiquette a bit to inform the rest of the sig that Corran is > working on Distutils-on-Mac support, to see if there are any other Mac > people lurking out there, wishing Distutils worked on Mac OS. Please > speak up!] I agree that this should probably be discussed here... indeed any additional insight would be useful at this point. Unfortunately, I just did some mucking around with os and os.path on the mac, and things are going to be very ugly I fear... > > The major bug has to do with macintosh paths. The notation to indicate > > that you move up one level in the directory heirarchy on Mac OS is a double > > colon, ie. > > > > dir1:dir2::dir3:file > > > > is the same as "dir1:dir3:file" in the same way that > > "dir1/dir2/../dir3/file" is the same as "dir1/dir3/file" on posix systems. > > This is important, because sometimes macintosh paths are specified with a > > trailing ":" if it is a directory, and sometimes they are not. For > > example, on my system, > > Interesting. "Trailing slash means directory" is a (weak) convention on > Unix as well, but I've avoided it in the Distutils because it breaks on > Windows. (In particular: if os.path.isdir("\\foo\\bar") is true, > os.path.isdir("\\foo\\bar\\") is not. ISTR that this may be fixed in > the current CVS Python, but don't remember for sure.) Unfortunately, it seems like sometimes the trailing ":" is required. To explain why, I need to explain a little bit more about mac pathnames. On the mac, a path starting with a colon is relative, while one which doesn't start with a colon is absolute (ie. the reverse of the posix convention), _unless_ it's just a single name (ie. no colons whatsoever) in which case it's relative. The end result of this is that "Macintosh HD" refers to a file in the local directory called "Macintosh HD" (as does ":Macintosh HD"), while "Macintosh HD:" refers to the root directory of the hard disk "Macintosh HD". However, "Macintosh HD:Applications:" and "Macintosh HD:Applications" are the same thing as each other. Similarly ":Macintosh HD:Applications:" and ":Macintosh HD:Applications" are the same as each other. This seems to be a system-level convention (ie. we aren't going to be able to change it). Observe also: >>> os.path.join("Macintosh HD", "Applications") ':Macintosh HD:Applications' >>> os.path.join("Macintosh HD:", "Applications") 'Macintosh HD:Applications' There's a similar problem with ":", "::", etc. Removing a trailing ":" in these cases directly affects the meaning. > > >>> import sys > > >>> sys.prefix > > 'Macintosh HD:Applications:Python 1.5.2c1:' > > >>> sys.path > > ['Macintosh HD:Applications:Python 1.5.2c1:', 'Macintosh > > HD:Applications:Python 1.5.2c1:', 'Macintosh HD:Applications:Python > > 1.5.2c1:Lib', 'Macintosh HD:Applications:Python 1.5.2c1:Lib:site-packages', > > 'Macintosh HD:Applications:Python 1.5.2c1:Lib:lib-tk', ... etc ] > > Well, one thing I learn from this is that you really ought to upgrade to > 1.5.2final. ;-) 1.5.2c1 _is_ 1.5.2final on the mac ;) > > Notice how sometimes the paths have trailing ":" and sometimes they don't. > > I guess the convention is a weak one in Mac OS too. Yes and no :( > Note that on Unix: > > >>> os.path.normpath("foo//bar") > 'foo/bar' > >>> os.path.normpath("foo//bar/") > 'foo/bar' > > which argues in favour of fixing normpath to strip trailing colons on > Mac OS. Having looked at this, I can see why Mac normpath can't just strip trailing colons. However, the cases where we have to leave a trailing colon are fairly easily identified (ie. paths which have just one ":" and it's at the end should have the trailing colon left intact, as should paths which are entirely colons...) Another solution would be to leave trailing ":" on known directories, but this would fail for working with directory paths prior to their actual creation. > > 2. I hacked a fix for 1 (see below), but this led to a second problem: just > > because you do os.path.normpath, you still can't assume that two different > > paths aren't really the same. The result of this was having install.py > > tell me that distutils wasn't installed somewhere in sys.path, when in fact > > it was. This may have other consequences where distutils compares paths to > > each other. > > Ick! The whole point of normpath, as I see it, is to guarantee that > string equality means filesystem equality. If it doesn't do that on Mac > OS, then it's broken. I have to agree with this. > Offhand, I can't think of other places where Distutils compares paths. > Maybe the code that excludes setup.py from the modules to install -- > that's in build_py.py; see the 'find_package_modules()' method. OK. Hopefully a suitable replacement for normpath will do the trick - just grep for "import os" and patch it in... > > (b) A more robust solution is probebly to write a normpath for distutils > > which guarantees that pathnames either do or do not end in a ":" on the > > mac. Not sure the best place to put it, or how much code this is going to > > affect, but it could be a real pain to get right. > > > > (c) Lobby for normpath to be "fixed" on the mac - almost certainly doable, > > but leaves the problem of 1.5.* versions not working properly. > > I think we can do both (b) and (c). Eg. somewhere we'd say: > > if python < 1.6 and Mac OS: # maybe 2.0 > def normpath (...): > ... > os.path.normpath = normpath > > and hopefully the "Distutils-specific" normpath would be right there in > macpath.py in 2.0 (maybe 1.6). > > Can you whip up a patch to macpath.py and submit it to the SourceForge > patch manager? (Or just mail it to me if you don't want to deal with > SF.) Make sure you add a test too! I think I have a suitable replacement function (see the attachment normpath.py) and test suite. I'll patch it into macpath.py and see if I can submit it to sourceforge (I assume that macpath.py is part of the stuff archived there, rather than the macpython CVS archive - if not I'll forward stuff to Jack Jansen). Even with this improvement, we're not out of the woods. This fixes problem 2, but we'll still need to worry about substituting correctly in the cases where we have a trailing ":". At least these shouldn't be too hard to detect - I think it's just install.py that needs to take this into account, since os.path.join() is used everywhere else, right? I'll fiddle with this in the next day or two. > > (d) Some change to the install scheme mechanism so that it uses > > os.path.join(). For example, use a list or tuple of strings, rather than a > > single string: > > > > 'mac': { > > 'purelib': ('$base', 'Lib'), > > 'platlib': ('$base', 'Mac', 'PlugIns'), > > 'headers': ('$base', 'Include', '$dist_name'), > > 'scripts': ('$base', 'Scripts'), > > 'data' : ('$base',), > > } > > I'm not keen on that -- getting that stuff working was fairly tricky > (although not nearly as tricky as designing it!), and I really don't > want to revisit it. Understandably. I think a solution is in sight. Regards, Corran --============_-1246924501==_============ Content-Type: text/plain; name="normpath.py"; charset="us-ascii" Content-Disposition: attachment; filename="normpath.py" import string def normpath(s): """Normalize a pathname. Will return the same result for equivalent paths.""" if ":" not in s: return ":"+s comps = string.splitfields(s, ":") i = 1 while i < len(comps)-1: if comps[i] == "" and comps[i-1] != "": if i > 1: del comps[i-1:i+1] i = i-1 else: # best way to handle this is to raise an exception raise norm_error, 'path starts with volume::' else: i = i + 1 print i, comps s = string.join(comps, ":") # remove trailing ":" except for ":" and "Volume:" if s[-1] == ":" and len(comps) > 2 and s != ":"*len(s): s = s[:-1] return s def _test_normpath(): pass if __name__ == "__main__": _test_normpath() --============_-1246924501==_============ Content-Type: text/plain; name="test_normpath.py"; charset="us-ascii" Content-Disposition: attachment; filename="test_normpath.py" from test_support import * import normpath errors = 0 def testit(name, value, expected): if value != expected: raise TestFailed, '%s returned %f, expected %f'%\ (name, value, expected) testit("normpath", normpath.normpath(":"), ":") testit("normpath", normpath.normpath("::"), "::") testit("normpath", normpath.normpath(":::"), ":::") testit("normpath", normpath.normpath("test"), ":test") testit("normpath", normpath.normpath(":test"), ":test") testit("normpath", normpath.normpath("test:"), "test:") testit("normpath", normpath.normpath(":test:test1:"), ":test:test1") testit("normpath", normpath.normpath("test:test1:"), "test:test1") testit("normpath", normpath.normpath(":test::"), ":") testit("normpath", normpath.normpath(":test:::"), "::") testit("normpath", normpath.normpath(":test:::test1:"), "::test1") testit("normpath", normpath.normpath(":test:test1::"), ":test") testit("normpath", normpath.normpath("test:test1::"), "test:") testit("normpath", normpath.normpath(":test:test1:::"), ":") if errors: print str(errors) + " errors." else: print "No errors. Thank your lucky stars." --============_-1246924501==_============-- From gward@python.net Thu Aug 3 02:30:16 2000 From: gward@python.net (Greg Ward) Date: Wed, 2 Aug 2000 21:30:16 -0400 Subject: [Distutils] New code snapshot In-Reply-To: ; from cwebster@nevada.edu on Tue, Aug 01, 2000 at 11:33:11PM -0700 References: ; <20000729215720.A1465@beelzebub> <20000801220349.B1034@beelzebub> Message-ID: <20000802213016.A731@beelzebub> On 01 August 2000, Corran Webster said: > Unfortunately, it seems like sometimes the trailing ":" is required. To > explain why, I need to explain a little bit more about mac pathnames. On > the mac, a path starting with a colon is relative, while one which doesn't > start with a colon is absolute (ie. the reverse of the posix convention), > _unless_ it's just a single name (ie. no colons whatsoever) in which case > it's relative. The end result of this is that "Macintosh HD" refers to a > file in the local directory called "Macintosh HD" (as does ":Macintosh > HD"), while "Macintosh HD:" refers to the root directory of the hard disk > "Macintosh HD". > > However, "Macintosh HD:Applications:" and "Macintosh HD:Applications" are > the same thing as each other. Similarly ":Macintosh HD:Applications:" and > ":Macintosh HD:Applications" are the same as each other. Ooh, tricky! Now I can see why Mac OS doesn't have a command-line interface: if users can't understand the difference between "/foo" and "foo", how on earth will they understand that "foo" == ":foo" != "foo:", while "foo:bar" == ":foo:bar" (but "foo:bar" == "foo:bar:" and ":foo:bar" == ":foo:bar:"). Aieee! Doesn't quite rival VMS for complexity, but it's getting there. > There's a similar problem with ":", "::", etc. Removing a trailing ":" in > these cases directly affects the meaning. [...] > Having looked at this, I can see why Mac normpath can't just strip trailing > colons. However, the cases where we have to leave a trailing colon are > fairly easily identified (ie. paths which have just one ":" and it's at the > end should have the trailing colon left intact, as should paths which are > entirely colons...) Agreed. Sounds fairly straightforward to implement Mac OS' rules. I've glanced at the patch you mailed me privately and will comment in more detail when I respond to that. > OK. Hopefully a suitable replacement for normpath will do the trick - just > grep for "import os" and patch it in... Changed my mind on that: any Distutils code that uses normpath should use the Distutils version, which will be identical to os.path.normpath except for OS/Python combinations where normpath is broken (specifically, Python 1.5 on Mac OS). Details when I respond to your patch. > Even with this improvement, we're not out of the woods. This fixes problem > 2, but we'll still need to worry about substituting correctly in the cases > where we have a trailing ":". At least these shouldn't be too hard to > detect - I think it's just install.py that needs to take this into account, > since os.path.join() is used everywhere else, right? Ugh. Head hurts. Have to think about this more once normpath is working. Greg -- Greg Ward - Linux nerd gward@python.net http://starship.python.net/~gward/ ... I think I'd better go back to my DESK and toy with a few common MISAPPREHENSIONS ... From cwebster@nevada.edu Thu Aug 3 08:02:38 2000 From: cwebster@nevada.edu (Corran Webster) Date: Thu, 3 Aug 2000 00:02:38 -0700 Subject: [Distutils] New code snapshot In-Reply-To: <20000802213016.A731@beelzebub> References: ; from cwebster@nevada.edu on Tue, Aug 01, 2000 at 11:33:11PM -0700 ; <20000729215720.A1465@beelzebub> <20000801220349.B1034@beelzebub> Message-ID: At 9:30 PM -0400 2/8/00, Greg Ward wrote: > On 01 August 2000, Corran Webster said: > > Unfortunately, it seems like sometimes the trailing ":" is required. To > > explain why, I need to explain a little bit more about mac pathnames. On > > the mac, a path starting with a colon is relative, while one which doesn't > > start with a colon is absolute (ie. the reverse of the posix convention), > > _unless_ it's just a single name (ie. no colons whatsoever) in which case > > it's relative. The end result of this is that "Macintosh HD" refers to a > > file in the local directory called "Macintosh HD" (as does ":Macintosh > > HD"), while "Macintosh HD:" refers to the root directory of the hard disk > > "Macintosh HD". > > > > However, "Macintosh HD:Applications:" and "Macintosh HD:Applications" are > > the same thing as each other. Similarly ":Macintosh HD:Applications:" and > > ":Macintosh HD:Applications" are the same as each other. > > Ooh, tricky! Now I can see why Mac OS doesn't have a command-line > interface: if users can't understand the difference between "/foo" and > "foo", how on earth will they understand that "foo" == ":foo" != "foo:", > while "foo:bar" == ":foo:bar" (but "foo:bar" == "foo:bar:" and > ":foo:bar" == ":foo:bar:"). Aieee! Doesn't quite rival VMS for > complexity, but it's getting there. Actually it's ":foo" == "foo" != "foo:" but ":foo:bar" != "foo:bar" == "foo:bar:" > > There's a similar problem with ":", "::", etc. Removing a trailing ":" in > > these cases directly affects the meaning. > [...] > > Having looked at this, I can see why Mac normpath can't just strip trailing > > colons. However, the cases where we have to leave a trailing colon are > > fairly easily identified (ie. paths which have just one ":" and it's at the > > end should have the trailing colon left intact, as should paths which are > > entirely colons...) > > Agreed. Sounds fairly straightforward to implement Mac OS' rules. I've > glanced at the patch you mailed me privately and will comment in more > detail when I respond to that. For the record, I posted to the MacPython list about this, and it looks like people are happy with the new version of os.path.normpath for the mac, so hopefully that'll be in the CVS tree in a day or two (I'll send it to Jack Jansen to add it to the tree). Regards, Corran From R.Liebscher@gmx.de Thu Aug 3 11:50:07 2000 From: R.Liebscher@gmx.de (Rene Liebscher) Date: Thu, 03 Aug 2000 12:50:07 +0200 Subject: [Distutils] Re: CygwinCCompiler, msvc hack, BCPPCompiler References: <000401bfe1ed$0d778a60$2937ba8c@nhv> <20000629191650.D682@beelzebub> <395CB802.7CE487C@gmx.de> <20000704101613.A1881@beelzebub> <396465FC.3FD96CAD@gmx.de> <20000708212019.A4248@beelzebub> <396C71A1.198D8C2C@gmx.de> <397A344D.E3837BD6@gmx.de> <20000726210640.A1506@beelzebub> <398014F5.728445EE@gmx.de> <20000801213345.A600@beelzebub> Message-ID: <39894E5F.CD288233@gmx.de> Greg Ward wrote: > > On 27 July 2000, Rene Liebscher said: > > * msvc.patch: changes msvccompiler.py and build_ext.py > > (You need its changes in build_ext.py to get the > > other two compilers work properly after applying their patches.) > > OK, I've checked that one in. One problem: I don't like the fact that > Extension.ext_symbols can now be None -- you took away the "or []" in > the constructor, which is inconsistent with every other attribute of > Extension. Since this class is just a pile of data without much > behaviour, I value convenience -- don't have to check for None, just > assume everything is a list -- over completeness. And I really dislike > the inconsistency you've introduced. > > I can see why None-ness is needed, though: in > build_ext.get_export_symbols(), you can tell if 'export_symbols' was > supplied at all by looking for None. But if an empty list was supplied, > isn't that wrong? If export_symbols is an empty list, then we'll go > ahead and build the .pyd with nothing in the export list, not even > "init" + module_name. In the general-purpose library-building code > (msvccompiler.py), this would be right: but this code is geared towards > building Python extensions, and if a Python extension doesn't export its > init function, what's the point? > > I suggest changing build_ext.get_export_symbols() from this: > > if ext.export_symbols is None: > return [] > else: > return ext.export_symbols > > to this: > > initfunc_name = "init" + string.split(ext.name,'.')[-1] > if initfunc_name not in ext.export_symbols: > ext.export_symbols.append(initfunc_name) > > which of course assumes that ext.export_symbols is a list, which will be > valid as long as we put back the "or []" in Extension's constructor. > Sound reasonable? OK, I think you are right, if one wants to build none Python dll's he will not use build_ext to do this. > > * bcpp.patch: changes bcppcompiler.py > > OK, I'm going over this one now. > > > > ld_args.extend([',',output_filename]) > > # no map file > > ld_args.extend([',']) > > # start libraries > > ld_args.extend([',']) > > This code seems fishy to me. First of all, why are you using > 'extend([x])' when 'append(x)' would do the same thing? And second, are > those commas really supposed to be whole words in the arg list? I don't > know how things work in Windows, but in Unix doing that would mean that > the compiler's argv list would look like I used 'extend' to be able to write " ld_args.extend([',','some_other_param']) ", but I never needed it in some places and simply forgot to replace it with 'append' in the final patch. > > [..., ',', 'foo.pyd', ',', ',', ...] > > which is really strange. I suspect that really should be coded as > > ld_args.append(",%s,," % output_filename) > > which would make an argv of > > [..., ',foo.pyd,,', ...] > > which seems a) more sensible, and b) looks like the Borland C++ command > lines I remember from 7-8 years ago. > > So: which arguments really have to be separate words (ie. separate > elements of the argv[] array that BCPP will ultimately have to process)? > Does this question even make sense on a DOS/Windows environment, ie. is > the argument delineation implicit in the 'spawn()' call preserved in the > child process? The commas separate different blocks of the command line, and I used them also to separate the command line building code in several blocks (objects, output filename, libraries, ... In the patch this block building is more obvious then in the current version where you already have put some blocks together.) It is not necessary to have these commas as separate words, but they don't really belong to a output filename or a library name, this is the other reason why I made them in separate words. > > > - def find_library_file (self, dirs, lib): > > - > > + def find_library_file (self, dirs, lib, debug=0): > > + # find library file > > Umm, the 'debug' flag is not part of the official CCompiler interface to > 'find_library_file()'. Is this really necessary? Should MSVCCompiler > do it as well? If so, then the interface should change. Yes, it should. Python comes also with libraries 'python??.lib' and 'python??_d.lib'. So it is probably a good idea to support it this way. > Looks like 'find_library_file()' is used in BCPPCompiler to give > preference to bcpp_xxx.lib; is this really important? Where does it > arise? Is this a common convention, or a Python-only convention? (Or a > Liebscher-only convention? ;-) go down to the next explanation, it is about the same problem. > > # either exchange python15.lib in the python libs directory against > > # a Borland-like one, or create one with name bcpp_python15.lib > > # there and remove the pragmas from config.h > > #libraries.append ('mypylib') > > libraries.append ('import32') > > libraries.append ('cw32mt') > > I don't understand. You commented out the use of 'mypylib' and added > the comment. Can you explain what's going on here, please? If we need > to make changes in Python (1.6 or 2.0!) to support Borland C++ better, > now's the time to do it. 'mypylib' is not a Borland standard library. It is a Borland-like python.lib. MSVC and Borland use different formats for their object files (COFF and OMF.) Now there comes also a 'python??' library from build_ext it should be also called 'python??.lib'. So you had to replace the standard 'python??.lib' by a Borland-like one. But what happens if you installed Python on a network drive and some users want to use MSVC and other BORLAND C++? Then you have to give one of these libraries another name. I would suggest 'bcpp_python??.lib'. * conventions (see above) I have never heard of some convention how to handle libraries in the same directory if you want to use different compilers which need these libraries with the same name but different format. How to resolve this? I think it is the best if every compiler(class) first looks if there is a special version for and use then this special version. In this case bcpp_python??.lib if it exists and if not python??.lib. This would be also work with other compiler classes, for example I am also testing LCC-Win32, which uses then lcc_python??.lib . So in this sense it is a 'Liebscher-only convention', but it doesn't hurt users who replace their libraries (python??.lib, ...) with versions specific to their compilers. If you know a better way to handle this problem, let me know. * About the 'pragma' in config.h: In PC/config.h of the Python source there are following lines: ------------------------------------------- #ifndef USE_DL_EXPORT /* So nobody needs to specify the .lib in their Makefile any more */ #ifdef _DEBUG #pragma comment(lib,"python20_d.lib") #else #pragma comment(lib,"python20.lib") #endif #endif /* USE_DL_EXPORT */ ------------------------------------------- If we want to use bcpp_python20.lib instead of python20.lib, we had to change the first line to: ------------------------------------------ #if !defined(USE_DL_EXPORT) && defined(_MSC_VER) ------------------------------------------ So the Borland C++ compiler wouldn't try to load this incompatible library 'python20.lib' . It would make sense to change this in any case for the next version of Python, because it comes with an import library for MSVC, so this pragma should be visible only for MSVC. (We can't change the config.h file in existing installations this is why I put the comment in there. So if a user got problems he finds a hint where this could come from.) > > * cygwin.patch: > Other comments... > > * why are {gcc,ld,dllwrap}_version class attributes? They are > derived from the particular compiler used by a particular > instance of the class, and when you set them in the constructor > they become instance attributes. So why even define them as > class attrs? Ok, I will change this. > > * 'check_config_h()' really should return meaningful strings instead > of magic numbers. Comment or no, any occurence of a bare > integer in non-arithmetic circumstances is a magic number in > my book, and I don't like magic numbers. > > * you shouldn't write to stdout or stderr in a compiler class -- use > the 'announce()' method. I should really add a 'debug_print()' > method; that would be handy. If you add 'debug_print()' I will use it. > > * I don't like using 'list(foo)' to make a copy of a list 'foo' -- > either 'foo[:]' or 'copy(foo)' (from the standard copy module) is > acceptable. Ok, I will change this too. Kind regards Rene Liebscher From gward@python.net Fri Aug 4 02:30:10 2000 From: gward@python.net (Greg Ward) Date: Thu, 3 Aug 2000 21:30:10 -0400 Subject: [Distutils] Re: CygwinCCompiler, msvc hack, BCPPCompiler In-Reply-To: <39894E5F.CD288233@gmx.de>; from R.Liebscher@gmx.de on Thu, Aug 03, 2000 at 12:50:07PM +0200 References: <395CB802.7CE487C@gmx.de> <20000704101613.A1881@beelzebub> <396465FC.3FD96CAD@gmx.de> <20000708212019.A4248@beelzebub> <396C71A1.198D8C2C@gmx.de> <397A344D.E3837BD6@gmx.de> <20000726210640.A1506@beelzebub> <398014F5.728445EE@gmx.de> <20000801213345.A600@beelzebub> <39894E5F.CD288233@gmx.de> Message-ID: <20000803213010.A1100@beelzebub> [my suggestion] > initfunc_name = "init" + string.split(ext.name,'.')[-1] > if initfunc_name not in ext.export_symbols: ext.export_symbols.append(initfunc_name) [Rene agrees] > OK, I think you are right, if one wants to build none Python dll's > he will not use build_ext to do this. OK, can you make this change and include it in your next patch? > I used 'extend' to be able to write " > ld_args.extend([',','some_other_param']) ", > but I never needed it in some places and simply forgot to replace it > with > 'append' in the final patch. [...] > It is not necessary to have these commas as separate words, but they > don't really > belong to a output filename or a library name, this is the other reason > why I made them in separate words. OK. I'd really like to see that code cleaned up: can you take care of that too? If it doesn't matter how things are broken up into words, how about just economizing on the amount of Python code? The current implementation seems rather bloated to me. > 'mypylib' is not a Borland standard library. It is a Borland-like > python.lib. MSVC and Borland use different formats for their object > files (COFF and OMF.) Now there comes also a 'python??' library from > build_ext it should be also called 'python??.lib'. So you had to > replace the standard 'python??.lib' by a Borland-like one. But what > happens if you installed Python on a network drive and some users want > to use MSVC and other BORLAND C++? Then you have to give one of these > libraries another name. I would suggest 'bcpp_python??.lib'. OK, that seems like a sensible convention to me. Congratulations, you have just converted a "Liebscher convention" to a "Distutils convention". Next thing you know it'll be a "Python convention", and then it'll be unstoppable! ;-) I've added the 'debug' flag to the official 'find_library_file()' signature specified by CCompiler. I've also rewritten the implementation in both MSVCCompiler and BCPPCompiler. Here's the MSVC one (it's a bit simpler -- no prefix): def find_library_file (self, dirs, lib, debug=0): # Prefer a debugging library if found (and requested), but deal # with it if we don't have one. if debug: try_names = [lib + "_d", lib] else: try_names = [lib] for dir in dirs: for name in try_names: libfile = os.path.join(dir, self.library_filename (name)) if os.path.exists(libfile): return libfile else: # Oops, didn't find it in *any* of 'dirs' return None and here's the BCPP version: def find_library_file (self, dirs, lib, debug=0): # List of effective library names to try, in order of preference: # bcpp_xxx.lib is better than xxx.lib # and xxx_d.lib is better than xxx.lib if debug is set # # The "bcpp_" prefix is to handle a Python installation for people # with multiple compilers (primarily Distutils hackers, I suspect # ;-). The idea is they'd have one static library for each # compiler they care about, since (almost?) every Windows compiler # seems to have a different format for static libraries. if debug: dlib = (lib + "_d") try_names = ("bcpp_" + dlib, "bcpp_" + lib, dlib, lib) else: try_names = ("bcpp_" + lib, lib) for dir in dirs: for name in try_names: libfile = os.path.join(dir, self.library_filename (name)) if os.path.exists(libfile): return libfile else: # Oops, didn't find it in *any* of 'dirs' return None Do those look right to you? Obviously this is completely untested, but I think both are a huge improvement so I'll check 'em in anyways. Make sure you "cvs up" if you have any patches for msvccompiler.py or bcppcompiler.py! Also in the "obvious" category: these should be combined, presumably when someone (probably me, sigh) sits down and factors WindowsCCompiler out of MSVCCompiler and BCPPCompiler. > * About the 'pragma' in config.h: > In PC/config.h of the Python source there are following lines: > ------------------------------------------- > #ifndef USE_DL_EXPORT > /* So nobody needs to specify the .lib in their Makefile any more */ > #ifdef _DEBUG > #pragma comment(lib,"python20_d.lib") > #else > #pragma comment(lib,"python20.lib") > #endif > #endif /* USE_DL_EXPORT */ > ------------------------------------------- > If we want to use bcpp_python20.lib instead of python20.lib, we > had to change the first line to: > ------------------------------------------ > #if !defined(USE_DL_EXPORT) && defined(_MSC_VER) > ------------------------------------------ > So the Borland C++ compiler wouldn't try to load this > incompatible library 'python20.lib' . Looks good to me. I just posted to python-dev about this: let's see what they say; I can make this change to PC/config.h if it's accepted. > (We can't change the config.h file in existing installations > this is why I put the comment in there. So if a user got problems > he finds a hint where this could come from.) Sorry, which comment? Do you mean the warning that's printed if 'check_config_h()' doesn't like what it finds? > > * you shouldn't write to stdout or stderr in a compiler class -- use > > the 'announce()' method. I should really add a 'debug_print()' > > method; that would be handy. > If you add 'debug_print()' I will use it. Added it. Please change your prints or writes or whatever they are. Thanks! Greg -- Greg Ward - just another Python hacker gward@python.net http://starship.python.net/~gward/ Eschew obfuscation! From gward@python.net Fri Aug 4 02:33:27 2000 From: gward@python.net (Greg Ward) Date: Thu, 3 Aug 2000 21:33:27 -0400 Subject: [Distutils] New code snapshot In-Reply-To: ; from cwebster@nevada.edu on Thu, Aug 03, 2000 at 12:02:38AM -0700 References: ; ; <20000729215720.A1465@beelzebub> <20000801220349.B1034@beelzebub> <20000802213016.A731@beelzebub> Message-ID: <20000803213327.B1100@beelzebub> OK, let's see if I understand. > ":foo" == "foo" != "foo:" rel rel abs > but > > ":foo:bar" != "foo:bar" == "foo:bar:" rel abs abs Right? And the oddball is "foo", which is special-cased to be relative. I think I get it now... > For the record, I posted to the MacPython list about this, and it looks > like people are happy with the new version of os.path.normpath for the mac, > so hopefully that'll be in the CVS tree in a day or two (I'll send it to > Jack Jansen to add it to the tree). Cool. I wonder if this should be committed on the 1.6 branch as well, since it's "just a bug fix". Greg -- Greg Ward - just another /P(erl|ython)/ hacker gward@python.net http://starship.python.net/~gward/ Know thyself. If you need help, call the CIA. From gward@python.net Fri Aug 4 02:47:12 2000 From: gward@python.net (Greg Ward) Date: Thu, 3 Aug 2000 21:47:12 -0400 Subject: [Distutils] normpath/abspath problem Message-ID: <20000803214712.A1333@beelzebub> Hi all -- Corran Webster has discovered an annoying little problem: 'os.path.normpath()' is broken under Mac OS. (More precisely, 'macpath.normpath()' is broken.) He has an alternate version which sounds agreeable to the MacPython folks, so there's a good chance it'll be in Python 2.0, and possibly 1.6. To maintain full compatibility with 1.5.2, though, we'd have to include it in the Distutils and use it if necessary, eg. def mac_normpath (path): ... if mac and python < 1.6: normpath = mac_normpath else: normpath = os.path.normpath OK, that works. We have to search out all uses of os.path.normpath and change them to util.normpath (where util = distutils/util.py, where the above code would live), but that's not a big deal. It's certainly the clean way to do it. But then what about abspath(), which uses normpath()? macpath.abspath() -- like the other two abspath() implementations -- calls normpath(), but it would end up calling the version in macpath.py, which will still be broken. Options: * change the above code to if mac and python < 1.6: os.path.normpath = mac_normpath which was actually my original suggestion, but I changed my mind because it's *evil* * provide a Distutils version of abspath(), which (surprise) would be identical source to macpath.abspath()... but would of course refer to our normpath() * forget about Mac OS support under Python 1.5.2 I'm not really keen on any of these. Other ideas? ...Distutils, the alternative Python test suite... Greg -- Greg Ward - nerd gward@python.net http://starship.python.net/~gward/ God made machine language; all the rest is the work of man. From fdrake@beopen.com Fri Aug 4 03:21:03 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Thu, 3 Aug 2000 22:21:03 -0400 (EDT) Subject: [Distutils] normpath/abspath problem In-Reply-To: <20000803214712.A1333@beelzebub> References: <20000803214712.A1333@beelzebub> Message-ID: <14730.10383.736957.264908@cj42289-a.reston1.va.home.com> Greg Ward writes: > He has an alternate version which sounds agreeable to the MacPython > folks, so there's a good chance it'll be in Python 2.0, and possibly > 1.6. To maintain full compatibility with 1.5.2, though, we'd have to > include it in the Distutils and use it if necessary, eg. > > def mac_normpath (path): > ... So far so good. > if mac and python < 1.6: > normpath = mac_normpath > else: > normpath = os.path.normpath How about: import sys try: sys.version_info except AttributeError: import macpath macpath = mac_normpath Simple, and doesn't require any platform tests. (sys.version_info is new starting in version 1.6.) > But then what about abspath(), which uses normpath()? macpath.abspath() > -- like the other two abspath() implementations -- calls normpath(), but > it would end up calling the version in macpath.py, which will still be > broken. This solution fixes all callers of macpath.normpath without additional magic. Keep It Simple. ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From cwebster@nevada.edu Fri Aug 4 19:27:57 2000 From: cwebster@nevada.edu (Corran Webster) Date: Fri, 4 Aug 2000 11:27:57 -0700 Subject: [Distutils] New code snapshot In-Reply-To: <20000803213327.B1100@beelzebub> References: ; from cwebster@nevada.edu on Thu, Aug 03, 2000 at 12:02:38AM -0700 ; ; <20000729215720.A1465@beelzebub> <20000801220349.B1034@beelzebub> <20000802213016.A731@beelzebub> Message-ID: At 9:33 PM -0400 3/8/00, Greg Ward wrote: > OK, let's see if I understand. > > > ":foo" == "foo" != "foo:" > rel rel abs > > > but > > > > ":foo:bar" != "foo:bar" == "foo:bar:" > rel abs abs > > Right? And the oddball is "foo", which is special-cased to be > relative. I think I get it now... Spot-on. > > For the record, I posted to the MacPython list about this, and it looks > > like people are happy with the new version of os.path.normpath for the mac, > > so hopefully that'll be in the CVS tree in a day or two (I'll send it to > > Jack Jansen to add it to the tree). > > Cool. I wonder if this should be committed on the 1.6 branch as well, > since it's "just a bug fix". I think that's the plan. I have no idea what the situation is for MacPython 1.6 vs. 2.0 at the moment, particularly since Jack Jansen is at CWI. I imagine that there will be a 1.6 release, since a lot of stuff has been added in 1.6 alpha (threading, particularly). Regards, Corran From gward@python.net Sat Aug 5 02:10:37 2000 From: gward@python.net (Greg Ward) Date: Fri, 4 Aug 2000 21:10:37 -0400 Subject: [Distutils] Re: FW: Extracting meta-data from distributions In-Reply-To: <613145F79272D211914B0020AFF64019320714@gandalf.digicool.com>; from Amos@digicool.com on Fri, Aug 04, 2000 at 05:23:05PM -0400 References: <613145F79272D211914B0020AFF64019320714@gandalf.digicool.com> Message-ID: <20000804211037.B1013@beelzebub> On 04 August 2000, Amos Latteier said: > I'm sending this to you directly since there seems to be some problem > with the distutils sig -- my mail bounced with a mailman error. Anyway > if you have any suggestions I'd love to hear them. If you want, I'll > summarize your response to the distutils sig later when the mailinglist > is fixed. Odd. I'll try cc'ing the list and see what happens. I did notice http connections to python.org were appallingly slow yesterday -- and I still work in the same building (same LAN, modulo firewalls and so forth) as that machine! > -----Original Message----- > From: Amos Latteier > Sent: Friday, August 04, 2000 2:17 PM > To: 'distutils-sig@python.org' > Subject: Extracting meta-data from distributions > > I've been thinking about how to query distutils packages. One thing I'd > like to do is download archives from the net and programmatically find > meta-data about the archive. $ ./setup.py --help [...] Information display options (just display information, ignore any commands) --help-commands list all available commands --name print package name --version (-V) print package version --fullname print - --author print the author's name --author-email print the author's email address --maintainer print the maintainer's name --maintainer-email print the maintainer's email address --contact print the maintainer's name if known, else the author's --contact-email print the maintainer's email address if known, else the author's --url print the URL for this package --licence print the licence of the package --license alias for --licence --description print the package description --long-description print the long package description [...] $ ./setup.py --name --version --author-email --url Distutils 0.9.1pre gward@python.net http://www.python.org/sigs/distutils-sig/ Clear enough? > * It seems that I must execute potentially untrusted code to get the > meta-data. Is there anyway around this? I guess RExec is the answer... Curses. I knew someone would get paranoid about writing dist-bots at some point. I have no answers to this... however, the above "informational" command shouldn't be doing any filesystem access apart from importing stuff, so it's probably "securable". Obviously, general Distutils usage makes extensive use of the filesystem, so writing general dist-bots securely will probably be tricky. Sigh. > * It seems that there is no distutils command to return all the > meta-data that I can poke into sys.argv before importing setup.py. > Should I replace distutils.core.setup with my own function before > importing the archive's setup.py. Or is there a less hackish way to get > back the meta-data all in one piece? There's no "give me all meta-data" option -- you have to "just know" the options listed in the --help command. Also, obviously, the output assumes you "just know" the order of options as you supplied them on the command line. Oh well, it's a heck of a lot better than nothing. > Perhaps there are other better strategies for getting at distutils > archive meta-data, since I'm pretty sure that this scenario has been > already thought through by someone smart. *blush* Actually, I can only take credit for knowing a good idea when I see it (the meta-data display options were Bastian Kleineidam's idea), and for tearing the command-line parsing code to shreds in order to allow the above semantics, where multiple options can be used together and their order is preserved. Greg -- Greg Ward - just another /P(erl|ython)/ hacker gward@python.net http://starship.python.net/~gward/ I invented skydiving in 1989! From gward@python.net Sat Aug 5 02:33:34 2000 From: gward@python.net (Greg Ward) Date: Fri, 4 Aug 2000 21:33:34 -0400 Subject: [Distutils] normpath/abspath problem In-Reply-To: <14730.10383.736957.264908@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Thu, Aug 03, 2000 at 10:21:03PM -0400 References: <20000803214712.A1333@beelzebub> <14730.10383.736957.264908@cj42289-a.reston1.va.home.com> Message-ID: <20000804213334.A1177@beelzebub> On 03 August 2000, Fred L. Drake, Jr. said: > import sys > try: > sys.version_info > except AttributeError: > import macpath > macpath = mac_normpath I assume you meant "macpath.normpath = mac_normpath" there! That said, I've never been fond of using try/except when you mean if. If you mean "Python version >= 1.6" why not say so? How exactly does "sys.version_info does not raise an exception" convey "this is Python 1.6 or greater" to the average reader? Greg -- Greg Ward - Linux nerd gward@python.net http://starship.python.net/~gward/ The world's my oyster soup kitchen floor wax! From Amos@digicool.com Sat Aug 5 20:36:32 2000 From: Amos@digicool.com (Amos Latteier) Date: Sat, 5 Aug 2000 15:36:32 -0400 Subject: [Distutils] RE: FW: Extracting meta-data from distributions Message-ID: <613145F79272D211914B0020AFF64019320715@gandalf.digicool.com> > > I've been thinking about how to query distutils packages. > One thing I'd > > like to do is download archives from the net and > programmatically find > > meta-data about the archive > $ ./setup.py --name --version --author-email --url > Distutils > 0.9.1pre > gward@python.net > http://www.python.org/sigs/distutils-sig/ > > Clear enough? Right. However I was looking for something I could do from Python, not the command line. I'd like to import the distribution's setup module and then interrogate it from Python to find out meta-data. > > * It seems that I must execute potentially untrusted code > to get the > > meta-data. Is there anyway around this? I guess RExec is > the answer... > > Curses. I knew someone would get paranoid about writing dist-bots at > some point. I have no answers to this... however, the above > "informational" command shouldn't be doing any filesystem access apart > from importing stuff, so it's probably "securable". > Obviously, general > Distutils usage makes extensive use of the filesystem, so writing > general dist-bots securely will probably be tricky. Sigh. To install a distribution obviously you must trust it. I'm imaging a system that does stuff like crawl the web looking for Python distributions, downloads them and parses them for meta-data. In this case I don't trust the distribution enough to install it, but I do want to find out what it has to say for itself. Thanks for you help! I'll let you know if I come up with solutions to these problems that I like better. -Amos From calvin@cs.uni-sb.de Sat Aug 5 21:58:38 2000 From: calvin@cs.uni-sb.de (Bastian Kleineidam) Date: Sat, 5 Aug 2000 22:58:38 +0200 (CEST) Subject: [Distutils] missing imports in util.py In-Reply-To: Message-ID: Hi, in the latest CVS version the lines from distutils.dir_util import * from distutils.file_util import * in util.py are missing. Bastian Kleineidam From gward@python.net Sun Aug 6 03:57:39 2000 From: gward@python.net (Greg Ward) Date: Sat, 5 Aug 2000 22:57:39 -0400 Subject: [Distutils] Re: FW: Extracting meta-data from distributions In-Reply-To: <613145F79272D211914B0020AFF64019320715@gandalf.digicool.com>; from Amos@digicool.com on Sat, Aug 05, 2000 at 03:36:32PM -0400 References: <613145F79272D211914B0020AFF64019320715@gandalf.digicool.com> Message-ID: <20000805225739.A1767@beelzebub> On 05 August 2000, Amos Latteier said: > Right. However I was looking for something I could do from Python, not > the command line. I'd like to import the distribution's setup module and > then interrogate it from Python to find out meta-data. I know, how about os.popen("%s setup.py --name --version" % sys.executable).read() ? Just kidding! Right now, I can't think of a good way to do this. As you suspected, you'd have to write your own setup() function and stick it into distutils.core before importing setup, then just "import setup". setup.py would then call your craftily constructed 'setup()' function instead of the standard one. Obviously, your setup() would probably look an awful lot like the one in distutils.core; you should really read through the source to see what it does. Here's a summary: * figure out the distribution class to use (default distutils.dist.Distribution) * instantiate the distribution class, using (most of) the keyword args to 'setup()' as constructor args. (IOW, setup(name="Distutils, version="1.0") is nearly equivalent to Distribution(name="Distutils, version="1.0") .) * parse config files * parse the command line * run all commands mentioned on the command line, using the per-command options that were found by parsing config files and the command line You might think that this: from distutils.dist import Distribution from distutils import core core.setup = Distribution import setup would work, but there are two problems: * there's at least one keyword arg to 'setup()' that is not passed to the Distribution constructor: 'distclass', which specifies the distribution class to use (this is one of the "backdoors" for extending the Distutils, but (AFAIK) it has never been used in practice) * no way to get at the Distribution object slyly created for you Next option: write your own version of 'setup()' that just does the first two steps and stores the created object somewhere you can get your hands on it (eg. a global in distutils.core), and then replace distutils.core.setup with your version. Best option: change the Distutils so that it (optionally) does this for you. Eg. where a normal setup script does this: from distutils.core import setup setup(name = "Distutils, version = "1.0") and nothing more, your tool would do something like this: from distutils import core core.do_nothing_mode() # better name? import setup dist = core.get_distribution() dist.get_name(), dist.get_version(), ... I think you could get away with execfile()'ing "setup.py" instead of importing it; it's not really a module to be imported, after all. It would have the same effect: call the official Distutils 'setup()' function, which -- since we're in "do nothing" mode -- just does the first two steps and saves the distribution object somewhere. 'get_distribution()' would then retrieve that distribution object so you can query its meta-data. A bit of a hack, sure, I think it'll work. Let me know if you cook up a patch to core.py, or if you'd rather I did it. Shouldn't be too hard. > To install a distribution obviously you must trust it. I'm imaging a > system that does stuff like crawl the web looking for Python > distributions, downloads them and parses them for meta-data. In this > case I don't trust the distribution enough to install it, but I do want > to find out what it has to say for itself. Yeah, I can definitely see that as useful in (say) a Distutils-aware Vaults of Parnassus. You still have to import or execfile() untrusted code, of course. Ahh well... Greg -- Greg Ward - geek-at-large gward@python.net http://starship.python.net/~gward/ All the world's a stage and most of us are desperately unrehearsed. From gward@python.net Sun Aug 6 03:59:30 2000 From: gward@python.net (Greg Ward) Date: Sat, 5 Aug 2000 22:59:30 -0400 Subject: [Distutils] missing imports in util.py In-Reply-To: ; from calvin@cs.uni-sb.de on Sat, Aug 05, 2000 at 10:58:38PM +0200 References: Message-ID: <20000805225930.A1787@beelzebub> On 05 August 2000, Bastian Kleineidam said: > in the latest CVS version the lines > > from distutils.dir_util import * > from distutils.file_util import * > > in util.py are missing. No, they were deliberately deleted. ("missing" implies this was accidental, which it was not.) I *thought* I caught all the import problems that this introduced, but if I missed any please let me know where! (And if it caused problems in your own code... too bad. Sorry, but those "import *"'s were a backwards compatibility hack that only should have been there for a week or two, but I got lazy.) Greg -- Greg Ward - just another Python hacker gward@python.net http://starship.python.net/~gward/ I'd like some JUNK FOOD ... and then I want to be ALONE -- From calvin@cs.uni-sb.de Sun Aug 6 12:10:28 2000 From: calvin@cs.uni-sb.de (Bastian Kleineidam) Date: Sun, 6 Aug 2000 13:10:28 +0200 (CEST) Subject: [Distutils] import errors Message-ID: Without the import * commands in util.py I have the following tracebacks in the current CVS code: File "/usr/lib/python1.5/site-packages/distutils/cmd.py", line 325, in mkpath util.mkpath (name, mode, AttributeError: mkpath File "/usr/lib/python1.5/site-packages/distutils/cmd.py", line 335, in copy_file return util.copy_file (infile, outfile, AttributeError: copy_file File "/usr/lib/python1.5/site-packages/distutils/cmd.py", line 404, in make_file if self.force or util.newer_group (infiles, outfile): AttributeError: newer_group File "/usr/lib/python1.5/site-packages/distutils/cmd.py", line 373, in make_archive return util.make_archive (base_name, format, root_dir, base_dir, AttributeError: make_archive Bastian Kleineidam From gward@python.net Sun Aug 6 21:41:31 2000 From: gward@python.net (Greg Ward) Date: Sun, 6 Aug 2000 16:41:31 -0400 Subject: [Distutils] import errors In-Reply-To: ; from calvin@cs.uni-sb.de on Sun, Aug 06, 2000 at 01:10:28PM +0200 References: Message-ID: <20000806164131.A926@beelzebub> On 06 August 2000, Bastian Kleineidam said: > Without the import * commands in util.py I have the following tracebacks > in the current CVS code: Yup, I stumbled across those earlier today when I actually tried to *use* the Distutils (as opposed to merely hacking on the code). They should be fixed now. Thanks -- Greg -- Greg Ward - Linux weenie gward@python.net http://starship.python.net/~gward/ Save energy: be apathetic. From R.Liebscher@gmx.de Tue Aug 8 13:20:48 2000 From: R.Liebscher@gmx.de (Rene Liebscher) Date: Tue, 08 Aug 2000 14:20:48 +0200 Subject: [Distutils] Re: CygwinCCompiler, msvc hack, BCPPCompiler References: <395CB802.7CE487C@gmx.de> <20000704101613.A1881@beelzebub> <396465FC.3FD96CAD@gmx.de> <20000708212019.A4248@beelzebub> <396C71A1.198D8C2C@gmx.de> <397A344D.E3837BD6@gmx.de> <20000726210640.A1506@beelzebub> <398014F5.728445EE@gmx.de> <20000801213345.A600@beelzebub> <39894E5F.CD288233@gmx.de> <20000803213010.A1100@beelzebub> Message-ID: <398FFB20.9EECC6E6@gmx.de> Greg Ward wrote: > > [my suggestion] > > initfunc_name = "init" + string.split(ext.name,'.')[-1] > > if initfunc_name not in ext.export_symbols: > ext.export_symbols.append(initfunc_name) > > [Rene agrees] > > OK, I think you are right, if one wants to build none Python dll's > > he will not use build_ext to do this. > > OK, can you make this change and include it in your next patch? > > > I used 'extend' to be able to write " > > ld_args.extend([',','some_other_param']) ", > > but I never needed it in some places and simply forgot to replace it > > with > > 'append' in the final patch. > [...] > > It is not necessary to have these commas as separate words, but they > > don't really > > belong to a output filename or a library name, this is the other reason > > why I made them in separate words. > > OK. I'd really like to see that code cleaned up: can you take care of > that too? If it doesn't matter how things are broken up into words, how > about just economizing on the amount of Python code? The current > implementation seems rather bloated to me. It is not as easy as you may think, I just spotted a potential problem before it could arise. If I would write ...append(",,%s," % filename) and filename would contain a blank ("/a b/file") then spawn would quote it as whole ",,/a b/file,". And this is probably wrong. So we should insert file names as single words in the list. (Don't say blanks in file names are not allowed in python module names, THIS is a generic compiler class which could also be used for other purposes.) > I've added the 'debug' flag to the official 'find_library_file()' > signature specified by CCompiler. I've also rewritten the > implementation in both MSVCCompiler and BCPPCompiler. Here's the MSVC > one (it's a bit simpler -- no prefix): > ... > and here's the BCPP version: > ... > Do those look right to you? Obviously this is completely untested, but > I think both are a huge improvement so I'll check 'em in anyways. Make > sure you "cvs up" if you have any patches for msvccompiler.py or > bcppcompiler.py! > > Also in the "obvious" category: these should be combined, presumably > when someone (probably me, sigh) sits down and factors WindowsCCompiler > out of MSVCCompiler and BCPPCompiler. > > (We can't change the config.h file in existing installations > > this is why I put the comment in there. So if a user got problems > > he finds a hint where this could come from.) > > Sorry, which comment? Do you mean the warning that's printed if > 'check_config_h()' doesn't like what it finds? I meant this one: > > # either exchange python15.lib in the python libs directory against > > # a Borland-like one, or create one with name bcpp_python15.lib > > # there and remove the pragmas from config.h > > #libraries.append ('mypylib') > > libraries.append ('import32') > > libraries.append ('cw32mt') > > > * you shouldn't write to stdout or stderr in a compiler class -- use > > > the 'announce()' method. I should really add a 'debug_print()' > > > method; that would be handy. > > If you add 'debug_print()' I will use it. > > Added it. Please change your prints or writes or whatever they are. Already done. From R.Liebscher@gmx.de Tue Aug 8 13:47:34 2000 From: R.Liebscher@gmx.de (Rene Liebscher) Date: Tue, 08 Aug 2000 14:47:34 +0200 Subject: [Distutils] Re: CygwinCCompiler, msvc hack, BCPPCompiler References: <395CB802.7CE487C@gmx.de> <20000704101613.A1881@beelzebub> <396465FC.3FD96CAD@gmx.de> <20000708212019.A4248@beelzebub> <396C71A1.198D8C2C@gmx.de> <397A344D.E3837BD6@gmx.de> <20000726210640.A1506@beelzebub> <398014F5.728445EE@gmx.de> <20000801213345.A600@beelzebub> <39894E5F.CD288233@gmx.de> <20000803213010.A1100@beelzebub> <398FFB20.9EECC6E6@gmx.de> Message-ID: <39900166.5CB9F747@gmx.de> This is a multi-part message in MIME format. --------------6D75E882F1D3D7994C314311 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit (My first email was sent uncomplete, here comes the second part.) Patch decription: - Extension.py: * ext.export_symbols is now always a list (added 'or []') - build_ext.py: * get_export_symbols() changed, adds now module init function if not given by the user - bccp_compiler.py: * changed some list.extend([...]) to list.append(...) * added '/g0' to compiler_options, so compiler doesn't stop after 100 warnings - cygwin_compiler.py: * use self.debug_print() for debug messages * uses now copy.copy() to copy lists * added 'shared_lib_extension=".dll"', ... , this is necessary if you want use the compiler class outside of the standard distutils build process. * changed result type of check_config_h() from int to string kind regards Rene Liebscher --------------6D75E882F1D3D7994C314311 Content-Type: text/plain; charset=us-ascii; name="bcpp_cygwin.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="bcpp_cygwin.patch" diff -BurN --minimal --exclude=*.pyc distutils.orig/distutils/bcppcompiler.py d.p/distutils/bcppcompiler.py --- distutils.orig/distutils/bcppcompiler.py Tue Aug 8 13:18:37 2000 +++ d.p/distutils/bcppcompiler.py Tue Aug 8 14:27:43 2000 @@ -67,8 +67,8 @@ self.lib = "tlib.exe" self.preprocess_options = None - self.compile_options = ['/tWM', '/O2', '/q'] - self.compile_options_debug = ['/tWM', '/Od', '/q'] + self.compile_options = ['/tWM', '/O2', '/q', '/g0'] + self.compile_options_debug = ['/tWM', '/Od', '/q', '/g0'] self.ldflags_shared = ['/Tpd', '/Gn', '/q', '/x'] self.ldflags_shared_debug = ['/Tpd', '/Gn', '/q', '/x'] @@ -232,7 +232,6 @@ # either exchange python15.lib in the python libs directory against # a Borland-like one, or create one with name bcpp_python15.lib # there and remove the pragmas from config.h - #libraries.append ('mypylib') libraries.append ('import32') libraries.append ('cw32mt') @@ -257,7 +256,7 @@ # name of dll file ld_args.extend([',',output_filename]) # no map file and start libraries - ld_args.extend([',', ',']) + ld_args.append(',,') for lib in libraries: # see if we find it and if there is a bcpp specific lib diff -BurN --minimal --exclude=*.pyc distutils.orig/distutils/command/build_ext.py d.p/distutils/command/build_ext.py --- distutils.orig/distutils/command/build_ext.py Thu Aug 3 11:00:01 2000 +++ d.p/distutils/command/build_ext.py Tue Aug 8 14:26:06 2000 @@ -549,14 +549,10 @@ the .pyd file (DLL) must export the module "init" function. """ - # XXX what if 'export_symbols' defined but it doesn't contain - # "init" + module_name? Should we add it? warn? or just carry - # on doing nothing? - - if ext.export_symbols is None: - return ["init" + string.split(ext.name,'.')[-1]] - else: - return ext.export_symbols + initfunc_name = "init" + string.split(ext.name,'.')[-1] + if initfunc_name not in ext.export_symbols: + ext.export_symbols.append(initfunc_name) + return ext.export_symbols def get_libraries (self, ext): """Return the list of libraries to link against when building a diff -BurN --minimal --exclude=*.pyc distutils.orig/distutils/cygwinccompiler.py d.p/distutils/cygwinccompiler.py --- distutils.orig/distutils/cygwinccompiler.py Thu Aug 3 10:59:58 2000 +++ d.p/distutils/cygwinccompiler.py Tue Aug 8 14:08:44 2000 @@ -44,16 +44,19 @@ __revision__ = "$Id: cygwinccompiler.py,v 1.4 2000/08/02 01:31:56 gward Exp $" -import os,sys +import os,sys,copy from distutils.unixccompiler import UnixCCompiler from distutils.file_util import write_file class CygwinCCompiler (UnixCCompiler): compiler_type = 'cygwin' - gcc_version = None - dllwrap_version = None - ld_version = None + obj_extension = ".o" + static_lib_extension = ".a" + shared_lib_extension = ".dll" + static_lib_format = "lib%s%s" + shared_lib_format = "%s%s" + exe_extension = ".exe" def __init__ (self, verbose=0, @@ -62,14 +65,16 @@ UnixCCompiler.__init__ (self, verbose, dry_run, force) - if check_config_h()<=0: + check_result = check_config_h() + self.debug_print("Python's GCC status: %s" % check_result) + if check_result[:2] <> "OK": self.warn( "Python's config.h doesn't seem to support your compiler. " "Compiling may fail because of undefined preprocessor macros.") (self.gcc_version, self.ld_version, self.dllwrap_version) = \ get_versions() - sys.stderr.write(self.compiler_type + ": gcc %s, ld %s, dllwrap %s\n" % + self.debug_print(self.compiler_type + ": gcc %s, ld %s, dllwrap %s\n" % (self.gcc_version, self.ld_version, self.dllwrap_version) ) @@ -117,9 +122,9 @@ extra_postargs=None, build_temp=None): - # use separate copies, so can modify the lists - extra_preargs = list(extra_preargs or []) - libraries = list(libraries or []) + # use separate copies, so we can modify the lists + extra_preargs = copy.copy(extra_preargs or []) + libraries = copy.copy(libraries or []) # Additional libraries libraries.extend(self.dll_libraries) @@ -241,11 +246,11 @@ compiling probably doesn't work. """ # return values - # 2: OK, python was compiled with GCC - # 1: OK, python's config.h mentions __GCC__ - # 0: uncertain, because we couldn't check it - # -1: probably not OK, because we didn't found it in config.h - # You could check check_config_h()>0 => OK + # "OK, python was compiled with GCC" + # "OK, python's config.h mentions __GCC__" + # "uncertain, because we couldn't check it" + # "not OK, because we didn't found __GCC__ in config.h" + # You could check check_config_h()[:2] == "OK" from distutils import sysconfig import string,sys @@ -254,7 +259,7 @@ if -1 == string.find(sys.version,"GCC"): pass # go to the next test else: - return 2 + return "OK, python was compiled with GCC" try: # It would probably better to read single lines to search. @@ -265,14 +270,14 @@ # is somewhere a #ifdef __GNUC__ or something similar if -1 == string.find(s,"__GNUC__"): - return -1 + return "not OK, because we didn't found __GCC__ in config.h" else: - return 1 + return "OK, python's config.h mentions __GCC__" except IOError: # if we can't read this file, we cannot say it is wrong # the compiler will complain later about this file as missing pass - return 0 + return "uncertain, because we couldn't check it" def get_versions(): """ Try to find out the versions of gcc, ld and dllwrap. diff -BurN --minimal --exclude=*.pyc distutils.orig/distutils/extension.py d.p/distutils/extension.py --- distutils.orig/distutils/extension.py Thu Aug 3 10:59:58 2000 +++ d.p/distutils/extension.py Tue Aug 8 14:26:26 2000 @@ -105,6 +105,6 @@ self.extra_objects = extra_objects or [] self.extra_compile_args = extra_compile_args or [] self.extra_link_args = extra_link_args or [] - self.export_symbols = export_symbols + self.export_symbols = export_symbols or [] # class Extension --------------6D75E882F1D3D7994C314311-- From thomas.heller@ion-tof.com Thu Aug 10 19:56:54 2000 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Thu, 10 Aug 2000 20:56:54 +0200 Subject: [Distutils] distutils and python release schedule Message-ID: <01d001c002fc$c06284b0$4500a8c0@thomasnb> Now, with the release schedules for 1.6 and 2.0 what is the status of distutils? Which version will be included in 1.6 (do we care about that)?. Which version in 2.0? Probably 1.0, whatever that means... Will bdist_wininst be part of these? Has anyone heard about anyone using it? bdist_wininst has one known bug (the user running the installer will receive error messages if zero-length files are included in the distribution). I have a fix for this bug, and also started a larger rewrite of the installer, but this is not yet finished. Thomas Heller From fdrake@beopen.com Thu Aug 10 20:08:43 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Thu, 10 Aug 2000 15:08:43 -0400 (EDT) Subject: [Distutils] distutils and python release schedule In-Reply-To: <01d001c002fc$c06284b0$4500a8c0@thomasnb> References: <01d001c002fc$c06284b0$4500a8c0@thomasnb> Message-ID: <14738.64955.781028.904582@cj42289-a.reston1.va.home.com> Thomas Heller writes: > Now, with the release schedules for 1.6 and 2.0 > what is the status of distutils? > > Which version will be included in 1.6 (do we care > about that)?. At this point, 1.6 contains Distutils 0.9; I'll change that whenever Greg tells me what to use. > Which version in 2.0? Probably 1.0, whatever that means... By definition! ;) This is up to Greg. > bdist_wininst has one known bug (the user > running the installer will receive error messages > if zero-length files are included in the distribution). That's one strange bug! But I've heard about some versions of particular ZIP tools having problems with zero-length files depending on option settings, so this might not be so unusual. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From gward@python.net Sat Aug 12 03:22:30 2000 From: gward@python.net (Greg Ward) Date: Fri, 11 Aug 2000 22:22:30 -0400 Subject: [Distutils] Re: distutils and python release schedule In-Reply-To: <01d001c002fc$c06284b0$4500a8c0@thomasnb>; from thomas.heller@ion-tof.com on Thu, Aug 10, 2000 at 08:56:54PM +0200 References: <01d001c002fc$c06284b0$4500a8c0@thomasnb> Message-ID: <20000811222230.D597@beelzebub> On 10 August 2000, Thomas Heller said: > Now, with the release schedules for 1.6 and 2.0 > what is the status of distutils? > > Which version will be included in 1.6 (do we care > about that)?. > Which version in 2.0? Probably 1.0, whatever that means... Given my glacial release schedule, Python 1.6 will probably include Distutils 0.9.1 (0.9 + bug fixes and some of Rene's reorganization of extension building on Windows). Still planning for Distutils 1.0 in Python 2.0. > Will bdist_wininst be part of these? > Has anyone heard about anyone using it? Yeah, bdist_wininst went out in Distutils 0.9, *and* I used it to create an installer for the Distutils! I haven't heard from anyone having problems with it, but then I haven't heard from anyone using it successfully either. I can only assume that it works. > bdist_wininst has one known bug (the user > running the installer will receive error messages > if zero-length files are included in the distribution). > > I have a fix for this bug, and also started a larger > rewrite of the installer, but this is not yet finished. Cool -- please send the little patch. Another problem: the strings "1.5" and "1.6" are hardcoded into the installer. Can you add "2.0" and send in the appropriate patches? Thanks -- Greg -- Greg Ward - nerd gward@python.net http://starship.python.net/~gward/ God made machine language; all the rest is the work of man. From gward@python.net Sun Aug 13 02:16:29 2000 From: gward@python.net (Greg Ward) Date: Sat, 12 Aug 2000 21:16:29 -0400 Subject: [Distutils] Re: CygwinCCompiler, msvc hack, BCPPCompiler In-Reply-To: <39900166.5CB9F747@gmx.de>; from R.Liebscher@gmx.de on Tue, Aug 08, 2000 at 02:47:34PM +0200 References: <20000708212019.A4248@beelzebub> <396C71A1.198D8C2C@gmx.de> <397A344D.E3837BD6@gmx.de> <20000726210640.A1506@beelzebub> <398014F5.728445EE@gmx.de> <20000801213345.A600@beelzebub> <39894E5F.CD288233@gmx.de> <20000803213010.A1100@beelzebub> <398FFB20.9EECC6E6@gmx.de> <39900166.5CB9F747@gmx.de> Message-ID: <20000812211629.A589@beelzebub> On 08 August 2000, Rene Liebscher said: > Patch decription: [...] OK, I've checked in all these changes. > - cygwin_compiler.py: [...] > * changed result type of check_config_h() from int to string I finally figured out how 'check_config_h()' should work; I've implemented it, tested it, and will check it in shortly. Here's the current code; please sanity-check it for me! (It works for me under Linux, at least.) ------------------------------------------------------------------------ def check_config_h(): """Check if the current Python installation (specifically, config.h) appears amenable to building extensions with GCC. Returns a tuple (status, details), where 'status' is one of the following constants: CONFIG_H_OK all is well, go ahead and compile CONFIG_H_NOTOK doesn't look good CONFIG_H_UNCERTAIN not sure -- unable to read config.h 'details' is a human-readable string explaining the situation. Note there are two ways to conclude "OK": either 'sys.version' contains the string "GCC" (implying that this Python was built with GCC), or the installed "config.h" contains the string "__GNUC__". """ # XXX since this function also checks sys.version, it's not strictly a # "config.h" check -- should probably be renamed... from distutils import sysconfig import string,sys # if sys.version contains GCC then python was compiled with # GCC, and the config.h file should be OK if string.find(sys.version,"GCC") >= 0: return (CONFIG_H_OK, "sys.version mentions 'GCC'") fn = sysconfig.get_config_h_filename() try: # It would probably better to read single lines to search. # But we do this only once, and it is fast enough f = open(fn) s = f.read() f.close() except IOError, exc: # if we can't read this file, we cannot say it is wrong # the compiler will complain later about this file as missing return (CONFIG_H_UNCERTAIN, "couldn't read '%s': %s" % (fn, exc.strerror)) else: # "config.h" contains an "#ifdef __GNUC__" or something similar if string.find(s,"__GNUC__") >= 0: return (CONFIG_H_OK, "'%s' mentions '__GNUC__'" % fn) else: return (CONFIG_H_NOTOK, "'%s' does not mention '__GNUC__'" % fn) ------------------------------------------------------------------------ The new use of 'check_config_h()' can be seen in the current CVS version of cygwinccompiler.py. Please let me know ASAP if this works for you; release 0.9.1 is long overdue, and we need to stop screwing around and get it out the door! Thanks -- Greg -- Greg Ward - programmer-at-large gward@python.net http://starship.python.net/~gward/ Disclaimer: All rights reserved. Void where prohibited. Limit 1 per customer. From gward@python.net Sun Aug 13 02:24:47 2000 From: gward@python.net (Greg Ward) Date: Sat, 12 Aug 2000 21:24:47 -0400 Subject: [Distutils] Re: CygwinCCompiler, msvc hack, BCPPCompiler In-Reply-To: <398FFB20.9EECC6E6@gmx.de>; from R.Liebscher@gmx.de on Tue, Aug 08, 2000 at 02:20:48PM +0200 References: <396465FC.3FD96CAD@gmx.de> <20000708212019.A4248@beelzebub> <396C71A1.198D8C2C@gmx.de> <397A344D.E3837BD6@gmx.de> <20000726210640.A1506@beelzebub> <398014F5.728445EE@gmx.de> <20000801213345.A600@beelzebub> <39894E5F.CD288233@gmx.de> <20000803213010.A1100@beelzebub> <398FFB20.9EECC6E6@gmx.de> Message-ID: <20000812212447.D589@beelzebub> On 08 August 2000, Rene Liebscher said: > It is not as easy as you may think, I just spotted a potential problem > before it could arise. > If I would write ...append(",,%s," % filename) and filename would > contain > a blank ("/a b/file") then spawn would quote it as whole ",,/a b/file,". > And this is probably wrong. So we should insert file names as single > words in the list. OK, you win. I think this situation sucks because of 1) MS-DOS' poorly-thought-out command-line model, which (as near as I can tell) has continued under Windows, and 2) Borland's abuse of Microsoft's fuzzy thinking. So your code makes the best of a bad situation. Oh well. > (Don't say blanks in file names are not allowed in python module names, > THIS is a generic compiler class which could also be used for > other purposes.) Oh good, finally someone other than me is preaching this sermon -- thanks! ;-) Greg -- Greg Ward - nerd gward@python.net http://starship.python.net/~gward/ Never put off till tomorrow what you can put off till the day after tomorrow. From kjohnston@rcsi.ie Mon Aug 14 10:09:17 2000 From: kjohnston@rcsi.ie (Catriona Johnston) Date: Mon, 14 Aug 2000 10:09:17 +0100 Subject: [Distutils] RE:Installation Message-ID: <9921C1171939D3119D860090278AECA2DEC635@EXCHANGE> OLD PROBLEM -------------------------------------------------------------- >I am trying to install numpy and am first installing >distutils. I am running SunOS 5.7 on a sparc Ultra-4. >I installed Python after downloading it from python.org. >When I try to install distutils, it reports that it >cannot find the /lib/python1.5/config and >indeed there is no such directory in the python distribution >that I can see. > >Fred Clare >fred@ucar.edu -------------------------------------------------------------- I am new to programming and python and I am afraid that I am having the same problem as Fred had...I want to install numpy and must therefore install distutils first. How can I fix the lack of the config directory and therefore its contents Makefile? I have tried reinstalling python but have had no success. I am running python on Linux red hat 6.1. Any help? Thanks kate johnston From kjohnston@rcsi.ie Mon Aug 14 12:42:58 2000 From: kjohnston@rcsi.ie (Catriona Johnston) Date: Mon, 14 Aug 2000 12:42:58 +0100 Subject: [Distutils] RE: Installation Message-ID: <9921C1171939D3119D860090278AECA2DEC636@EXCHANGE> Hello again, Sorry about the previous message I now know that the red hat installation is missing the python-devel rpm which supplies the config directory. However I cannot find anywhere to download it from. The following web site which previously did supply this rpm has just last month stopped doing so :( http://andrich.net/cgi-bin/inspect.py?file=/var/www/virtualdomains /andrich/www/python/files/python-devel-1.5.2-2.i386.rpm Does anyone know of a web-site where I can download it from? Thank you for your patience. :) kate johnston From kjohnston@rcsi.ie Mon Aug 14 13:10:38 2000 From: kjohnston@rcsi.ie (Catriona Johnston) Date: Mon, 14 Aug 2000 13:10:38 +0100 Subject: [Distutils] RE: Installation Message-ID: <9921C1171939D3119D860090278AECA2DEC637@EXCHANGE> Sorry Guys...I found a site which is a good RPM source for all those looking for one... its: http://rufus.w3.org/linux/RPM/ Cheers! Kate From thomas.heller@ion-tof.com Mon Aug 14 16:36:48 2000 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Mon, 14 Aug 2000 17:36:48 +0200 Subject: [Distutils] Re: distutils and python release schedule References: <01d001c002fc$c06284b0$4500a8c0@thomasnb> <20000811222230.D597@beelzebub> Message-ID: <003701c00605$76b88060$4500a8c0@thomasnb> [About distutils and python versions...] > > Will bdist_wininst be part of these? > > Has anyone heard about anyone using it? > > Yeah, bdist_wininst went out in Distutils 0.9, *and* I used it to create > an installer for the Distutils! I haven't heard from anyone having > problems with it, but then I haven't heard from anyone using it > successfully either. I can only assume that it works. If you continue to publish distutils on starship, we (or I) could look into apache's logfiles. > > > bdist_wininst has one known bug (the user > > running the installer will receive error messages > > if zero-length files are included in the distribution). > > > > I have a fix for this bug, and also started a larger > > rewrite of the installer, but this is not yet finished. > > Cool -- please send the little patch. > > Another problem: the strings "1.5" and "1.6" are hardcoded into the > installer. Can you add "2.0" and send in the appropriate patches? > Probably on wednesday. Thomas From gward@python.net Tue Aug 15 13:13:45 2000 From: gward@python.net (Greg Ward) Date: Tue, 15 Aug 2000 08:13:45 -0400 Subject: [Distutils] RE: Installation In-Reply-To: <9921C1171939D3119D860090278AECA2DEC637@EXCHANGE>; from kjohnston@rcsi.ie on Mon, Aug 14, 2000 at 01:10:38PM +0100 References: <9921C1171939D3119D860090278AECA2DEC637@EXCHANGE> Message-ID: <20000815081345.A749@beelzebub> On 14 August 2000, Catriona Johnston said: > Sorry Guys...I found a site which is a good RPM source for all those looking > for one... > its: > http://rufus.w3.org/linux/RPM/ Well, that was an easy problem to fix... just sit back and let the user figure it out for herself! ;-) Happy hacking... Greg -- Greg Ward - geek gward@python.net http://starship.python.net/~gward/ Paranoia is simply an optimistic outlook on life. From hgebel@inet.net Tue Aug 15 14:31:05 2000 From: hgebel@inet.net (Harry Henry Gebel) Date: Tue, 15 Aug 2000 09:31:05 -0400 Subject: [Distutils] RE:Installation In-Reply-To: <9921C1171939D3119D860090278AECA2DEC635@EXCHANGE>; from kjohnston@rcsi.ie on Mon, Aug 14, 2000 at 10:09:17AM +0100 References: <9921C1171939D3119D860090278AECA2DEC635@EXCHANGE> Message-ID: <20000815093105.A2524@inet.net> On Mon, Aug 14, 2000 at 10:09:17AM +0100, Catriona Johnston wrote: > >When I try to install distutils, it reports that it > >cannot find the /lib/python1.5/config and > I am new to programming and python and I am afraid that I am having the same > problem as Fred had...I want to install numpy and must therefore install > distutils first. How can I fix the lack of the config directory and > therefore its contents Makefile? I have tried reinstalling python but have > had no success. I am running python on Linux red hat 6.1. Any help? Install the python-devel rpm in addition to the python rpm, it contains all of the files in the config directory. -- Harry Henry Gebel, Senior Developer, Landon House SBS ICQ# 76308382 West Dover Hundred, Delaware From gward@mems-exchange.org Tue Aug 15 15:37:53 2000 From: gward@mems-exchange.org (Greg Ward) Date: Tue, 15 Aug 2000 10:37:53 -0400 Subject: [Distutils] ANNOUNCE: Distutils 0.9.1 Message-ID: <20000815103752.A14531@ludwig.cnri.reston.va.us> Hi all -- I've finally thrown together Distutils 0.9.1. This fixes all bugs that were reported in Distutils 0.9, as well as a one long-standing bug that nobody reported (and I only discovered myself this morning, putting together the release!). Also includes a bunch of work by Rene Liebscher cleaning up/reorganizing extension-building on Windows. Here's the real change log: * added --dist-dir option to the sdist and bdist commands, to control where output files are put; all default to the "dist" directory * factored a bunch of code out of the "sdist" command, which will hopefully make it easier to use its nifty "file list template" features used in other places (thanks to Rene Liebscher) * general cleanup/improvement of compiling extensions with non- Microsoft compilers under Windows (Rene Liebscher): - fixed Borland C++ interface so it works - better handling of different GCC versions under Windows * fixed a bunch of little bugs (thanks to various people) * some documentation work: added "Describing extensions" section to the "Distributing Python Modules" manual * fixed a long-standing bug in the "build_py" command that prevented "bdist_rpm" from working in certain cases It's available from http://www.python.org/sigs/distutils-sig/download.html as a source tarball, source ZIP file, source RPM, built RPM, and Windows installer. Greg -- Greg Ward - software developer gward@mems-exchange.org MEMS Exchange / CNRI voice: +1-703-262-5376 Reston, Virginia, USA fax: +1-703-262-5367 From R.Liebscher@gmx.de Thu Aug 17 12:45:51 2000 From: R.Liebscher@gmx.de (Rene Liebscher) Date: Thu, 17 Aug 2000 13:45:51 +0200 Subject: [Distutils] some small bugs Message-ID: <399BD06F.13FD9EAA@gmx.de> This is a multi-part message in MIME format. --------------C024D49164D0E627B3792EBD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit While playing with distutils, I found some (old) bugs. If your distribution directory for bdist doesn't exist, distutils doesn't create it. (Even the default 'dist', so distutils fails if you use bdist for the first time.) bdist_wininst fails if no long description exists. It should warn about this, and go ahead. And a new introduced one in bcppcompiler.py It uses the first object file's path name to get the directory for its def-file. But if there is another object placed at the first position, this doesn't work. The patch moves these parts to their right position. The patch also changes the prefered library names from bcpp_xxx.lib to xxx_bcpp.lib. The next is not a bug. I tried distutils with BeOS R5. BeOS uses also some linker scripts (as AIX does.) But in the Makefile are again the wrong pathnames to these scripts. So we have to correct this as for AIX in sysconfig.py. (Python doesn't install these scripts, I will put a patch for its Makefile.in to sourceforge.) And finally some corrections to the comments in my cygwinccompiler class. Kind regards Rene Liebscher --------------C024D49164D0E627B3792EBD Content-Type: text/plain; charset=us-ascii; name="rene.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="rene.patch" diff -BurN --minimal --exclude=*.pyc distutils.orig/distutils/bcppcompiler.py distutils.patched/distutils/bcppcompiler.py --- distutils.orig/distutils/bcppcompiler.py Mon Aug 14 15:13:04 2000 +++ distutils.patched/distutils/bcppcompiler.py Thu Aug 17 12:58:03 2000 @@ -224,17 +224,6 @@ else: ld_args = self.ldflags_shared[:] - # Borland C++ has problems with '/' in paths - objects = map(os.path.normpath, objects) - startup_obj = 'c0d32' - objects.insert(0, startup_obj) - - # either exchange python15.lib in the python libs directory against - # a Borland-like one, or create one with name bcpp_python15.lib - # there and remove the pragmas from config.h - libraries.append ('import32') - libraries.append ('cw32mt') - # Create a temporary exports file for use by the linker head, tail = os.path.split (output_filename) modname, ext = os.path.splitext (tail) @@ -246,6 +235,17 @@ self.execute(write_file, (def_file, contents), "writing %s" % def_file) + # Borland C++ has problems with '/' in paths + objects = map(os.path.normpath, objects) + startup_obj = 'c0d32' + objects.insert(0, startup_obj) + + # either exchange python15.lib in the python libs directory against + # a Borland-like one, or create one with name bcpp_python15.lib + # there and remove the pragmas from config.h + libraries.append ('import32') + libraries.append ('cw32mt') + # Start building command line flags and options. for l in library_dirs: @@ -377,9 +377,9 @@ # seems to have a different format for static libraries. if debug: dlib = (lib + "_d") - try_names = ("bcpp_" + dlib, "bcpp_" + lib, dlib, lib) + try_names = (dlib + "_bcpp", lib + "_bcpp", dlib, lib) else: - try_names = ("bcpp_" + lib, lib) + try_names = (lib + "_bcpp", lib) for dir in dirs: for name in try_names: diff -BurN --minimal --exclude=*.pyc distutils.orig/distutils/command/bdist.py distutils.patched/distutils/command/bdist.py --- distutils.orig/distutils/command/bdist.py Thu Aug 3 11:00:00 2000 +++ distutils.patched/distutils/command/bdist.py Thu Aug 17 13:14:58 2000 @@ -102,6 +102,9 @@ def run (self): + # create dist directory + self.mkpath(self.dist_dir) + for format in self.formats: try: cmd_name = self.format_command[format][0] diff -BurN --minimal --exclude=*.pyc distutils.orig/distutils/command/bdist_wininst.py distutils.patched/distutils/command/bdist_wininst.py --- distutils.orig/distutils/command/bdist_wininst.py Tue Aug 8 13:18:38 2000 +++ distutils.patched/distutils/command/bdist_wininst.py Thu Aug 17 13:08:20 2000 @@ -137,8 +137,12 @@ # 'info' will be displayed in the installer's dialog box, # describing the items to be installed. - info = metadata.long_description + '\n' - + if metadata.long_description: + info = metadata.long_description + '\n' + else: + self.warn ('no long_description available') + info = '' + for name in dir (metadata): if (name != 'long_description'): data = getattr (metadata, name) diff -BurN --minimal --exclude=*.pyc distutils.orig/distutils/cygwinccompiler.py distutils.patched/distutils/cygwinccompiler.py --- distutils.orig/distutils/cygwinccompiler.py Mon Aug 14 15:13:04 2000 +++ distutils.patched/distutils/cygwinccompiler.py Thu Aug 17 12:59:50 2000 @@ -18,7 +18,7 @@ # # see also http://starship.python.net/crew/kernr/mingw32/Notes.html # -# * We use put export_symbols in a def-file, and don't use +# * We put export_symbols in a def-file, and don't use # --export-all-symbols because it doesn't worked reliable in some # tested configurations. And because other windows compilers also # need their symbols specified this no serious problem. @@ -32,7 +32,7 @@ # (ld doesn't support -shared, so we use dllwrap) # * cygwin gcc 2.95.2/ld 2.10.90/dllwrap 2.10.90 works now # - its dllwrap doesn't work, there is a bug in binutils 2.10.90 -# see also ..... +# see also http://sources.redhat.com/ml/cygwin/2000-06/msg01274.html # - using gcc -mdll instead dllwrap doesn't work without -static because # it tries to link against dlls instead their import libraries. (If # it finds the dll first.) diff -BurN --minimal --exclude=*.pyc distutils.orig/distutils/sysconfig.py distutils.patched/distutils/sysconfig.py --- distutils.orig/distutils/sysconfig.py Thu Aug 3 11:00:00 2000 +++ distutils.patched/distutils/sysconfig.py Thu Aug 17 13:05:20 2000 @@ -254,6 +254,15 @@ python_exp = os.path.join(python_lib, 'config', 'python.exp') g['LDSHARED'] = "%s %s -bI:%s" % (ld_so_aix, g['CC'], python_exp) + if sys.platform == 'beos': + # Linker script is in the BeOS directory instead the config + # directory. In the Makefile it is relative to the srcdir which after + # installation no longer makes sense + python_lib = get_python_lib(standard_lib=1) + linkerscript_name = os.path.basename(string.split(g['LDSHARED'],' ')[0]) + linkerscript = os.path.join(python_lib, 'BeOS', linkerscript_name) + g['LDSHARED'] = ("%s -L%s/lib -lpython%s" + % (linkerscript,sys.prefix,sys.version[0:3])) def _init_nt(): --------------C024D49164D0E627B3792EBD-- From calvin@cs.uni-sb.de Thu Aug 17 12:57:58 2000 From: calvin@cs.uni-sb.de (Bastian Kleineidam) Date: Thu, 17 Aug 2000 13:57:58 +0200 (CEST) Subject: [Distutils] automatic CVS diffs? In-Reply-To: <399BD06F.13FD9EAA@gmx.de> Message-ID: Hello, a little offtopic, but I am wondering how I can produce a diff automatically from the CVS repository. Lets assume I made a cvs checkout and change some files. Can I produce a diff file with the changes I made by comparing it with the original repository? This would be really convenient. Bastian Kleineidam From fdrake@beopen.com Thu Aug 17 14:03:05 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Thu, 17 Aug 2000 09:03:05 -0400 (EDT) Subject: [Distutils] automatic CVS diffs? In-Reply-To: References: <399BD06F.13FD9EAA@gmx.de> Message-ID: <14747.57993.790065.405022@cj42289-a.reston1.va.home.com> Bastian Kleineidam writes: > a little offtopic, but I am wondering how I can produce a diff > automatically from the CVS repository. Lets assume I made a cvs checkout > and change some files. Can I produce a diff file with the changes I made > by comparing it with the original repository? > This would be really convenient. Try "cvs diff -c file..." (where the -c causes diff to generate context diffs). -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From calvin@cs.uni-sb.de Thu Aug 17 14:07:20 2000 From: calvin@cs.uni-sb.de (Bastian Kleineidam) Date: Thu, 17 Aug 2000 15:07:20 +0200 (CEST) Subject: [Distutils] automatic CVS diffs? In-Reply-To: <14747.57993.790065.405022@cj42289-a.reston1.va.home.com> Message-ID: Thanks for your help, the cvs diff command is the solution. Bastian Kleineidam From gward@python.net Tue Aug 22 02:32:32 2000 From: gward@python.net (Greg Ward) Date: Mon, 21 Aug 2000 21:32:32 -0400 Subject: [Distutils] Need help with bdist_wininst bugs Message-ID: <20000821213232.A1154@beelzebub> Hi all -- there are a couple of small bugs in the bdist_wininst command that need fixing. Thomas Heller is busy with personal stuff, and I am a fumbling babe in the woods when it comes to hacking on Windows C++ code. So we need help! Anyone care to tackle one of these? The bugs I know about are: * two particular Python version numbers -- "1.5" and "1.6" are hard- coded into the C source file (misc/install.c) for the installer; this list should at least be expanded to include "2.0", and preferably a less yucky solution than hard-coding version numbers can be found * problems (can't remember the details) when including zero-byte files in the archive Part of the solution to the latter is probably a warning in sdist.py that squawks if you have any zero-byte files in your manifest -- it's good practice to always include at least a comment or docstring in __init__.py, and I can't think of any other reason to include empty files. It's known to cause problems on Windows, so should probably just be avoided. Seem reasonable? Thomas (or others), what are the other known problems with bdist_wininst? Thanks -- Greg -- Greg Ward - Linux geek gward@python.net http://starship.python.net/~gward/ Speak softly and carry a +6 two-handed sword. From gward@python.net Tue Aug 22 02:55:05 2000 From: gward@python.net (Greg Ward) Date: Mon, 21 Aug 2000 21:55:05 -0400 Subject: [Distutils] some small bugs In-Reply-To: <399BD06F.13FD9EAA@gmx.de>; from R.Liebscher@gmx.de on Thu, Aug 17, 2000 at 01:45:51PM +0200 References: <399BD06F.13FD9EAA@gmx.de> Message-ID: <20000821215505.A1131@beelzebub> On 17 August 2000, Rene Liebscher said: > If your distribution directory for bdist > doesn't exist, distutils doesn't create > it. (Even the default 'dist', so distutils > fails if you use bdist for the first time.) Oops! Only a problem in bdist_dumb, because the other bdist commands just happen to use sdist, which did call 'mkpath()' properly. Anyways, I've fixed the problem by adding a couple of 'mkpath()' calls to archive_util.py, which should handle all future tarball-and-zip-file- generating commands. > bdist_wininst fails if no long description > exists. It should warn about this, and go ahead. How precisely does it fail? > And a new introduced one in bcppcompiler.py > It uses the first object file's path name to > get the directory for its def-file. But if there is > another object placed at the first position, this > doesn't work. The patch moves these parts to their > right position. Hmm, I knew I should have thought harder about that bit of code. Well, I'll think hard about this patch. ;-) > The patch also changes the prefered library names > from bcpp_xxx.lib to xxx_bcpp.lib. Good -- meant to get this into 0.9.1, but oh well. > The next is not a bug. > I tried distutils with BeOS R5. BeOS uses also some > linker scripts (as AIX does.) But in the Makefile are > again the wrong pathnames to these scripts. So we have > to correct this as for AIX in sysconfig.py. > (Python doesn't install these scripts, I will > put a patch for its Makefile.in to sourceforge.) Oh, bother. I knew that having if sys.platform == "aix4" in the code wouldn't cut it. Need to think about how to detect this situation -- "Python installed custom linker scripts to build shared extensions on this platform" -- and deal with it generally. ISTR that my first crack that the AIX problem took this approach by just absolut-izing the LD_SO Makefile entry, but this didn't cut it because the ld_so_aix script wasn't in the same location as the Makefile. Or something like that. Can anyone think of the *right* way to do this? > And finally some corrections to the comments > in my cygwinccompiler class. Oh good. Now, can you resubmit your patch as three patches: one for the bcppcompiler.py fixes, one for sysconfig, and one for cygwinccompiler? It's much easier to review and apply them one at a time like that. And make sure you "cvs up" first so you get my fix to archive_util.py! Thanks -- Greg -- Greg Ward - geek gward@python.net http://starship.python.net/~gward/ The world is coming to an end. Please log off. From Juergen Hermann" Message-ID: On Mon, 21 Aug 2000 21:32:32 -0400, Greg Ward wrote: >there are a couple of small bugs in the bdist_wininst command that need= >fixing. I could do it. >Part of the solution to the latter is probably a warning in sdist.py >that squawks if you have any zero-byte files in your manifest -- it's >good practice to always include at least a comment or docstring in >__init__.py, and I can't think of any other reason to include empty >files. It's known to cause problems on Windows, so should probably jus= t >be avoided. Seem reasonable? As long as it's a warning only, I can see nothing bad with it. Bye, J=FCrgen From thomas.heller@ion-tof.com Thu Aug 24 15:36:09 2000 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Thu, 24 Aug 2000 16:36:09 +0200 Subject: [Distutils] Need help with bdist_wininst bugs References: Message-ID: <024901c00dd8$a4c8bd50$4500a8c0@thomasnb> > On Mon, 21 Aug 2000 21:32:32 -0400, Greg Ward wrote: > > >there are a couple of small bugs in the bdist_wininst command that need > >fixing. > and Juergen Hermann wrote: > I could do it. > Maybe there is no need for this. I'm currently working on a new release of bdist_wininst, which I can hopefully post tomorrow. I would very much appriciate beta-testers. Juergen? Thomas From mwa@gate.net Thu Aug 24 18:42:40 2000 From: mwa@gate.net (Mark W. Alexander) Date: Thu, 24 Aug 2000 13:42:40 -0400 (EDT) Subject: [Distutils] Was I asleep? (Extension instance message) Message-ID: 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 From akuchlin@mems-exchange.org Thu Aug 24 19:00:36 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Thu, 24 Aug 2000 14:00:36 -0400 Subject: [Distutils] Was I asleep? (Extension instance message) In-Reply-To: ; from mwa@gate.net on Thu, Aug 24, 2000 at 01:42:40PM -0400 References: Message-ID: <20000824140036.A20503@kronos.cnri.reston.va.us> 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 From mwa@gate.net Thu Aug 24 22:32:29 2000 From: mwa@gate.net (Mark W. Alexander) Date: Thu, 24 Aug 2000 17:32:29 -0400 (EDT) Subject: [Distutils] Was I asleep? (Extension instance message) In-Reply-To: <20000824140036.A20503@kronos.cnri.reston.va.us> Message-ID: 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 > 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 > From mwa@gate.net Fri Aug 25 03:23:22 2000 From: mwa@gate.net (Mark W. Alexander) Date: Thu, 24 Aug 2000 22:23:22 -0400 (EDT) Subject: [Distutils] bdist_pkgtool attempt Message-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---941424627-93897353-967170202=:59938 Content-Type: TEXT/PLAIN; charset=US-ASCII Thanks to Harry Henry Gebels bdist_rpm module, I hacked out a bdist_pkgtool module to create binary packages for those of us stuck with Solaris. The module is attached. As a first pass, it takes somewhat of a sledgehammer approach, but it does work for at least a simple pure-python module. I have not tested pre/post-install scripts, and I doubt if they'd work anyway. I did however, include a "request" script which searches for the python installation directory before the package is installed and automatically relocates the module to the site-packages directory on the installation target. The same module package can be installed on machines with python installed in different locations and it will figure out the correct place to go. Let me know of any problems. I'm off to do HP-UX depot format now..... Mark Alexander mwa@gate.net ---941424627-93897353-967170202=:59938 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="bdist_pkgtool.py" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="bdist_pkgtool.py" IiIiZGlzdHV0aWxzLmNvbW1hbmQuYmRpc3RfcGtndG9vbA0KDQpJbXBsZW1l bnRzIHRoZSBEaXN0dXRpbHMgJ2JkaXN0X3BrZ3Rvb2wnIGNvbW1hbmQgKGNy ZWF0ZSBTb2xhcmlzIHBrZ3Rvb2wNCmRpc3RyaWJ1dGlvbnMpLiIiIg0KDQoj IE9yaWdpbmFsIGJkaXN0X3JwbSBjcmVhdGVkIDIwMDAvMDQvMjUsIGJ5IEhh cnJ5IEhlbnJ5IEdlYmVsDQojIEhhY2tlZCAmIHNsYXNoZWQgdG8gc3VwcG9y dCBTb2xhcmlzIHBrZ3Rvb2wgb24gMjAwMC8wODI0LCBieSBNYXJrIEFsZXhh bmRlcg0KDQpSRVE9IiIiDQojIS9iaW4vc2gNCg0KUFJPRFVDVD0idGhpcyBw eXRob24gbW9kdWxlIg0KDQpQQVRIPSIke1BBVEh9Oi9vcHQvcHl0aG9uL2Jp bjovdXNyL2xvY2FsL2JpbiINCmV4cG9ydCBQQVRIDQoNCnRyYXAgYGV4aXQg M2AgMTUNClBZX0RJUj1gcHl0aG9uIC1jICJpbXBvcnQgc3lzO3ByaW50ICcl cy9saWIvcHl0aG9uJXMnICUgKHN5cy5leGVjX3ByZWZpeCxzeXMudmVyc2lv blswOjNdKSIgMj4vZGV2L251bGxgDQpQWV9QS0dfRElSPWBweXRob24gLWMg ImltcG9ydCBzeXM7cHJpbnQgJyVzL2xpYi9weXRob24lcy9zaXRlLXBhY2th Z2VzJyAlIChzeXMuZXhlY19wcmVmaXgsc3lzLnZlcnNpb25bMDozXSkiIDI+ L2Rldi9udWxsYA0KDQplY2hvICIiDQppZiBbIC16ICIke1BZX0RJUn0iIF07 IHRoZW4NCgllY2hvICJJIGNhbid0IHNlZW0gdG8gZmluZCB0aGUgcHl0aG9u IGRpc3RyaWJ1dGlvbi4iDQoJZWNobyAiSSdtIGFzc3VtaW5nIHRoZSBkZWZh dWx0IHBhdGggZm9yIHNpdGUtcGFja2FnZXMiDQplbHNlDQoJQkFTRURJUj0i JHtQWV9QS0dfRElSfSINCgljYXQgPDxFT0YNCglQeXRob24gZm91bmQhIFRo ZSBkZWZhdWx0IHBhdGg6DQoNCgkke0JBU0VESVJ9DQoNCgl3aWxsIGluc3Rh bGwgJHtQUk9EVUNUfSBzdWNoIHRoYXQgYWxsIHB5dGhvbiB1c2VycyANCglj YW4gaW1wb3J0IGl0Lg0KDQoJSWYgeW91IGp1c3Qgd2FudCBpbmRpdmlkdWFs IGFjY2VzcywgeW91IGNhbiBpbnN0YWxsIGludG8NCglhbnkgZGlyZWN0b3J5 IGFuZCBhZGQgdGhhdCBkaXJlY3RvcnkgdG8geW91ciBcJFBZVEhPTlBBVEgN CkVPRg0KZmkNCmVjaG8gIiINCg0KDQpCQVNFRElSPWBja3BhdGggLWQgJHtC QVNFRElSfSAtYXkgXA0KCS1wICJXaGVyZSBzaG91bGQgJHtQUk9EVUNUfSBi ZSBpbnN0YWxsZWQ/IFske0JBU0VESVJ9XSJgIHx8IGV4aXQgJD8NCmVjaG8g IkJBU0VESVI9XCIke0JBU0VESVJ9XCIiID4+JDENCg0KIiIiDQojIyMgcmVx dWVzdCBzY3JpcHQNCg0KX19yZXZpc2lvbl9fID0gIiRJZDogYmRpc3RfcGtn dG9vbC5weSx2IDAuMSAiDQoNCmltcG9ydCBvcywgc3RyaW5nDQppbXBvcnQg Z2xvYg0KZnJvbSB0eXBlcyBpbXBvcnQgKg0KZnJvbSBkaXN0dXRpbHMuY29y ZSBpbXBvcnQgQ29tbWFuZCwgREVCVUcNCmZyb20gZGlzdHV0aWxzLnV0aWwg aW1wb3J0IGdldF9wbGF0Zm9ybQ0KZnJvbSBkaXN0dXRpbHMuZmlsZV91dGls IGltcG9ydCB3cml0ZV9maWxlDQpmcm9tIGRpc3R1dGlscy5lcnJvcnMgaW1w b3J0ICoNCmltcG9ydCBzeXMNCmZyb20gY29tbWFuZHMgaW1wb3J0IGdldG91 dHB1dA0KDQpjbGFzcyBiZGlzdF9wa2d0b29sIChDb21tYW5kKToNCg0KICAg IGRlc2NyaXB0aW9uID0gImNyZWF0ZSBhbiBwa2d0b29sIChTb2xhcmlzKSBw YWNrYWdlIg0KDQogICAgdXNlcl9vcHRpb25zID0gWw0KICAgICAgICAoJ3Br Z3Rvb2wtYmFzZT0nLCBOb25lLA0KICAgICAgICAgImJhc2UgZGlyZWN0b3J5 IGZvciBjcmVhdGluZyBSUE1zIChkZWZhdWx0cyB0byBcInBrZ3Rvb2xcIiB1 bmRlciAiDQogICAgICAgICAiLS1iZGlzdC1iYXNlOyBtdXN0IGJlIHNwZWNp ZmllZCBmb3IgUlBNIDIpIiksDQogICAgICAgICgnZGlzdC1kaXI9JywgJ2Qn LA0KICAgICAgICAgImRpcmVjdG9yeSB0byBwdXQgZmluYWwgcGtndG9vbCBm aWxlIGluICINCiAgICAgICAgICIoYW5kIHBhY2thZ2UgaW5mbyBmaWxlcyBp ZiAtLXNwZWMtb25seSkiKSwNCiAgICAgICAgKCdzcGVjLW9ubHknLCBOb25l LA0KICAgICAgICAgIm9ubHkgcmVnZW5lcmF0ZSBzcGVjIGZpbGUiKSwNCg0K ICAgICAgICAjIE1vcmUgbWV0YS1kYXRhOg0KICAgICAgICAoJ2NsYXNzZXMn LCBOb25lLA0KICAgICAgICAgInN1Yi1wYWNrYWdlIGNsYXNzZXMgW2RlZmF1 bHQ6IFwibm9uZVwiXSIpLA0KICAgICAgICAoJ2NhdGVnb3J5JywgTm9uZSwN CiAgICAgICAgICJNb2R1bGUgY2F0ZWdvcnkiKSwNCiAgICAgICAgKCd2ZXJz aW9uJywgTm9uZSwNCiAgICAgICAgICJNb2R1bGUgdmVyc2lvbiIpLA0KICAg ICAgICAoJ3JlbGVhc2UnLCBOb25lLA0KICAgICAgICAgIlBhY2thZ2UgdmVy c2lvbiIpLA0KICAgICAgICAoJ2FyY2gnLCBOb25lLA0KICAgICAgICAgIkFy Y2hpdGVjdHVyZSIpLA0KICAgICAgICAoJ3ZlbmRvcicsIE5vbmUsDQogICAg ICAgICAiUGFja2FnZSBcInZlbmRvclwiIChlZy4gXCJKb2UgQmxvdyA8am9l QGV4YW1wbGUuY29tPlwiKSAiDQogICAgICAgICAiW2RlZmF1bHQ6IG1haW50 YWluZXIgb3IgYXV0aG9yIGZyb20gc2V0dXAgc2NyaXB0XSIpLA0KICAgICAg ICAoJ3BhY2thZ2VyJywgTm9uZSwNCiAgICAgICAgICJQYWNrYWdlIHBhY2th Z2VyIChlZy4gXCJKYW5lIERvZSA8amFuZUBleGFtcGxlLm5ldD5cIikiDQog ICAgICAgICAiW2RlZmF1bHQ6IHZlbmRvcl0iKSwNCiAgICAgICAgIygncmVx dWVzdCcsIE5vbmUsDQogICAgICAgICAjInJlcXVlc3Qgc2NyaXB0IChCb3Vy bmUgc2hlbGwgY29kZSkiKSwNCiAgICAgICAgKCdwcmUtaW5zdGFsbCcsIE5v bmUsDQogICAgICAgICAicHJlLWluc3RhbGwgc2NyaXB0IChCb3VybmUgc2hl bGwgY29kZSkiKSwNCiAgICAgICAgKCdwb3N0LWluc3RhbGwnLCBOb25lLA0K ICAgICAgICAgInBvc3QtaW5zdGFsbCBzY3JpcHQgKEJvdXJuZSBzaGVsbCBj b2RlKSIpLA0KICAgICAgICAoJ3ByZS11bmluc3RhbGwnLCBOb25lLA0KICAg ICAgICAgInByZS11bmluc3RhbGwgc2NyaXB0IChCb3VybmUgc2hlbGwgY29k ZSkiKSwNCiAgICAgICAgKCdwb3N0LXVuaW5zdGFsbCcsIE5vbmUsDQogICAg ICAgICAicG9zdC11bmluc3RhbGwgc2NyaXB0IChCb3VybmUgc2hlbGwgY29k ZSkiKSwNCiAgICAgICAgKCdkZXBlbmQnLCBOb25lLA0KICAgICAgICAgImNh cGFiaWxpdGllcyByZXF1aXJlZCBieSB0aGlzIHBhY2thZ2UiKSwNCiAgICAg ICAgKCdjb21wdmVyJywgTm9uZSwNCiAgICAgICAgICJjb21wYXRpYmxlIHZl cnNpb25zIG9mIHRoaXMgcGFja2FnZSIpLA0KICAgICAgIF0NCg0KICAgIGRl ZiBpbml0aWFsaXplX29wdGlvbnMgKHNlbGYpOg0KICAgICAgICBzZWxmLmJk aXN0X2Jhc2UgPSBOb25lDQogICAgICAgIHNlbGYucGtndG9vbF9iYXNlID0g Tm9uZQ0KICAgICAgICBzZWxmLmRpc3RfZGlyID0gTm9uZQ0KICAgICAgICBz ZWxmLnNwZWNfb25seSA9IE5vbmUNCg0KICAgICAgICBzZWxmLmNsYXNzZXMg PSBOb25lDQogICAgICAgIHNlbGYuYXJjaCA9IE5vbmUNCiAgICAgICAgc2Vs Zi52ZW5kb3IgPSBOb25lDQogICAgICAgIHNlbGYucGFja2FnZXIgPSBOb25l DQogICAgICAgIHNlbGYuYXJjaCA9IE5vbmUNCg0KICAgICAgICAjc2VsZi5y ZXF1ZXN0ID0gTm9uZQ0KICAgICAgICBzZWxmLnByZV9pbnN0YWxsID0gTm9u ZQ0KICAgICAgICBzZWxmLnBvc3RfaW5zdGFsbCA9IE5vbmUNCiAgICAgICAg c2VsZi5wcmVfdW5pbnN0YWxsID0gTm9uZQ0KICAgICAgICBzZWxmLnBvc3Rf dW5pbnN0YWxsID0gTm9uZQ0KICAgICAgICBzZWxmLmRlcGVuZCA9IE5vbmUN CiAgICAgICAgc2VsZi5jb21wdmVyID0gTm9uZQ0KICAgICAgICBzZWxmLnZl cnNpb24gPSBOb25lDQogICAgICAgIHNlbGYucmVsZWFzZSA9IE5vbmUNCiAg ICAgICAgc2VsZi5jYXRlZ29yeSA9IE5vbmUNCg0KICAgICMgaW5pdGlhbGl6 ZV9vcHRpb25zKCkNCg0KDQogICAgZGVmIGZpbmFsaXplX29wdGlvbnMgKHNl bGYpOg0KICAgICAgICBzZWxmLnNldF91bmRlZmluZWRfb3B0aW9ucygnYmRp c3QnLCAoJ2JkaXN0X2Jhc2UnLCAnYmRpc3RfYmFzZScpKQ0KICAgICAgICBp ZiBzZWxmLnBrZ3Rvb2xfYmFzZSBpcyBOb25lOg0KICAgICAgICAgICAgc2Vs Zi5wa2d0b29sX2Jhc2UgPSBvcy5wYXRoLmpvaW4oc2VsZi5iZGlzdF9iYXNl LCAicGtndG9vbCIpDQoNCiAgICAgICAgaWYgb3MubmFtZSAhPSAncG9zaXgn Og0KICAgICAgICAgICAgcmFpc2UgRGlzdHV0aWxzUGxhdGZvcm1FcnJvciwg XA0KICAgICAgICAgICAgICAgICAgKCJkb24ndCBrbm93IGhvdyB0byBjcmVh dGUgcGtndG9vbCAiDQogICAgICAgICAgICAgICAgICAgImRpc3RyaWJ1dGlv bnMgb24gcGxhdGZvcm0gJXMiICUgb3MubmFtZSkNCg0KICAgICAgICAjIGRv bid0IHBhc3MgQ0ZMQUdTIHRvIHB1cmUgcHl0aG9uIGRpc3RyaWJ1dGlvbnMN CiAgICAgICAgI2lmIG5vdCBzZWxmLmRpc3RyaWJ1dGlvbi5oYXNfZXh0X21v ZHVsZXMoKToNCiAgICAgICAgICAgICNzZWxmLnVzZV9ycG1fb3B0X2ZsYWdz ID0gMA0KDQogICAgICAgIHNlbGYuc2V0X3VuZGVmaW5lZF9vcHRpb25zKCdi ZGlzdCcsICgnZGlzdF9kaXInLCAnZGlzdF9kaXInKSkNCiAgICAgICAgc2Vs Zi5maW5hbGl6ZV9wYWNrYWdlX2RhdGEoKQ0KDQogICAgIyBmaW5hbGl6ZV9v cHRpb25zKCkNCg0KICAgIGRlZiBmaW5hbGl6ZV9wYWNrYWdlX2RhdGEgKHNl bGYpOg0KICAgICAgICBzZWxmLmVuc3VyZV9zdHJpbmcoJ2NsYXNzZXMnLCBO b25lKQ0KICAgICAgICBzZWxmLmVuc3VyZV9zdHJpbmcoJ2FyY2gnLCAnc3Bh cmMnKQ0KICAgICAgICBzZWxmLmVuc3VyZV9zdHJpbmcoJ3ZlbmRvcicsDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAiJXMgPCVzPiIgJSAoc2VsZi5k aXN0cmlidXRpb24uZ2V0X2NvbnRhY3QoKSwNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBzZWxmLmRpc3RyaWJ1dGlvbi5nZXRf Y29udGFjdF9lbWFpbCgpKSkNCiAgICAgICAgc2VsZi5lbnN1cmVfc3RyaW5n KCdwYWNrYWdlcicpIA0KICAgICAgICBzZWxmLmVuc3VyZV9zdHJpbmcoJ3Zl cnNpb24nLCAiMCIpDQogICAgICAgIHNlbGYuZW5zdXJlX3N0cmluZygncmVs ZWFzZScsICIxIikNCiAgICAgICAgc2VsZi5lbnN1cmVfc3RyaW5nKCdjYXRl Z29yeScsICJTeXN0ZW0sYXBwbGljYXRpb24iKQ0KICAgICAgICAjc2VsZi5l bnN1cmVfZmlsZW5hbWUoJ3JlcXVlc3QnKQ0KICAgICAgICBzZWxmLmVuc3Vy ZV9maWxlbmFtZSgncHJlX2luc3RhbGwnKQ0KICAgICAgICBzZWxmLmVuc3Vy ZV9maWxlbmFtZSgncG9zdF9pbnN0YWxsJykNCiAgICAgICAgc2VsZi5lbnN1 cmVfZmlsZW5hbWUoJ3ByZV91bmluc3RhbGwnKQ0KICAgICAgICBzZWxmLmVu c3VyZV9maWxlbmFtZSgncG9zdF91bmluc3RhbGwnKQ0KDQogICAgICAgICMg WFhYIGRvbid0IGZvcmdldCB3ZSBwdW50ZWQgb24gc3VtbWFyaWVzIGFuZCBk ZXNjcmlwdGlvbnMgLS0gdGhleQ0KICAgICAgICAjIHNob3VsZCBiZSBoYW5k bGVkIGhlcmUgZXZlbnR1YWxseSENCg0KICAgICAgICAjIE5vdyAqdGhpcyog aXMgc29tZSBtZXRhLWRhdGEgdGhhdCBiZWxvbmdzIGluIHRoZSBzZXR1cCBz Y3JpcHQuLi4NCiAgICAgICAgc2VsZi5lbnN1cmVfc3RyaW5nX2xpc3QoJ2Rl cGVuZCcpDQogICAgICAgIHNlbGYuZW5zdXJlX3N0cmluZ19saXN0KCdjb21w dmVyJykNCg0KICAgICMgZmluYWxpemVfcGFja2FnZV9kYXRhICgpDQoNCg0K ICAgIGRlZiBydW4gKHNlbGYpOg0KDQogICAgICAgIGlmIERFQlVHOg0KICAg ICAgICAgICAgcHJpbnQgImJlZm9yZSBfZ2V0X3BhY2thZ2VfZGF0YSgpOiIN CiAgICAgICAgICAgIHByaW50ICJ2ZW5kb3IgPSIsIHNlbGYudmVuZG9yDQog ICAgICAgICAgICBwcmludCAicGFja2FnZXIgPSIsIHNlbGYucGFja2FnZXIN Cg0KICAgICAgICAjIG1ha2UgZGlyZWN0b3JpZXMNCiAgICAgICAgcGtnX2Rp ciA9IHNlbGYucGtndG9vbF9iYXNlDQogICAgICAgIHNlbGYubWtwYXRoKHBr Z19kaXIpDQoNCiAgICAgICAgIyBTcGVjIGZpbGUgZ29lcyBpbnRvICdkaXN0 X2RpcicgaWYgJy0tc3BlYy1vbmx5IHNwZWNpZmllZCcsDQogICAgICAgICMg YnVpbGQvYmRpc3QuPHBsYXQ+L3BrZ3Rvb2wgb3RoZXJ3aXNlLg0KICAgICAg ICBzcGVjX3BhdGggPSBvcy5wYXRoLmpvaW4ocGtnX2RpciwgInBrZ2luZm8i KQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIyIlcy5wa2dp bmZvIiAlIHNlbGYuZGlzdHJpYnV0aW9uLmdldF9uYW1lKCkpDQogICAgICAg ICMgYnVpbGQgcGFja2FnZQ0KICAgICAgICBzZWxmLmFubm91bmNlKCdCdWls ZGluZyBwYWNrYWdlJykNCiAgICAgICAgc2VsZi5zcGF3bihzdHJpbmcuc3Bs aXQoIiVzL2Jpbi9weXRob24gc2V0dXAucHkgYnVpbGQiICUgc3lzLmV4ZWNf cHJlZml4KSkNCiAgICAgICAgc2VsZi5hbm5vdW5jZSgnQ3JlYXRpbmcgcGtn aW5mbyBmaWxlJykNCiAgICAgICAgc2VsZi5leGVjdXRlKHdyaXRlX2ZpbGUs DQogICAgICAgICAgICAgICAgICAgICAoc3BlY19wYXRoLA0KICAgICAgICAg ICAgICAgICAgICAgIHNlbGYuX21ha2VfaW5mb19maWxlKCkpLA0KICAgICAg ICAgICAgICAgICAgICAgIndyaXRpbmcgJyVzJyIgJSBzcGVjX3BhdGgpDQog ICAgICAgIHNlbGYuYW5ub3VuY2UoJ0NyZWF0aW5nIHByb3RvdHlwZSBmaWxl JykNCiAgICAgICAgc3BlY19wYXRoID0gb3MucGF0aC5qb2luKHBrZ19kaXIs ICJwcm90b3R5cGUiKQ0KICAgICAgICBzZWxmLmV4ZWN1dGUod3JpdGVfZmls ZSwNCiAgICAgICAgICAgICAgICAgICAgIChzcGVjX3BhdGgsDQogICAgICAg ICAgICAgICAgICAgICAgc2VsZi5fbWFrZV9wcm90b3R5cGUoKSksDQogICAg ICAgICAgICAgICAgICAgICAid3JpdGluZyAnJXMnIiAlIHNwZWNfcGF0aCkN Cg0KICAgICAgICBzZWxmLmFubm91bmNlKCdDcmVhdGluZyByZWxvY2F0aW9u IHJlcXVlc3Qgc2NyaXB0JykNCiAgICAgICAgcmVxX3BhdGggPSBvcy5wYXRo LmpvaW4ocGtnX2RpciwgInJlcXVlc3QiKQ0KCXNlbGYuZXhlY3V0ZSh3cml0 ZV9maWxlLChyZXFfcGF0aCxzdHJpbmcuc3BsaXQoUkVRLCJcMDEyIikpLA0K CQkid3JpdGluZyAnJXMnIiAlIHJlcV9wYXRoKQ0KDQogICAgICAgIGlmIHNl bGYuc3BlY19vbmx5OiAjIHN0b3AgaWYgcmVxdWVzdGVkDQogICAgICAgICAg ICByZXR1cm4NCg0KDQogICAgICAgICNzZWxmLnNwYXduKHN0cmluZy5zcGxp dCgicGtncHJvdG8gIikpDQogICAgICAgIHNlbGYuYW5ub3VuY2UoJ0NyZWF0 aW5nIHBhY2thZ2UnKQ0KICAgICAgICBycG1fYXJncyA9IFsncGtnbWsnLCAn LW8nLCAnLWYnXQ0KICAgICAgICBycG1fYXJncy5hcHBlbmQoc3BlY19wYXRo KQ0KICAgICAgICBycG1fYXJncy5hcHBlbmQoJy1iJykNCiAgICAgICAgcnBt X2FyZ3MuYXBwZW5kKG9zLmVudmlyb25bJ1BXRCddKQ0KICAgICAgICBzZWxm LnNwYXduKHJwbV9hcmdzKQ0KICAgICAgICBycG1fYXJncyA9IFsncGtndHJh bnMnLCAnLXMnLCAnL3Zhci9zcG9vbC9wa2cnXQ0KICAgICAgICBzcGVjX3Bh dGggPSBvcy5wYXRoLmpvaW4ob3MuZW52aXJvblsnUFdEJ10scGtnX2Rpciwg c2VsZi5kaXN0cmlidXRpb24uZ2V0X25hbWUoKSkgKyBcDQoJCSItIiArIHNl bGYuZGlzdHJpYnV0aW9uLmdldF92ZXJzaW9uKCkgKyAiLnBrZyINCiAgICAg ICAgc2VsZi5hbm5vdW5jZSgnVHJhbnNmZXJyaW5nIHBhY2thZ2UgdG8gJyAr IHBrZ19kaXIpDQogICAgICAgIHJwbV9hcmdzLmFwcGVuZChzcGVjX3BhdGgp DQogICAgICAgIHJwbV9hcmdzLmFwcGVuZChzZWxmLmRpc3RyaWJ1dGlvbi5n ZXRfbmFtZSgpKQ0KICAgICAgICBzZWxmLnNwYXduKHJwbV9hcmdzKQ0KCW9z LnN5c3RlbSgicm0gLXJmIC92YXIvc3Bvb2wvcGtnLyVzIiAlIHNlbGYuZGlz dHJpYnV0aW9uLmdldF9uYW1lKCkpDQoNCiAgICAgICAgIyBYWFggdGhpcyBp cyBhIG5hc3R5IGhhY2sgLS0gd2UgcmVhbGx5IHNob3VsZCBoYXZlIGEgcHJv cGVyIHdheSB0bw0KICAgICAgICAjIGZpbmQgb3V0IHRoZSBuYW1lcyBvZiB0 aGUgUlBNIGZpbGVzIGNyZWF0ZWQ7IGFsc28sIHRoaXMgYXNzdW1lcw0KICAg ICAgICAjIHRoYXQgUlBNIGNyZWF0ZXMgZXhhY3RseSBvbmUgc291cmNlIGFu ZCBvbmUgYmluYXJ5IFJQTS4NCiAgICAjIHJ1bigpDQoNCiAgDQogICAgZGVm IF9tYWtlX3Byb3RvdHlwZShzZWxmKToNCiAgICAgICAgcGtnX2RpciA9IHNl bGYucGtndG9vbF9iYXNlDQogICAgICAgIHByb3RvX2ZpbGUgPSBbImkgcGtn aW5mbyIsDQogICAgICAgICAgICAgICAgICAgICJpIHJlcXVlc3QiLA0KCQkg ICAgIiFkZWZhdWx0IDA2NDQgcm9vdCBiaW4iXQ0KICAgICAgICBpZiBzZWxm LmRlcGVuZDoNCiAgICAgICAgICAgIHByb3RvX2ZpbGUuZXh0ZW5kKFsnaSBk ZXBlbmQnXSkNCiAgICAgICAgcHJvdG9fZmlsZS5leHRlbmQoc3RyaW5nLnNw bGl0KA0KICAgICAgICAgICAgZ2V0b3V0cHV0KCJwa2dwcm90byBidWlsZC9s aWIvJXM9JXMiICUNCiAgICAgICAgICAgICAgICAoc2VsZi5kaXN0cmlidXRp b24uZ2V0X25hbWUoKSwNCiAgICAgICAgICAgICAgICBzZWxmLmRpc3RyaWJ1 dGlvbi5nZXRfbmFtZSgpKSksDQogICAgICAgICAgICAiXDAxMiIpKQ0KICAg ICAgICByZXR1cm4gcHJvdG9fZmlsZQ0KDQogICAgZGVmIF9tYWtlX2luZm9f ZmlsZShzZWxmKToNCiAgICAgICAgIiIiR2VuZXJhdGUgdGhlIHRleHQgb2Yg YW4gUlBNIHNwZWMgZmlsZSBhbmQgcmV0dXJuIGl0IGFzIGENCiAgICAgICAg bGlzdCBvZiBzdHJpbmdzIChvbmUgcGVyIGxpbmUpLg0KICAgICAgICAiIiIN CiAgICAgICAgIyBkZWZpbml0aW9ucyBhbmQgaGVhZGVycw0KICAgICAgICBz cGVjX2ZpbGUgPSBbDQogICAgICAgICAgICAnUEtHPSIlcyInICUgc2VsZi5k aXN0cmlidXRpb24uZ2V0X25hbWUoKSwNCiAgICAgICAgICAgICdOQU1FPSIl cyInICUgc2VsZi5kaXN0cmlidXRpb24uZ2V0X25hbWUoKSwNCiAgICAgICAg ICAgICdWRVJTSU9OPSIlcyInICUgc2VsZi5kaXN0cmlidXRpb24uZ2V0X3Zl cnNpb24oKSwNCiAgICAgICAgICAgIF0NCiAgICAgICAgaWYgc2VsZi5hcmNo Og0KICAgICAgICAgICAgc3BlY19maWxlLmV4dGVuZChbJ0FSQ0g9IiVzIicg JSBzZWxmLmFyY2ggXSkNCiAgICAgICAgaWYgc2VsZi5jbGFzc2VzOg0KICAg ICAgICAgICAgc3BlY19maWxlLmV4dGVuZChbJ0NMQVNTRVM9IiVzIicgJSBz ZWxmLmNsYXNzZXMgXSkNCiAgICAgICAgaWYgc2VsZi5jYXRlZ29yeToNCiAg ICAgICAgICAgIHNwZWNfZmlsZS5leHRlbmQoWydDQVRFR09SWT0iJXMiJyAl IHNlbGYuY2F0ZWdvcnkgXSkNCiAgICAgICAgc2l0ZT1Ob25lDQogICAgICAg IGZvciBpIGluICBzeXMucGF0aDoNCiAgICAgICAgICAgIGlmIGlbLTEzOl09 PSJzaXRlLXBhY2thZ2VzIjoNCiAgICAgICAgICAgICAgICBzaXRlPWkNCiAg ICAgICAgICAgICAgICBicmVhaw0KICAgICAgICBpZiBzaXRlOg0KICAgICAg ICAgICAgc3BlY19maWxlLmV4dGVuZChbJ0JBU0VESVI9IiVzIicgJSBzaXRl IF0pDQogICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICNpZiBzZWxm LmRlcGVuZDoNCiAgICAgICAgICAgICAjc3BlY19maWxlLmFwcGVuZCgnQnVp bGRSZXF1aXJlczogJyArDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAjc3RyaW5nLmpvaW4oc2VsZi5idWlsZF9yZXF1aXJlcykpDQoNCiAgICAg ICAgIyBYWFggdGhpcyBpcyBraW5kIG9mIG1pc2xlYWRpbmc6IHVzZXItc3Vw cGxpZWQgb3B0aW9ucyBhcmUgZmlsZXMNCiAgICAgICAgIyB0aGF0IHdlIG9w ZW4gYW5kIGludGVycG9sYXRlIGludG8gdGhlIHNwZWMgZmlsZSwgYnV0IHRo ZSBkZWZhdWx0cw0KICAgICAgICAjIGFyZSBqdXN0IHRleHQgdGhhdCB3ZSBk cm9wIGluIGFzLWlzLiAgSG1tbS4NCg0KICAgICAgICBzY3JpcHRfb3B0aW9u cyA9IFsNCiAgICAgICAgICAgICgncHJlcCcsICdwcmVwX3NjcmlwdCcsICIl c2V0dXAiKSwNCiAgICAgICAgICAgICMoJ2J1aWxkJywgJ2J1aWxkX3Njcmlw dCcsIGRlZl9idWlsZCksDQogICAgICAgICAgICAoJ2luc3RhbGwnLCAnaW5z dGFsbF9zY3JpcHQnLA0KICAgICAgICAgICAgICJweXRob24gc2V0dXAucHkg aW5zdGFsbCAiDQogICAgICAgICAgICAgIi0tcm9vdD0kUlBNX0JVSUxEX1JP T1QgIg0KICAgICAgICAgICAgICItLXJlY29yZD1JTlNUQUxMRURfRklMRVMi KSwNCiAgICAgICAgICAgICMoJ2NsZWFuJywgJ2NsZWFuX3NjcmlwdCcsICJy bSAtcmYgJFJQTV9CVUlMRF9ST09UIiksDQogICAgICAgICAgICAoJ3ByZScs ICdwcmVfaW5zdGFsbCcsIE5vbmUpLA0KICAgICAgICAgICAgKCdwb3N0Jywg J3Bvc3RfaW5zdGFsbCcsIE5vbmUpLA0KICAgICAgICAgICAgKCdwcmV1bics ICdwcmVfdW5pbnN0YWxsJywgTm9uZSksDQogICAgICAgICAgICAoJ3Bvc3R1 bicsICdwb3N0X3VuaW5zdGFsbCcsIE5vbmUpLA0KICAgICAgICBdDQoNCiAg ICAgICAgcmV0dXJuIHNwZWNfZmlsZQ0KDQogICAgIyBfbWFrZV9pbmZvX2Zp bGUgKCkNCg0KICAgIGRlZiBfZm9ybWF0X2NoYW5nZWxvZyhzZWxmLCBjaGFu Z2Vsb2cpOg0KICAgICAgICAiIiJGb3JtYXQgdGhlIGNoYW5nZWxvZyBjb3Jy ZWN0bHkgYW5kIGNvbnZlcnQgaXQgdG8gYSBsaXN0IG9mIHN0cmluZ3MNCiAg ICAgICAgIiIiDQogICAgICAgIGlmIG5vdCBjaGFuZ2Vsb2c6DQogICAgICAg ICAgICByZXR1cm4gY2hhbmdlbG9nDQogICAgICAgIG5ld19jaGFuZ2Vsb2cg PSBbXQ0KICAgICAgICBmb3IgbGluZSBpbiBzdHJpbmcuc3BsaXQoc3RyaW5n LnN0cmlwKGNoYW5nZWxvZyksICdcbicpOg0KICAgICAgICAgICAgbGluZSA9 IHN0cmluZy5zdHJpcChsaW5lKQ0KICAgICAgICAgICAgaWYgbGluZVswXSA9 PSAnKic6DQogICAgICAgICAgICAgICAgbmV3X2NoYW5nZWxvZy5leHRlbmQo WycnLCBsaW5lXSkNCiAgICAgICAgICAgIGVsaWYgbGluZVswXSA9PSAnLSc6 DQogICAgICAgICAgICAgICAgbmV3X2NoYW5nZWxvZy5hcHBlbmQobGluZSkN CiAgICAgICAgICAgIGVsc2U6DQogICAgICAgICAgICAgICAgbmV3X2NoYW5n ZWxvZy5hcHBlbmQoJyAgJyArIGxpbmUpDQogICAgICAgICAgICAgICAgDQog ICAgICAgICMgc3RyaXAgdHJhaWxpbmcgbmV3bGluZSBpbnNlcnRlZCBieSBm aXJzdCBjaGFuZ2Vsb2cgZW50cnkNCiAgICAgICAgaWYgbm90IG5ld19jaGFu Z2Vsb2dbMF06DQogICAgICAgICAgICBkZWwgbmV3X2NoYW5nZWxvZ1swXQ0K ICAgICAgICANCiAgICAgICAgcmV0dXJuIG5ld19jaGFuZ2Vsb2cNCg0KICAg ICMgX2Zvcm1hdF9jaGFuZ2Vsb2coKQ0KDQojIGNsYXNzIGJkaXN0X3JwbQ0K ---941424627-93897353-967170202=:59938-- From gward@python.net Fri Aug 25 03:45:29 2000 From: gward@python.net (Greg Ward) Date: Thu, 24 Aug 2000 22:45:29 -0400 Subject: [Distutils] Was I asleep? (Extension instance message) In-Reply-To: ; from mwa@gate.net on Thu, Aug 24, 2000 at 01:42:40PM -0400 References: Message-ID: <20000824224529.A1044@beelzebub> 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-- From gward@python.net Fri Aug 25 03:45:59 2000 From: gward@python.net (Greg Ward) Date: Thu, 24 Aug 2000 22:45:59 -0400 Subject: [Distutils] Need help with bdist_wininst bugs In-Reply-To: <024901c00dd8$a4c8bd50$4500a8c0@thomasnb>; from thomas.heller@ion-tof.com on Thu, Aug 24, 2000 at 04:36:09PM +0200 References: <024901c00dd8$a4c8bd50$4500a8c0@thomasnb> Message-ID: <20000824224559.B1044@beelzebub> On 24 August 2000, Thomas Heller said: > Maybe there is no need for this. > I'm currently working on a new release of bdist_wininst, which > I can hopefully post tomorrow. > > I would very much appriciate beta-testers. Juergen? As soon as I check it in, you'll get all the beta-testers you want... *chortle*... Greg -- Greg Ward - Unix geek gward@python.net http://starship.python.net/~gward/ I invented skydiving in 1989! From mwa@gate.net Fri Aug 25 16:15:39 2000 From: mwa@gate.net (Mark W. Alexander) Date: Fri, 25 Aug 2000 11:15:39 -0400 (EDT) Subject: [Distutils] Was I asleep? In-Reply-To: <20000824224529.A1044@beelzebub> Message-ID: 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 > 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 > From thomas.heller@ion-tof.com Fri Aug 25 16:31:55 2000 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Fri, 25 Aug 2000 17:31:55 +0200 Subject: [Distutils] New bdist_wininst Message-ID: <00a901c00ea9$99eafcf0$4500a8c0@thomasnb> This is a multi-part message in MIME format. ------=_NextPart_000_00A6_01C00EBA.5D323010 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit (From the readme file:) This is a new release of the distutils windows installer. The known bug (bogus error message when an empty file is extracted) is fixed. Other changes: - The target-compile and target-optimize flags of bdist_wininst are gone. It is no longer possible to compile the python files during installation. - The zlib module is no longer required or used by bdist_wininst. - I moved the decompression/extraction code into a separate file (extract.c). - The installer stub is now compressed by UPX (see http://upx.tsx.org/). This reduces the size of the exe (and thus the overhead of the final installer program) from 40 kB to 16 kB. - The installer displays a more uptodate user wizard-like user interface, also containing a graphic: Just's Python Powered logo. (I could not convince myself to use one of the BeOpen logos). - The installation progress bar now moves correctly. Greg, the zip-file contains complete files, not diffs. When you check it in, note that archive.h, extract.c, install.c, install.rc, README.txt, resource.h, wininst.dsp, wininst.dsw and bdist_wininst.py are text-files in DOS format. PythonPowered.bmp and wininst.exe are binary files and should be checked in with -kb. (I'm not sure if wininst.exe should be checked in at all) Thomas Heller ------=_NextPart_000_00A6_01C00EBA.5D323010 Content-Type: application/x-zip-compressed; name="wininst.zip" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="wininst.zip" UEsDBAoAAAAAABC4ESkAAAAAAAAAAAAAAAAGAAAAYnVpbGQvUEsDBAoAAAAAABC4ESkAAAAAAAAA AAAAAAAKAAAAYnVpbGQvbGliL1BLAwQKAAAAAAARuBEpAAAAAAAAAAAAAAAAFAAAAGJ1aWxkL2xp Yi9kaXN0dXRpbHMvUEsDBAoAAAAAABG4ESkAAAAAAAAAAAAAAAAcAAAAYnVpbGQvbGliL2Rpc3R1 dGlscy9jb21tYW5kL1BLAwQKAAAAAAB8pQkpAAAAAAAAAAAAAAAABAAAAENWUy9QSwMECgAAAAAA YZG2KAAAAAAAAAAAAAAAAAMAAABkZC9QSwMECgAAAAAAM5O4KAAAAAAAAAAAAAAAAAcAAABkZC9D VlMvUEsDBAoAAAAAABupwigAAAAAAAAAAAAAAAAFAAAAZGlzdC9QSwMECgAAAAAAJnsOKQAAAAAA AAAAAAAAAAoAAABkaXN0dXRpbHMvUEsDBAoAAAAAAAiKGSkAAAAAAAAAAAAAAAASAAAAZGlzdHV0 aWxzL2NvbW1hbmQvUEsDBBQAAAAIAAiKGSkx2GghNEQAAB9vAAAiAAAAZGlzdHV0aWxzL2NvbW1h bmQvYmRpc3Rfd2luaW5zdC5wee29a5OjSJMu+D3N8j/k6dmx7l56mqsEjO3YWnAHARIgrjPH2rgJ ECAkQID49RvKrKquqq5+Z845Znv2w2JdiQQeHh4e7o8/LmXSP/30U1YN432smuH3tGvb+JL9njwv /TFXl+oyjK8vry9qe23yNr+Mw9tY5m/C5xFvP38j+vPbJw3/+pb2eTzmb/EbvJV18/D2vB83Td6/ vuRL/i/Xviv6uP39p59+ek7wT58GZG8EhmEotkUx4re3Y9m18fCm5B/jXl/++KPPp2qoussff7z9 29tP/4cKp/rGhN+vj9+mN/z3zSdFDIpt3jD8X0n8XzfUWzHHffYmLte3/+N92qq9dv34NjyG3946 +G8Y++pSvL6c+q59+9ovff72SZb/WOFfZJ4/P8sU+fjHtYnHU9e3fxHMqv6Pr4U/Fv7H2Of5b299 3nbTx5u/DMz7vuuHz8P+z6f9aRMPw7cOePvlk4W//utT4g0eWT6kfXUdodueTvu8NZc3uBHpfYyT Jv9ze96g0W+G8+Z/7NtPn5Xch7z/o3tXMkAt//7Lx9b/C1zOv/3829vP2c+/fQj+5fhpzJ8mx/0D LqbP07GDr56zvBsC/f0eU09lfZXcnxP89Ovf6Prl5zrPr//ydM9zzvrv53zKveu9Dvk96/7l0/ri dyc8x7/FfXe/ZG/xaYSL/ukN+TtNf2sl1JCW1ZT/A2vHuIex8C9T3j9j9t1P09/b3Oe3O3QQTJrh mqfVqUrfro+xhDN9UvAPrHx7Lgsa+DHjM6Kh1/+BZf/Vvftzx8bu7Xof307VJW7eknvVjN9445nh fzfff/8zEk9QrBqruKnW/Es4/TLkzekZr58HPN9/QiFoAAw3s7vk391+7vB7osDb2Hf3PrzwB0Sj a9X8A4GnAS205O8lPnn+xyb8xcCP+//0gzX+8uvz7p9eeHfjP/RBdfreDdXwPs1XMs/j434SD89V vI942v1Zf/bHJ0j+lK8///r7nwO+VfQXp3fD79d4LH8/d9Xllz9HwYD5jPe/fmPupRt/5Lt//cE0 f/Huswx8lsib4ftF/r126Ou3X36CgP/Tb2/wtH2eiN+xn379TsPz6ONq+Kp67d9dLz5h9e2XHyfA T5/y6fNk7R0ibJI/C8xv8McWlo3+7X26v27c19nxexkPf+TL+EfbZfcmh+HwvVdKCOpf+QMm8O+f 3v37v5L//S/e+JEn4C7/8Pp/+7dv1f8PeuZ7H6SwcnSX5gH98PeA9DfHN3b8+p0LfhgY34z4nEFf xAcoC1E8h+EOQ/1zrn0K9d8+4dwznN9h7vPrX3/9M1W/T8TvE7W/X/7Mze9mh/c+pxec6omJ2c+/ fi31qep8Tsw+/woYvuTlJ6Fvkunj0u99B4P+377LzB9M8EdTJf+lSZ6CX0/0T28zLGrde3LN8WV8 onx1SZt7BivnI31G9/XRQSfBmP3hrL//EGO/FvgWY38sk1+Ge5//CVq//PoXX8eXC6zXaQ7j8dPI 95rcvf3z8NPbP3/noh+48kdTfC8D9/Pbmf/pDcCtbeP6nS59qveQpD15BHwBZ3/W3Pdd6k7P118P /Tvm8fufQqd701zi9gtyfwMZ7zD+SeBraz+Z8Y7FnwZ/g9TfuuLvKvsPjp/+efgdIjtJPB36eebv /BEEwVsZp/V/e9vf+y8eMVzn+ITFrz3zRLBrDzNz+X68X8bjW5x0kE38/jkKsniMf/vz7QdhhYz8 999//7+/Hv/vh7wv4+vw9pksje/KYI5942e48OFp0BMb+r8xBYp9Irn/9xtUA6vrXEE9cFScpvn1 gxffL0+qDpMEKoesO8vj5r1D+FPNXI3l2+GDp8XXa1Ol7yZA26Fhc1ml5dsVbsv4rqTs7k32tlbX t/v1ayXPMPpq8FdE+V/+5R3X4yKGhS6HOAhnekb+E4WTb+LtY62QIDxHw3Hywf+qbjyD9FNd/xzu X2XgN9H1dUQ+Y/+Pz9v8y/ehB2stXMtP/9UY+2zDv31+8VVUv8/2qReCfcn7XB9T/DASvyYEX5jg d4Xtq2bq7fus+BgJ3Zl0T0bzkX394w8IAV8Vh28A4VkNPhkIEfYJiX8lbf/0xn/prj4Lpd1ljJ+E qXh7Rvmndiz53FJ8Hbe/f63p+AzJ9D1gkidIw419xtozbb70JDFcJKTjz3l+g6R8/Hp8/H75yRp/ gZHY5PEw/vps46A/39uvLE/uRfHU8m0H/bWb23yM343+EUB9vvk1kFZ/fIqeJ5jAt08o+Sz3F0T7 e4j/ssAPdP+s9xvM/vAuBL9rDkv0ZxEYkvNP34GW31dj/u7sf/9sy3+HU6bvq3h78+Lmng8w8qGD oeQI1T0d/bWGPr/2v/z67/i//gv+32G0vOP+43Ph/LTBMAGvPUz0d9xIy7iPU9haPnHg+XHBn7qe 87zH7r1/b0FzuL+Pt9u9Gz+GDb//ZZW/z+8r+OWnP+3/j8v3q4Q1/tT9/AXE4FZdm/gBtVeXrwMt 738e4M246eDGd8tvX6v4PjRhDzk8sTz5c3T2jXWnDm7Al/1tukvxx9efNsAo+/nnN+Tt5/+4/Py1 sc/we4+T6h3q3n75rOJ7WgzT/Jd3Qchhf/5e/c8/4vifohWGWjyOX2n+7e27APpqiuf9H6h6+7LC 9xMC/f8fl+fVfx7+9VNg/sd/Bfl++fhY6fc0vlbjO/v4WNSvv73P/OsPjHr769b/8/Bv/zzAXYez /vIR6M+gfPvlXcVHZP76XUQcnxEPKfL9+iXcPwfr8JZfoFX58H6h75rvy9o3EfMEQsji8n8Qmf9x +XfnfaaPwPw7sacnv6zjYwHPS58X8PcDr2P5XDUc+/sXN3wJvA9/fHn7ub/4QVP2D1vT7+f8VviL 2T9Q9I3jx2ps/sco3V8mfmr4zk3v1/7eT2kDC9nXOnu4G/3lC3T+WdS+rWE/rG/vBfhp/m9vfy3D X39G8enz07G/p+M//fa2vlOJP++np+JTPn6A9NdF/sv8v8KWJf6O8n+JvM/l5K8M93+Y4H6ht7/D 5X1HcT/L/Kd16GuzvrH4u2L0tdyzJCVfJ8XXe/0+4zMuoFF/JI8RZuQvv/6N7Cd3fnW3hJ7Ln5zu Ywugj9Iamv1/VdV/TsqwBSdIarOl2d8+XYFZHxf/2bDmucDPlvz6MQxeK74umF8b/WHi36zow11f YuynHvrpUzj8+peIhR76Nlq/c9v3ZOxTdD7J6pb6S2J8XP49y9MO1pR3hH77RQxEARzB+yxw3r9+ vP68AbHkj/eNfX4JAevSH3+0EFH/+OPnT3P/YN5P0dH/9Pvv/wH/a6sh/Y/PfOsZjZ/W9HWufHC6 rz3yIZR8kvpkf3752v6vwuNDy0+fVvTTBy/67PfkK8F30gKzI3v75+wdVt93+F3gt4/dTj6XqdeX T+reP7H7CVa/o3ezADAAPMTnDxRlANAL8PmwwH/9eH15/qTeX1One0GBEVxMNSm4o4GVnlxe0wc3 py17SVtpVGWzTNrNlPFcFTncI/OpIob/bJE9qjI+vb5EsnsXLGynfZlBuGFX3+j7A01utyvCIvcB nU54jJLkFoHvmbFHg1Ovw/u4fERZZHjeX3dr9/pCbuNPI/oT+6eG81PCjQ4Lud3D9+x1PJGnnn5q 0K4hUb3P8OcaOcu2nis9AuhHkdCu5/rPm3to4SzqwAo/efPDfU9vWsbTx/z7e+xD05f70G/Fp/cf h/jnS6H4Ivt+qB8n7s+L4tcDuM+78OUQBBtent9nMp/vv57oPz++0/a/ePyNNsmzfOHT648FfhV2 P4jAp8ye815fXKlYPi59LOp9L4Tw+fMrH34+njJCoV+0NW3fI/5DyPx4+WHb/s/Q/3I8LZj/evkf Hv+v+O1/8vjfrY0vQO34mzZZu+ITKrSxvzSq3KyvL6rClSExNhHPkXFgd6pidxAfPLjXRRSUTUh6 WOhrA7w2h77ZR4FaxIqNpUI36aQ35/wGS8ninpDaBWrjrR3gbS0S4FweF6qCeDcEsbAIds4D7RoR JabypbBzwLI/1oR+VGdDAEUml436jEuecyNfGvWK415fEnku3BaSDsVeVUlrUsJ7ZK1X6xWo+eLd xlKAL/nq5ueP7dY0qGN9g/EoqOtz5R38pxUiwCcEfX1BT+zR82I94y23PEVBpsT6CVSsKHPPGEcA XHncLH5yQAl2YjxGAmaFcpHSNJhHgRZIqZ0cGJJE0fD1pUAnNLM3N4HkpVlx7b1r1Ypi6R57iVGU 9eIiQD3e6grGMtjBsDIb70YY1ppyRI9sNRY4lgJekblmkV9fssi8Aa88BT1Kw9GZz5hehTwEmuN1 27aPXpPrFhfrh6DAKjegDDSm2TuNZNgB7ANXzayTYlsFJ0gRxN5CCu2QRRG2iXx3dg2UzQXkwFxR gEiVjDPEQJAHtBAyeyjlA4uL+8JDZ4FITqc2jYtDCa7clhZPrmJpMOu1Czv4OL19sKnMnRd3Xm5g Yj1Z9XEi0ZeZ31xEOfEZ+Thkjnuf29I19s1xRO85PSvYfs4iYZrrDHTH1xfaI8sH2Ju2O6VRN6p8 cRDI7nS3wGLnFLc7neYIbFnamHGrFCYqs+B2a0SZmYxRzhs/LmxflB1xKsLg9SUPB7bSeFkgCirR cwIJa2b7iIfdrB13bYWQbO+7W0rVglDdMxEuPVLLPDtC7lRiY4vrLJOltmSMz9SQerjUmLndULK9 MI94XtpF2R6sArgRBfbadSUQkn/sF2trhoxVz5bZZNk4aOODVx1LH9SVi3IyQO9jkcAI0fyq8/l+ cdUmw3nMYZfsPu7X3B84LENZbCdxXa2hDnmkT7I7iBJ4eBlnxEKA3FOWZeriaNWnsFSWXfr6UmbA 3GgCiMwllEdqYQtBvrcRu0VZQro3x5klEmQrMuomy7fs5Vjkc0hbOGqTuX60hQhGBsOjN9MG0+31 ZeHvBEqgjAPmfqUO12gUBaQTKVccoFWNx+43O/Z+IOjHVohgRYs6k+InYm88BqFaLiY7TWiFzadd h0EkVygME63Dqhciv1u2HI2Ww7hSOpgtUhzSe91hrjKj94Q+jRNe5McTkF0eCBY3C9h8UE59QBAI YR44YL6+2OUseGUnPIBJeLyBnfp2J5f0cA6DDr3imSevm3ub6rEu3F1j2YscEpED5rPSwyyBa0qk pbfsaMgNgN2VZhmA4bY1QfEZLQ5i4GWqXdrMUaHJQp+lzTKmmSDAXLZDV6/l4TGFqsXLSWkl/Hla 77M+eJeZB4uxgZnFHMd9efPv3JmyDIXBiqsVb8iEEMobV4uuauuoXLrUxVzveys2VvzktLdgGsdN ukVzXZptUQw7tTQu7OvL6TidUUrY6KQrLAWXWkowpRiXCoDFJFY3GbUkLqKiKZLknHvShmm654sJ eDhwNUkxvQtgGFLaCTwH95SEyYjOt8g/nTYG03SjzNmA23QTBLc10q45wCyDHwZXjvq4HB740pkS 53bjxRHphC5yy/Zlr7H0goHYq7Gn7OyATOPOKEYUVxydIKR5Z5c3dsAOjrejebmPqR6s1enSjkMf 1SF7UIj5TMfj5XQa+wJwBWCDvbSH+CbzHGdz6NyLSUR6jFdRlJuLEmOkoqbsL1RqFlVfA+ZwAdf9 I4gKmjSPQFrtTtwCw7yjONSO+rHIbV9fZPnMCuONjbcmRjtZUgSFutdxXA6WKW0mNC43MydfHR1g SjRg14vfxIx0FwkeYIlnPPD+1Izz0FVo6cL+BA+YijljojNZaHknS2eq3AKldqwhzN4u2jG6jciK TwidynABRQCM63aiJR9XnLGKwwr0yesO3bFJm9cX1udmf7pxurPBbLe47TS5WbqI1AFCPlSl5i8S ViJMnNChIS0Ct+U4NVlcpW27OZHXhm4rN9+7Q+hysNarnAeka3+nl2uHqbCMNZHqSNtyFkWlIw7D FifGyfLm6XSnCnTIVsHHBmdFsJk6VrJB0TkB9u7Rqkobh93ItH+w97HVqwrN7kNt2+JU7pcp7kAY azWjeVlHb7TSINK9AVawDN7Mm9hY5aNEVby11wd2PlAcLCgQez2Kwzll7UG7Ea2pjBXd8/tlbSJD DIfmzhG5Mi5ljrGSsRLzEAGwHGO9SCO1bfq28GCfwlSFEHNdRMAIAelDO2+O0FxHyeYRkcygFU6U y2/EsWbk7GRdOEU6AEte0/2WqVbP2ldnLsdSIpCE0NNKi7ftU6fx9evL9eCvM2m1e2n3mItIVa+Y p8fL2DvzVTrNQ+6V0z5LEYP0zFaSD1v6Mi7qcip2cxShXsuxmwsiLyWyNyyozQcDFm9QkO+3hROY AwquzoEFBwZraekKo6X2Rciq2oUvWc51TKTK1izImQNuQRDDBVOCnVGq8hwDEUnYcVF9eShkOs2x diXcmZCV4pyJjdii4kOcrSjv9/zcl5oLzuoQL5rPLTpWs0srPiDkW5tcP4n8mnLn1xdscVm9kBdA l+1RC2Mum3ptnxhhMj7i/WwZ4mbXGwZ790XkzpEROLp7X7zXQC4DXBZJH2801/PM4i7C6MXpSA5A wRru8dLLub6sBAs2quBOaLg4Sp/hG3+axsC7GbO/P9NXdeYdladEbxEFh/Cuq2J4ZbZXyQruqZJv QwHs0JnrtmoxUEeH48dFW9lYmlv6vpGJezGtm8F0gczFxTE3zMK09Ie0M6izfC27471+2AVocOPw +uJvMlpvFlKUhBjVg1aKHWJ/4Vtht7s60ojb7chuZ6jrfFWz4IrqJ4zswuEw58Dyto1lE2jUOQOz 3DfiM3op65IpkR4cewtnrcjjZZzoCLoYcX1HhbFZrvNQYmE9lxZg1jU492oSalez0ufleiPJOLkb mb+PtsjrC39xTOwUcf5DVWtHs6ZFTITLNK8iL+HgzNMSb5O2WJVYaQVFrN6DsxNpZVpX07zbmjo2 AcebUkuUrzB673IG+fSjwceHflUD3ofweI9lK9oYfCbW4TbJzMn2pEw0RBDYfFyZWEKc2pgwivB8 8mUQYdKIotDXkPdyRXpoUkkrEJG3wonrML3Xr1RKMyeFs04pL1FqTZEgmc2bJldGOAwWTK3L9rEi XEOTBDfBnmxIz/Ixen3pVF43MHG4IEcj2217fBRP/GB3/OlURPuoUO9TkrmKYt4dLeZz8uCUfH7z CV64VXdXdI1KWrYPd+JkloRZn5ZZpkU3Hq/tc0CKlJmMdqevtznBKvve3+jYPGXXwt5Txm25WSI1 J2Y2PxidAbzUBjPsY6uknvEYTK8vVsVcx+Sk9PZKmrZFymzpS9bpEl7jjTosPVnXvXGJLvtSG1TJ 8C3ugjnYNg9kPJdP5Yob22My1OkFkaDfhqjdjtSMBcoDthS+e+rHxkBFqVcXFPYcSZbYzCjDjOof nbA9IklZPBLxqN43s2hH01U6xpXG1aq8LBBD0NyAZEX21gIt/NisfbnYtoyHX/qlfRCoU3NpMDsD 7MytjNk9jmdQMQLBImYUI1crnWIdsHjbYUla55Ajid1evZ6Z+liYo05kccN5Hn3vpgz1D5lTcJLR euFI+Q4JwCFhFf9cVLgcKnK1OMGpO5+ZUw2I5CwsJfQbeFYXztfRkNUIfpcr5dB7t/UB647oN1bH 0A/B4Ydr2JDeTS5NZi+VDLIXr57TSDy3SABjQzHy1rv++sJwrEewd/QssmnmOrDVkwAvcMwWWCuB sscHSfnJOXtk2UXmClzesobEV1mWPUhMIzrVtejuoCObgBp2cKULonKNeurDYm/Xguw+Jm67zR8n +2pP3uFQqJjrMYzgVclcHcUtrwr3fEdSBdYpiXCcdsuFKcK1KIxQgNpOImpJhiArlkiUQ4apGhZb RykGq9wWPFltco3XLpUGSb1M1+J+LuJVhOyPXUQEuQY7yHNBUefFsYH4NllKHncYZqrBHojXjXe2 HEQXtWGeeFd9bM9kKJK1Spg0WqDlUkvKFZX5x+mObXW0GpHqsZbh9bgNkwx2bWU1u36qUySHF352 MC7eGZMORuhlIEfN1pLPhG4XdtcIGLcvqaRAhMfNUnNvCzhiKgpiKztzyJWWlMFOvHJvzFlmx+2y 6ZAD3XMkp4m7Yyu4QIlycYYJsd9pkpcjR6dZcX82C4FUBhjlVTTRHr4RkwI2oh1QEOP1ZateboKa I7cLfxo1cmZLWm8TlZDHik4Mq2oHyBNOhZDwri3NuztlJ33InRJun5ZCmspodp7c49FNBQryEK8a WNV07YjB8PSQNhwYRq/YrOp85SD1tw+PPF3beRdwkkunKzrNUgX21IqdJ967WGuFFemeuWK6OcE8 bRBCczmL57lKT62VJMuJcLtDy22pRSIeVBKJqcrZNl+WQ0nzU5iP+dzJFH5i1BqiiHg5iRerkthe Tp69c5KP9up7IlVDfGY31yjbbrFdc2baMyhyublv+9Tq9re6hisDQD204Fq6F2QsOO++DsdJUdB8 BywccvLSvITjuefyPG/Ofoybcbcj9WScrk1MH2BbeEarQbaKKqBCtItJ/NwdQx5Ye1VCdkKDaIqr 3Ed9TwIK1gVDlW4y5LEqn1yJe+JoVCsfpsWYesESTjctl1hfYhAtL1aCJlPzSh9JIs2AACQKsUrG txyCbVBSIFnIexW6sDGE15ySc3BczJOJCUy2S7BGIGHyVJQQNW4TYrQeUUIuRpUoHazgCmO1GhdY EZOC1qKRPB+VGmY9JFSa9pgjykMopK2t1Nu7PM7nns3THHCSJEjprOg3YCsiAJznCrdQ5IbtVGov IIWDIgvizXSusHdWf2ZWwFHoXQu4VuONwhQWN0cHR1kUsT4fQSfDlRDmVR5WQnXsrSbYQB1ReRwd bOLCYV+VYsoJgX0fAvn1RSqBaFssT6vayiXUXbpY3oKxHumvBOmQq2zadbK/V2o3WqKhXHd8qGT3 AwdrNyHzR7Cyp1hoCvdYptLTNkglFi82xao7t7BZVEI2aUa6wqmUJ2u5SrATQBFT78GxOkYCB0IV MArJhoGT6bcwR5hymU2/MZXs9SXYnlvzvNnEh4RTeZ8LHzUFScuee4QpAVzhMF97omxTP7ZK4pDy wQH2OTuD907muM0hzXAeUl3snOsxpl9fEkfljkTNp1uw3t0iGUOy43A1FweCOA+46IF1w7OFsT9y l2DSzzyP8SHimCMS5XQu7UhDKWWxGInsukJWg9iaCZreXOYdcbwLjriD7eCN7BsQKpxjFW5BUqWg adaBAMxNc4R6NzXzQ+Mg16Xs+2oQvnlmNo7gwF3gjSEVz0m/iYAw+/Pq561l0TEn7uwOjI+HcrJx PpwUj4F0nciiGJwuaXs9X7nIEmhA11h2X2ZR2NuRCnnvhdN5kSGroktcDZwjZiqx48YHhaXWWL0X RrXQwsdsUXU3PGSCn+tSIcu9cTBknT9EMX2m9kTTcqmBvb7oKjcDPfWaAWviQmAF8QC5GakB58Jy w3hHGJfiibQ+mpQAjdw/ttG1qTKzMm1PS3U9GmuMXcU2nmeI5LIq1oygJSf2gKfyVHg0I+Xnh2aR a+yz91vquqIwQ5y2tkjm84KJjMpO2iUe06vcJWYzK8KF4yZw826GtpkVISNMt6AQxc4WbwCKYrIm FvcbG4IeJvR3XCvWcRrBKRTTed4Xq+mvwonxxriRhfXsbyPZKLCDBTtx/2KF7KhLMzUedioMB7k8 Ot4QYw3uUhIakeEY7NT1bti7tTYmIa0FS9FDLvNAt+MQLt1m6+Ux2hAfNLjSyhm6c8j3UTFOiisQ 3FYLqgezN4q6YhyLE9ubnvSmuu4EWgCUSzDUYUxCuT3TO3f/gL2NujUnf6w2MOvRZbBEgfP3TJmg DZ7cGmsnufbKORPn7AdJhxHBFF6qdLMAaZQmWws+MQpXugs4lZWAWuZ6kGpL3lKwAlqo4wtpUjsH GpkQYicwqXvUHB0LJxOD6LpY5ZlHNWVE8/t2lbW9Wk/pACulkE+wttJ4mVAcNalYXsGaBXwrd5aS rP3D6Od8m6mHESw1t9pzlig9yjHKHbCH+w6p0WG55JZbkWUQBQ7POeeEF88WNrseKWhkCHdhL+l7 c53rgBcx6o7F+VTirsUMbgm8rbCxyBJ0B87R+jYZ9qc9TuNLmFohuTG4KrQtAZEIJgtPrM8d98/P 8I3hdupGTOHuyA3IB2wejvQEo/xEnERwUS+6O/EDzoSTXzFbnrKyx7YEK5b1yWm+T5AOjhUj0sup g51R5S+pkc8F6Q4tCO8aQOp236fjEdKcie8VBbgmSQdCGWH+ibuKezbCVRrR6eWGLsHQ6YEVVWxK D7YHMYR7TPxCh3rpQm/w0yOlajzz0/00crB1WDgH2MfKMzB5v9X7yCU5LJ3jMT6PAJ8GbN4azrRz TqyugwxiyDSOKydsvMzhKpaNxnQyOabe6uuw0x87Rw7TXRb0QOdiiS6oQMuuJL9nRGk+bgNix7eS aAVYKPIMKlCwOufbpmK6UTEZYccK6xVWFIKl7wHviQBXTQfHvHLYYPQJ9AIXazk3X7WxTPlZ6gLf CpF1lUVu4XbX556maxF6TMsZxdZZM4l9mGqDrkzz4Pmw7DdNtSCKYiU+JswKmc0ZryrbDrhHGNGj MBWyP3usgsG+ExT86wvVEWummCTAig7xuFIkGOYyP0zOgu34kAnJkOTX7jJz+0HtL9KxdEOyvaqq aN2EsCI81KCPKVFGRk9BfONK6RoeVUEH5f6MMSOWyDqEk8CZV2lHWzIxO3ZoFSqgohuacHQrZ49W gH39VlHThzIH12k4CEfF8GuYC6OGw9YMkKqin1KuqwVA+FMLQVPFj66nYh6BXzAkWSicsw3xYcmq N7TsZS4dheb3oSQLG6Z02QYTjhXkIWtGwBwYTEvLBMqkseZCnM7rdo+Uq4GYu/0c9Eh7hn1lsnGu Z4I9XK6+Ygoc2t2RlNAfiUcySjrneg1ZjcokrWeI3DmP6d5KTFOJMchBAlPZ8zFBkDJT99tRNOBy neQ8pjN1XaydRSpbcBb7i0LNE7sGlmCgO9gvbDnd9E9Yk1F1rx0KXWGAvkeadc+GY63mEQWsk6ER uP0wlG16GU471KaZDemFg3GO6/NahXuKxv14seFKcQ0kOLNpSsnwlL1s8D2Z9xGTAxbQuy6/Zpl5 a6TzbneurW1UkxJpBIy6O0oWGSthzzCwYM33gQe7AnJyiDDRGV1wNnW48hCRlbfZFp17yMxJbzkP aHxkuyLYmu2+PWeMpvO2LTY76jSTwUEI6QMOWzdLZATXgr0M304HSXY1P4jDaM4AVzB4zztVvU0U ZfEMTUjodC8cH5WLreSJOFgEdYgYRuWHFPqBLgfOuopb0Zut53e7xKzDBLk6AKnGRAApvukPAh8E dL4lzELE+Hu2B6Z/1J24gLCz1uRdvpJb+Z7BFq1dGv/cEsEIMimCHIna6xKRRC7gsEt0hcgoYojg GGGca1aqi9eVF8NQh7W/uzgA0G3dzgPYydlK3ek+SwmtreJm7K+Nu9iQ4WdJGpO5RJT5XO8X4sH7 pTGH84xwhkylhOstJZre83YNcmMprejIeu5JjWj1dNqY2Q11JnueDzdXfNasKLg/dtjDNMLxuvdk fdBbGeMHLrrqN30JTHEoCbcRtxYVxD4aj0bbK5ZdzAU2yrxioHjNqY4ka7llQ3yzOWOvyGIoukOx 1c2IM7OuP+zEKwUJL3cXJU9Xl/OhoM64+xgssDZJt+zTjWU5x6o7cYfwQO/QVKA7E670yErhCPEV 9KVEuWZocPvTutncUIl3rzvYyV5aS1CP/H7rGLDZ35uwGhd2laGBR8uyv3LNvTnicoeflRBm1rkP 1LZyB9kTHc5mLv3Vj8IHXXuqMXeKTnpANlOEz2cYF/IxRju4K51noB4zXhWj1MTZ8h2hLPYz1OZ2 FqJSLmsVNawleLILGtWVdi03L2TJnnprF7UbTLK85kA+FI3PxPGIBRbZ5dh51Bt6ywNS7xqfU1jY GfnbnnH5yasISqWIDXsYQo654S3PFct4AqxRG/eKyQyvCaQ4UfFYNgUHjyNR03L+fM9KUHPbqCqa GX9+99GJpaxJxxAhet5FZrT2BEfI87mhbhaKYjv7OO4uu00gU0LI33Vd6EbVoSPTmJpUAIEZ0LzP 30IQje3rSzZCFLYniuurmp4flSB3wGtyrysA3OosTAs5n9tLVuGlvFOFNaewULAL1aMVIFy489ZF 00qUbyM9Ta8vZODuqhnfcveVF/RriuRMRtJkIlDJJHo+h9DAa1PzwSWFKgVoujhTWBSIAZvLbs5x uzKRiiBEqypjiG9LOdW1bpK9lCwArVVm2lvWTEEHBsTzvDmcYOcIz5qwRdCVTfa5ZaE0CjBM7gor mWTnFDsTPl5c79lnabKIlTiri+adYM8ZfVmY6bQcdUat1oBk2dvWJ8i+Qn1FXKVMwod2zuURlRh9 tqqTNdbiYeOqrkyxry+MxGXTPfSVZYjZ4ig0jXOmZuak7ESS5LwbrbpVVSNnOywt0QRJEWSxoJaq GLgAAEQBQXpwuLNALjYKo1eWOsr2iLUwZYflQkPTZ284x0nvz3e/MGZrxuaAJuLoOi8JfFeHAzcb O9aQNQPDtiTtm8FFQbh29iH2aqPSqe5e4W7ZWoId9zAviXVzEr6U8/G8w0/qAHt6+szX/RgTvlRp dH9qpcpKMNubb1G2eLJqO+dCTGCEVJopuqwnKil1kcLHfXu6PXYmouilSuDL5X7FOsHl7yhXnScY HPKRe1wD65goLoeIF5KwJ02lDhyN4bAC0klzCp2Kjdq9XTTpMEaLOdb+Q7KQXiZ0KsVsEICjpF+3 +r3Y4vQRAAehpFzf7Vf2UGBAUO5otNJFAfHtIUQbil+4w9wN6eix0XbP9F1AqQ+gTpCt6F4CO/Cy kMxDx8p30abL++y6PSIGlZ6UoCoUSepG7bw9KBCR9L3Hg3i6cRx2J3awjTgVwhYyv9mtxnFotzbD WztWmrdFwc3YJmWFs7YwyimPrbXTYQ98mxwhHcI9mr6+5JlwIQTjojC1OnWDeNSbOEZw9mhZwsPY jnUiuCPtR9tAFXDWhMQY1iQBYHa6NME1nKu74wPMUq6y6EAkB4vIqcEsypQvSFojqBgsCwW/ARJv ZQVfi8ZetmaDsyhpJ3DTqThkhWwI8RJ4mXXgd0hmHPOOtMzwBHfBfzBWb52bXtSaumdy4+o3rL3X ecI1x/vlfHHLwxnQsy0q2saNPR67Codxr9iwV90PhxORy21tX9XFhraVgfqIxEgOz7ORhPuMFLkq 8M1SrQhbCbT8TOzyQ1GfF3PgalFfIePcoSulblDKttyCdkERcwu/h1AHmaogR1oYhpgsV6hJA3CS nGLeH4qjfYaQZ+0qcOUd0WFnzpztU3KQ1KEvfBN7zH21YMZpx2BHtT2aFpfCKnO7zCvpXjDJMHf8 EYSyHAEVBTIva1bkd/0KyAesmaaLR5aTlnwUDWBLO2E13cteeGhg3QronBHSEc1fX3Zwsw/qYeI1 yahsx8e4xjBxnqiYWeqPt8e23a3uLSSzmir2MGaS8+JvAYkgntGj4dhHe0Tj8Qmxjd359UW0Na5N C/9hiTTaZwnr7Cxc39p7yxz2d+9BOOvcn4f6IKrsbRGJx5KiZwxDqOK4yVvL3oC5cL3DFVILaFvC c7ZIhhaeYgXsfUKCdDU035/DrZT4gZsOTQQrEPQazpN8SGxdZCjcJsDsndvnhXhkD4+qTyKjGw/I 64u59JW9x08+bjoLloaRku+8+YrkmxQLvI2hTCPGdSa7ue1aH2EMBeOR+cwdfH4edinC0Qee6C8a 2nUzrIAsSJjRZLitHXdF5gUrZgnOLrq2t8hwJTsMtFsLsa2I5HJIlaMq6ss1Vx5az9tXthga86xy NLlJS9F5/g4GOGRc0mMWdtPud2zDK+4ptYsTWo2nIrLvs1pfK+dmFKmDyNJInZdbKtG1fXbYodvl 4R4zNjsBhySSh92HdcwBx0cEQyYbWp8WxMBX7nqt7gXTj0pxTyYb3TsbnBdvAl1YNG65NHJzE3RN El0JG+9wQ9ywpjEkhhUQ9of0iDLO2XsYNj+sOe8d5/loiwFsBRCprUze6yg3FeBKOnxb+LPRM8kV 5Dawqf24N2+wyN59VQcT5JakicZsfVMMdhCO3KI6uW8o6lW+okOQ5WjGyQhpF8l2NEhU4XyjlJcA s6j0YN3MM8AF6iQRlbdQVlfDXBAvQ0os5HK0SmHPNo/Fy3USzfizuF3rRHTNyNFUjzxnAJMAKdYV ZTsja+LXIYfNsy4qx/mwEyyE6hDIQ8DZwKIwZ2dxbwtJvdtjrYS1SOIjwrBbqQI9jqZAUYqf20VO AHdvhgO6pMPdIalE7yjAMj2GuUJzryLYyxgMjaOglcfsAM79TeE57UFX5slZ7eOB4fZMRmjU4YCi aayn6aDvAZGUJcftNuw0BCs+YmOSgxPs6JXnSvV7yVs1rp1GX2foDXVfTuBAFSdEMdboUZnnSatA n/cCiT1WXqcItzQLojpWOhvXsMes0UwohUp8wO4jwI5hpzuibiZ6BdwFVW6a1pMyTo07dI/orH8o /Qd5nF24l2rt7kkHtjHjIUMGzSmLjjoAeV7kbdihsNb73XKvRqDJG/aeL/MNowrWCAdV0CQ0vekJ YQBlKWiw3TDkznpIKFJBa6RVUhXkYU9OgewKtji4TYYXry+VovQqD1zqkvUYSbag61zDmq0CUghT EEsdv94rWhTZYqsMiW+Xjq3c7ztmFMYk41JCCox8ZCACrxwJtWVDdJ7Ezfm4eldFFMsSf2xGL23t qpSUmzmfJel+wIIiDPgMjsFMpePIgPI5MRZu+E6oyuIMoRwhnpl1ttxFE5kzMgxbBIfT4kxYIBBq qKLdsczmIpx97mioKhmkWXwWRMLwHmJX7JDDOfR7Zy4XpxaFPkEOkL9tUzlW6q0ts6RnYguPrxOe cbmtAwkLd4SkiyQNrHnWgXrnK+vA1KBXPeQcHgvuqipKzGm1zC17SsMgcwiIEPOy4KwBvJYF28Ew 5SAlaxirnOMVR5kt9VDyPCdVAwJWZyl5SGEIwxlhQgNLN3WEzR1sF2iTfn4WvV8iI5cM0Su3HSzq 20PC2Q7p1hplbKWi4lAL0pjDcssWA1X8cFMkeb8RWdtaN8PD5iiIpriC8LYQKtBv1OPAZPxeF041 j/HMGZwHgavvg9Xy/izzhu3s2bvIOwLLmPvDDEgYuOR0Kw+gn5Lhml3Umhe1owJcALN+mTWQDcm1 UDPwkJRRkPc98FcQsxk9K9GIkNINTSUyKwxP55SzkKVJjjD0VqpQOrAOxvSwyxtWsPP5BpmqFLo7 xhXwcCcRdd8aUuzv5Y1bSewMGw39ILmSWRuMe8bvoNTNCs3r62V3PbRa9LiFwuJ39EIzgfOYIcNH Y3WXBRsuGeVN71qdEEm4QhoY30zhJb/FO2R7ElVrU++D2sOywKtI1weZYiirGUzVzOI3vVTu/EZ9 7F5fDG3Zur4U77gd4ja4W3nSw7TLXOhxarZRw7eGIDmfNhXRpq4D6PQIyL3ApHdczPbIxrbseZPO dY972hN7T95+4Y5756iYWyd2c0okRkClq+MjV34uCrRgVMgdif2tEzHRriCRI+8bveGuJQ8m317w B9WcKZlepdeXrklnlenVqlz35+NxPwuTcnYe4nlQH8dCOW7bMmv4QYwQZsMBdC5mH1GJwbj4XA4U rRhniwDMQHmWv319CQ8stlCHs/CYBFOQ9oITO31A9I/HvhZmtnE2V00VnJSwio1xFiUQ2TQwN8a6 TkL6GCNZ3Z/AptOR/AQzC3a0kdgguOXEQVqkjB8beDyMe2Rg5zmn+L6qkgX1VBx2f6LquJNYd+Jx IhVkPc2BGlRoJlXFRq5E8vkbHd2hB/eBxrtCBvlwSZ35hI7h7iRMp6zc64o9A9uNDtkpSdpU2ct8 YTkbupcThj3QacMVVpSKnla4pwEiEtBK8aJuhfNVofPrw0BrCtH9VNybQZldNY4zsR1qIIjqbdvt Og83jGZmhCe1IfIL63LzhtFnzwnn9XAXolTplbFZwbg1cGvC9vy0MSjMXaOevwP7nBhWipTR0S7K YKc/hO2AaIdqvHgFyd+8uvHuzRreFhWcQoi9mRQF68xvBrOJiaWsNzCN0zNjRRONJ8ehx8OyA4+R 86VNVRAbUK0Stw+yUwVThIblItr0bHRFUTmrY5inToBVVkChKo8oXNtxEixVksgiS0SEChh5Zads rWHkzMd2f4glYGcrrZ1FQZ3KMIkTpxUOrnEwzLm4v74c0NLZyT0aHzjTEDd1lwh4M90S2L023KJ1 51hf3MHXoryimHa70xv/LiUOVcwYQxh0Wwi1bHFH8DjEEJFuUWFe97BGJZWx3aNqt5MZAfBne7em 9t1GDiW2UUIQGuVmIHL6RLi0IYOyE2Se52VwqbQbxI9deRFYWJ0bGWYgPjAtmLWLBIR6x8PO9XZ1 mELgBBUgFQUsrCoJmZrZS4bySwsOlYbv61CtinA7k5Z4AARxcATYyzCwqVaV5IGb3B6zQ3KNbYOt A0u3FWxlh+TGHnuhGopsPPes3+18cIl3ze1wqu3xRlbFoaC8KhGs8/n5yfaUK8OxaLVjeJZQqT4n PEJxPI1mYXHaaFOR88Y5nIMUN5ytTNCDj0NsBvLWOPvD/DCTubg5AFLhXr1BbbRgHADg6zjZ+F3p WpDxQ84bJjwwFN4Kd9e2ja+Fq3Nghl5Irm2B8YeZ4gR0RBGSKeLnX0bIEhY5YHl90QtxVUVzSpXm EftZlwG2RVmW3R9rXLcsShXxMm2HwvLt4fmXEA45TTDngpBg6YJk6W1CkyTkCcE2Pb6+DEsOOfet lRfmvFv38dOWPWYeQ4iJorZt4/ggULPYqHb7qGZRAFe1lCMVrtZ/RHEaAYU72fSWLKUa8t4Telpl H67mXqPqUeLCUG6JwL/MLg8XJ/Jg82T4ncgVxfPzbx4y/+tTV7g/lQ8xJnAmla/MTtT4R//60sPw kXM7AfNgCMdLCEQRgjSRnq2uWIEBNgELGisS0tYrM9kT41OCkih7zmT2kTug0wLjKmHQG1J0fX4K mh2iOromsusRyUDyj8FSAu4K4SdAlnp2Ft6x/U2tck05ZwuaKd4juRiF5ttHabHmgWMGEWvucWA9 Xl/kQ9yAZd2H+OLGPt5I5ojcUdxJCLxMirGLrWsQB9cybRYyTZCNSXADSppYaGWUKrN3VbmgJLEl EwxADAkfzZx55kOvOCGRm3P84PZRUOHjnYwzXsgkYoPpFx9szQjyChgIhNkknJvGNt5JOSmEJn48 BVyiFybsnZOlTOItgee2XR3HG3+QvZ7OxqnBzSm62KQqe6mr1CvEHiK7GIpFMHbhLdpZEuwNQR9I uUDlB+dXgQn9xsHOEZ+XcSfHJyk83iKmxBAd5iMJrhHmSbZktLanHR2X3avyUT8Vx4Nds96xto4Z m2U+GGDca1Ey8hCRpmMsyt3CHigh4LtUF92mVdce0c0BkfWbnN1dKyQKJ1r3kh2UCafUNxvjzjRM F1iV2Yg0hl3L8iC0yteXURbF0MUC2C+LGZZJ6UUrtFQX5HNCZ0ZXCBhLyLD7nXKcTCu2MX0YL7Uz o7ZPQMqUpCuz4xseSyl7hDyExne+6x0TTDI8TIp4n7l3J35/cOZdyuP742PpXG6l3U3dW5i0tzDP CCRTHwAWmIVZx45ZZ1a20a+5CPP0XDAJCXwGq9vxHK0CEZUOerpJrUNPsOpJvqgnrWhyM/6IlhD2 uuUSkOERJZAz42+X+WxUFmkPO5WEeYpSd8PHNpruRtpRdIvb+sDGc+sn8tbLCe/q+Mwa8Pe1rR7U JLOXtPeEuz/ygxKViWkyV9CsuqBdIOM/w8zKzr7Z9DkWADjHhUk0iaAtDqHS7KqnfpwPpyENVLak rqdDSITDkVNmz76UeWxmi1cnZFYe+OE+JIr2+sI3Z8FbcEFRMzmeGSUKkcB4DPtgi6+nA3sug7nY ZbfHuLYS3w4XaRETaYD6ZDcig+N1nETpZnF+vHl2H8mUNjMiWnMY0crixxSt1Tqx84n8hglUDOtT OYNwnJJHruxnm2a4YsGG8eigMekrzRi27AD31Y/vq/n6ogijnMjoXWfYUysCeixLLPeugeWYN6Ae sXg0scDKkS0s5oB5UMKUtce4smQkx/dTOsphVGWLC8KL10IMmdzxLrNO5Fwv6SLC5DxzAyQvsAuc 9itslAg/ibHJTRzUfWyiOeLGu4CcLdBE3akhFUCV5cCQDu+gz28VI3nvG1HP+bwIMgNfs8YCILU8 xTi5RZhsZOsEFDBbBpDl+HhVcLALeciMYo7rID0s5vnxUDlAgRCu1BjKQsGLsAbzwzFN1F1Hag9W x1QPlmtLnTEURQExnDfgeX6ozgFgsM4/OMlSJMmF11afIpk+Uw3jqa3AHrArEgRdVXmn455ndS/a e9htX8fhgs8n2BrKsHaEnmQysxWVtbCGl+WEcmVT1/I83MEcRdrzr+TO4ko9X3GF6YhXeC7bs0rC C1DSGCz9Y4RaXYH6PqKo9fpDPovlD3nXIq/v8rDPGq3jx4juNoLufURV91j0lCw8H2aYZUU9AIJJ 1NBG+ZgYAgbPvt1qtxmeHYvrIpnmntqghBaUm/opeZFNZHgfQafygr7Pl1RbRoDBGOlgr1CbPQpn kzUddU+MHWmgjMMDmh6lGnZb0evL3Irl+5ywhSwiUMI5OappLdVuajnSNk+pSLjATuJpj3Udirp8 2lO5l0ct4lMtuZ6EMjyAi4LY20PMTm+WZcH5Hf/2fga+ZD9HR/otsPGnb5z2grHPe/V4HfWnjMZv hRByIXjPOl2PIrQfrrRWhHSFNRXqXlrj/JzXikOhWN4dJmyaIYJukOVNRD9luPPkx4TznL0fi7vz nKHCJkJ2VRlWQC8NsveRkG212bv/tC2lvGsIM4W+vu/vSdls30eeVjQfnrtAMCedpg4wssJIQw4K hiKvLxbTWA4Mne64cwU+KGvHEx6eACmMZTTWujzcg+YKu+s2qh8NmBsiuWguvIOkPpT3hGv+lAeP JvPx1xcB3tNOgfl+ZUeOzxHWhsyeI4yeZJ8jHun+TMFZjatzxDZQ3t2vDA7lwarfZijPXPqWnZ5/ XSjs3Ds6NE8bl20GR1jGZpPCEQcNp0/k832TItPzvbtHTk95wUTQQ7bRIB9BuYgNOARpUwyFSC4s UiKazIGLtq0fbSJO8rjA5TD6foFtvHHwwW4SHvJlm63HgOdPwtzEwza7NkXpFylXnGYK7i/gC7sO 4Z5qpnAsUjk81pvN3i44YCw1Zu6FMzAFQG0XTef6mRavSeFCRrgZ/Oa844Iq8q6rKl88bzyjfcut ma+tkIeQ2jVsvVqjZUs0Rj0rKZf3l9p+7HcN5VBLYG9W+xjNoAzkZXseNvFjJObu4Bun9pZs3MKA PC895JBRvr7ENoOeUIb74LeGIiwMWtsuUykozj7k6w6mqFTgosVX9KEQmQdBDZxJFLyzDQisA2Cf ArIQ/E2w27y+BIBngWoBq4DEj98GjxkskFQD+f3PsYtij7bjgaVRsPPOdAHd0/CEuRBhS/sOVwAJ 3S46oVkBuqYHWE+LKPFTIeWBGwiENxljTdJzCNYmJ3QuJVE6Rs3L/k5acXuFbFUohoCeTVrahrKJ jo6P9YlMTzTSPPPUajrJ97SYx4dAQxhkOGQVv4hQMiy0e0aAoGpyzp8427Jkthk5SZAllL5rhU8j qZBz59PWEnvaPUr26ws43bfZWYo5i4MauyCQpnDwOkkUr1Oo9+iWTvzM8lzJp1zO9/DyFlpSv1t8 xSClecikFm3JK5WIWZNBbVgG7EKUaNk+k7Zi+jK65dEGJNR+g1PEVvLwDbC41aBMWryXMr9AFJpP G8i2F18sHUgULn1fW1zowirDY/3WzZgEye2DJHu1yLuWdIvbSPFBdjyQUuQG/NwByIMJQpaEzC10 idBqcgMW7ihNwj7UhOm2SnECd+GUGrvZGiNpdt0NtSq1idJ8ZcawnizpbOh7yN1hS12GrhYcyR6p qZDuuUGd5jsBs0pXHClJUIFJJ5p4fSl7rBYsQ+ZE2InLipYsYtPSeMHNrpCt4TnaMzq7njbcw0sg HZc2M0PKZFjSyEbj5mBYbZ1nm/SArCn1+pIjzHjPatjf3KzJa/hlZsqEWAm/WzdxkUoAlg9hb3jW ZpwG5s4LnjfZs7u9+nPUEginsxcjO6hcTDQQkaqLzN3t5AJtOq6P0IyRJU5mOAJXogF2C4bFJQkh T83WxpPZnHbsJMsHMwINZDqUyB65PCEZMtxRHPv6klbJSfCZJjHUwDmtm4NlVJq2OyZ4vx3ZpqZR UUOIVmFHZEoiwG9xPRATVtthQ6Svp8Xv0Oqsph4i+RCRvD58XODVYn9M5ZMZ8/N8uJrmTm3Zdksw 5RhBSn1I9cl35mGiSKqoi0e7E3kqXyZqKUDaAGBwKgRZ/fm9zLE6WPKDTUeswN1BzNl5Bgq5v9+2 R9soACGykMmXsJ9NbEVbonNkuaDzqwtmDriS7M6U2J4Q3iWK5vXlPuD4ZZUCjuxQ07fMjFnYvh0H 4ADFDWDRYvAxucOJfQbCaK2UAXGP6euD983xTLrX3KGDzCMDETOmJyI1PY9RXs4NSEaExC6wJtit ZVk+ydM9TVw3E2bfsBN+GoRT2Oz9mo75CT34kjD26Z0Gljp4GJGOB6htF6oADcUUdERFJaogNEA+ EIXG8OcU1lae27qTbVTuaQ4vikST93YWQpY95LmRlGJNakEDa38doOrzLx/JgF33R4g1oOLcnRK5 veS2QenR6L4mjlRCuCAFNuMyd1q9tDIwLRGA231Oyt32cqtVGbPR9DaoAtsIkOEHDQ1muUywh30W lhoctrDPph5W5xzDShwgnbxGxFa4RAfaMVktsUwjY2vaCEczPbME2180Angk6Zve8+/Es2SQnVqf m41DRDT9kG0WYTEBM8xDkEU9vxwxVx35xAKxY7OePbVh6GkOBciB7g74euyTAFMSkJ1eX27cdJWv 2YMhshUcD6qsq5cCB57hG/Ldl2oQticeCINjl0oz6HS4XpO62BuSxAjqsvBAyuSeuPSZ/Py96Fj2 cDw4loQF+dblRLYG73jDoPQPZ3bak9a4KrkUBz1SMlwizI2VHA+CH5pm0JqzJ3KNeRGpPXIzZATm gt2yj8SXsGM2+lZc39VaPNjIFUXprBFkts78pXFk6R7Js32U2XPoL3LMeYxepKlLX/xdA1uzup30 BKEhWhbhdGylUcdYHAxHgiDtGdR2A7uJi65o/gj5+30xvaTFVed47V0fH9LlFluNRYmYo0/OYA7y pra8Adp2PF5hx4qQBii5TFrOumJmc6dRZk/ZLjJzmE81R1mqQzxJNWQ2U/sqJqQpymxJ3x9c6slM yR/RqDzED8hDRHOADA01h8VLJfMxnSh6MEMeAdebu/MFRt7cs4aREyKEJVrQdcbhsZOoua13OZKc rvPghBDeBnbpsAIKtXeH1IuBeKwEgDHcwGvIJj4MrDn0RZjbGeVSqk5bF7N2rpuNS5RNbnIH7OEN 4qr3qmTMk2Gi90v5/DaWYAeuuG3KUjSOa8PHrAtbRlCqxeV+JLQb51osobOmdZGOB7mprYuGpwSk c8IxSfilZWPuhF+icUbqEqIlKJSkNVZeccnsMSsBYe4u/tIqEoNnFOzJW7NJFfsUy/bDWESKLiDv dDcnTmJNge3GsR00w8fH1i5hvxBfXNPr9FAhYk8m4tW0Y1722KtcayMfq/ijzShRXtY7Fw0pLmJy O0gZek6Cg43FYRaGpAB7smpJjizkbyFBcElRtoy3HWB/scUi5kYaDUcPI5YQy5z7BZEijKeq3YEj rICI7puFpQ6HmZnWPUmZBDllF/Oegiv0W1QMOzHfHBs7DS0rqWbb25k6c/TaOMdsoO2Z8uw25ibj YFGqo8uAjWcc0yD/M8Wtg5Mp1h0coksRIQleX3DXSVeLvidypplIo3i47uErVZG7pmRq00SY1fSL OeYxjk/IUkibdpZKW/TFLOpcfCff7Gp3mzkmUc+wygT82aVgr7ERt0Lu4Fgv+G1RpDOj1LrXlopn MAvhNfHct0m/uGklrYnAOMWl5GzOBzKLqKx3n2TMhGiZXg4e5FLzxXYN+4ldmGBMnW1WcbgRXeMA LNgI2RiQRf75jZ2qnRnQ1CscYi0P0RWYORvc+kFItHCD0auvg5DPFgcZICodmEIoLGtz7sQkSoC3 i69kwSktf4J5ds/2F+1w5Sp27iNLKzTU2TycTZGpG2LP4wbE3oGcTHgL6FUIc2YZXDTahyC9zCIL 6QMvJLkFthtwKUQEO7JZrMy4T++sz887AmIhoJ9ff/0sHa6YCt6yAG/CM0BRNigYEtJa3qq19387 roZtJ5ZyBOkq1bIV6Gm2CVIf7x/PNYJ5+s2dRQEgG1eadLU/pQ+1kbbCFpgPIVUKXu1kuzvMKGlj Vep+oxlqWxQNasA5asgLhGbEbLAfgQudpySZletKd7ijnJKIaQ1HHqbMar9cSxFHmK0dh1rCiqII 9BtmyabEIwJ6WgiB6p5PplFsrMFZpDmj8KjVgS8YVaysXFhmR9haNslYymHrQgUom1enfFM916l2 CkTyx9odgESyFEBBEDyqOd8Fs93OeaHOKbDKwboiqtBvgTJ/aPQ1Yq9H54R6fypPNafarFhMhTPi 68s5tGbDeHpRWV31oPAHxJ+e7zV/Bz2uzsoxrU5N4Bx2d++E+PO77AVkINcAbHa5/VSim0Sc358V FuY1Xx3QL7v8v3L8/8+V+p87/j+jrQD886S+v3z+XihXPLXxP5LlgPz+ND3qb+9/nN4fkWZozxgs dv+5bRzg+uf5+bS0Qn4+2Yx/nyF56tnDfyp3f97nIY68vvzggWjPHlx7Tn57vhaqBOpE/vNHBT61 PRHt44lrPHWBP5PiBw9q+/aAE9VQSHh3xU6DJ6l7d8d/stJPNqpPNFSr5xP20n9k41ObgGFQYjJ/ ZJPiwPsG9gMNwgh30zzaX1/7YluCwZnJH2nkg6fG+kcaDRNq3K9fNP7NSoUeauDU5wy++enJgIBr sc9bphydz6Lll/v8HmLvZwntTwkH85xj7RnGqt5tcTGAKIleLVnO0XjorT0kgBOOGC544rwa1aZO YOTYmK29vjxHRPIyABE/erXpePzHXc8zJff8eTQAz9+wicTlGl60Mr00cHM4JQpsK23Zs+Xbddo+ /z4rhQEJWeY1k7hHQkCuRj6f1cc5kZ8JicyukTs2+dNnz/sk16QX+51fQk1PjW4UlNiR9DDrHXuj pyYo/Pyuz5Wla3L5H3mi5bfH/49v/3PH/wZt//b68v5/pvt/AFBLAwQKAAAAAAAoew4pAAAAAAAA AAAAAAAAFgAAAGRpc3R1dGlscy9jb21tYW5kL0NWUy9QSwMECgAAAAAAJnsOKQAAAAAAAAAAAAAA AA4AAABkaXN0dXRpbHMvQ1ZTL1BLAwQKAAAAAAA8WvEoAAAAAAAAAAAAAAAABAAAAGRvYy9QSwME CgAAAAAAPFrxKAAAAAAAAAAAAAAAAAgAAABkb2MvQ1ZTL1BLAwQKAAAAAACApQkpAAAAAAAAAAAA AAAACQAAAGRvYy9kaXN0L1BLAwQKAAAAAACApQkpAAAAAAAAAAAAAAAADQAAAGRvYy9kaXN0L0NW Uy9QSwMECgAAAAAAPFrxKAAAAAAAAAAAAAAAAAkAAABkb2MvaW5zdC9QSwMECgAAAAAAPFrxKAAA AAAAAAAAAAAAAA0AAABkb2MvaW5zdC9DVlMvUEsDBAoAAAAAADxa8SgAAAAAAAAAAAAAAAAJAAAA ZXhhbXBsZXMvUEsDBAoAAAAAADxa8SgAAAAAAAAAAAAAAAANAAAAZXhhbXBsZXMvQ1ZTL1BLAwQK AAAAAABokbYoAAAAAAAAAAAAAAAAEQAAAGV4YW1wbGVzL3NhbXBsZTEvUEsDBAoAAAAAADWTuCgA AAAAAAAAAAAAAAAVAAAAZXhhbXBsZXMvc2FtcGxlMS9DVlMvUEsDBAoAAAAAAGiRtigAAAAAAAAA AAAAAAARAAAAZXhhbXBsZXMvc2FtcGxlMi9QSwMECgAAAAAANZO4KAAAAAAAAAAAAAAAABUAAABl eGFtcGxlcy9zYW1wbGUyL0NWUy9QSwMECgAAAAAAaJG2KAAAAAAAAAAAAAAAABEAAABleGFtcGxl cy9zYW1wbGUzL1BLAwQKAAAAAAA1k7goAAAAAAAAAAAAAAAAFQAAAGV4YW1wbGVzL3NhbXBsZTMv Q1ZTL1BLAwQKAAAAAAAviRkpAAAAAAAAAAAAAAAABQAAAG1pc2MvUEsDBBQAAAAIADOJGSkcFdYR kQIAABQHAAAOAAAAbWlzYy9hcmNoaXZlLmjVVE1v4jAUPIPEf3hSLxSxQD9XKqcWUgmJJVXIbtW9 WCZxiNXEsexHabva/752QpoE0Y/rcgjKjD3vvRnHR1LRdUpB0uCxe3LcaXfawx68cvmNqiDmTwxi RkOmdKcNPVgydgUxorwaDrfb7UA+bqligyBLh1RKkSEbxJgmdu3QSmlUmwCBZREJQq7gj2HML8nE GpCuxy1TK91ohBWD0fPocnRxvroY5ZvtOh1nCiHk+lFs0nEdi7jSaIkGKvwMaTKZcuXHXL9DjWs9 iJsXZHofzaI6VOw3I6ZMYMKEgf+Oa8N9ZbDT0cmBwZ6MrTwTJDUGjw8R7BkVDbDBrSVZcYwSU2Sv P0lShnEWNvCEaiRpFpKIJ4wgT9kHdEixpPNJAhWcnTYAW0Xz18aqjdiHdxkJmjJiHFtj3CDysQ4R O5MPUbtDQDRS1TSEmw159xSxEaMpc5gw+ZIkC2hCirO9n2gUh58mej46+yBRwVjImkHYxJpH8v9M q3DqzSszBLWdUFIzzUSSe1a9NasWGkf1qye/efBFGt+ifEe3t3D92e3DnedOjrsWCbKQ9WF+t/Q9 QNNVHwaDwXEuZd6YEnDjunPYfTS5R9ANYqqgF2qzup5uT5pnHwpWq6DfabdaLYCqJpjzkaxMa7ZC XX8jzO1IytuxLMCV9a9UtIb0YXrvelOwM5fyn+gXm1MqzQHa7gYoRPLTU6pboqpWSvckxTgPUZpP ZH9c+/fFLgoXhd4oc8a4YgFm6qUctCxS9mIbzeuV2u/Lm8RNuFwwmM48MvGca9+ZwkkFT64XxP3l ePfezHfgtCJuZ3PnbcNZhf+ez26I43muB+cVunxY+s6PHX5R4YufP4hVWsLlnnRZ1HcW8L3T/gdQ SwMECgAAAAAADrUSKQAAAAAAAAAAAAAAAAsAAABtaXNjL2J1aWxkL1BLAwQKAAAAAACJvBcpAAAA AAAAAAAAAAAAFwAAAG1pc2MvYnVpbGQvYmRpc3Qud2luMzIvUEsDBAoAAAAAAA61EikAAAAAAAAA AAAAAAAPAAAAbWlzYy9idWlsZC9saWIvUEsDBAoAAAAAAA61EikAAAAAAAAAAAAAAAAXAAAAbWlz Yy9idWlsZC9saWIvcGFja2FnZS9QSwMECgAAAAAAPFrxKAAAAAAAAAAAAAAAAAkAAABtaXNjL0NW Uy9QSwMECgAAAAAAJ7cWKQAAAAAAAAAAAAAAAAoAAABtaXNjL2Rpc3QvUEsDBBQAAAAIADOJGSnQ 5TOW0AgAAKMYAAAOAAAAbWlzYy9leHRyYWN0LmOtWP9v2sgS/5lI/A+bnC6BAC25uz49laMVBadF j0AFpElzqSzHXmDvzNqyl4TkPf73N7Nf7DXQtD0dimJ7d2d2ZvYz3/Ynxv1wFVDy+wPjQfSQvli8 KR/8lI360XLpiyTcGk4XYXT3Z3HwKKFptEp8+mJxVD6AiYDOGKfkZtB/5/YGA3vpU8juXuI/szbn LAIWbe8mAi+Zy0GbiZf4C3Zvtnt5SroRv6eJICvO1o3YEwsiIhJEqXo/fVk+SIUnmE/uIxaQGVvL 8Yq/8BJyiu/V8sF/ywcEfg8LFlJSkQuOj/UsgckSm5GK/CTtNjl5eQI0JaTQY+Tk9vakBWO1Gg60 FLtN+WCDQr4bjQaE8nSVUDdgCfVFlDzaEnBvSetEfXP64MZeIupkOJr2zz9/HI+6hEeCzR53BDVr pbD2Rz7TJqkAiyX5UF0KW60qxXpXo3GPeEIkKP6pRXdy25Qq4Rx8vqfiHDbtwBe7WwmaKjuh6NWW tpBa2iaNM8UcRYUTAukXjM/JLFrxQJ6InEGKw25CPUF7uVVyewwvB4MqapNpXyqpV1KZfJ5MnQvX GY9H4zo52uHyc1o9qpOCgBtbyGNy3h84bmc6HfffXU4dt9cfO93paPw5l1wSERqmNBuaUDHwUuEk SQQWPfv3r5KzUeafk7N4DgZaZjCHFz4SKlYJJ9PxpdPSgAObX19fk8kiWoUBuaNC0ITQdRwynwka PpI0pj7IBwxOwW/A3WM3ZU+UeBw9JKSuYEs4YcZTQb2ARDMSzxZBcogEcHwKqUsvdlGkmcSiAtIs 9OapgTJOyKNEi6CoRcRrNAI+V74gyB/m8JGtf8YDPnSGvYFDFojJunpceHEMMNPWUXsFqbEW44JI HdtKl8YbS3G9BjEx7V84ZIZUOCaSR9ebe4y/1lwQs1JJPGb5Agy7Y6cDGBo6V5qRlAcn5HnLj0rB GqX3ztAZ97vu1bg/dcj/iPkGTj21oqk8QH0ou8rXLeAOR+OLzkB7SyuXUovQJv3hp86g33OVxVz4 uHRs318r585wXZEoTB+Y8CFMrtVS3wMvkCh25f7OdX8ynbzeAX/urqTS7Qzd0SdnLFWsE6N/1cRO +JW+bSi59NvWkssKJpMj+mQ6g6vO54k1/g0jyjWZ55e2nBsnjZKSkdFy6gwtPZFPSXsnMjZ8N/p5 Bzr/1Soa92Nn+gGkmbrno8thz7bvbv7I7ES2PEqLKmWdR5ANMxTbqlnSnXcGE6e1LRZkcm8VCiNE MfatqzvrN4Ww9J0YLJrWtuze0KkQoqJmwdBFO2s5cknyLQoHp+DRK/JSVL0o7cGGUwiE0wi3xTdI Typ2hGAJdxkFMvi5ASxU4ALCvSswntbJ8UwYF52odKqY6igG0/k/JUmugYpdbdJUdoMQf0WJ73HQ h0AkJh55oknUADXmUJGomNwJ04gwnP+Lpsq8PCIpQImqNNwNo5R+gKgfGim+ZUw70hb81oxpZXJX I8onycfOe0c6rI4H4KyoU+50aoP9Im1hKhPgH4ZWpsSPIQyyDNgCiD8x+jCaKZDagmpwSMxddD66 uQnw7znlNYOiDQ5hwx/UcUu479UPH3pCpdKNQiWWtOUDuhaJ5wtdAWQZdzunY0rX+ThN/GcL2ycX SKm3JE/q2cqTNzQaEI0Kdoilpy2pWEQBYuHG7TnnA/RobR0gW6NuYQSH6ic+nFJTs8Tfki5TKkjl WO+WgRIKnooeq1YtAj32goPmLuNYXSf+nnnv3mOhWqBkzCqN2hnKU+ATrRA9eaWyy0itiPdULbLW 68QQ9ykXUNh5HOq5IPJXS/imUMwBsiFtYAWHjddrjDtEN33AATaE9MDpHBqke0ruvXAFZR8MpasY 7A2vC0rmTywmC6gDoYjEAvEO4g6IACR3cOxQJyyADaw5VDFFnRPIqytSoxIe2I07+g85bEP6gHnG oaoRtM+Z+MU6gsbZK9OcGLI9hbXsLw24bU4arin5OQCE52kqE6uQ7GR69EPq8VXcKudNwo07mUKs Av8Z9rYFtmS9gWpo2J98+JsCf7+sG2NHLevrTM5dgzo8yET8m4IBix+WTbdK+/xS5yxwNz9+rKgI gYFgB9E6EO0CaGNKlp3tcfaSL+3whjsYr9XBKwsepj8axZRjzmRxwwKzvlyQMNfBjXhhKAMlJFDo liCkRNIrVAvFwMeskgz6ciiaWUq8NAUXDNCV6JqBOGXVOam4ueKwr2s2M4GTJfY9ANQUXp2oEl3n ya+HTQx0XGssyU1F+MdF51oWlV/s2VOrk1TDYJEEOz3UjHLZ8fkQQRIvtNSDZ5SoBh5pdJCHYOn6 sAgCPVbylZ3h6jHq8ocsYBo6vKryAAuE7fXVL3mIB63ASJAS9E2GzWGXEKZi2njD3z0KmnahySYN 2AaHopn8trXFuB9HKRMs4jLgyT32qm30RXGABATJhaqRr/DHkotgxQ4mBTwgJBBsqjDLOKKvAL3w 5ujEzXXzX81Xv929albzfGzjPOM+iKIYGCfRar6QZ7YjdV2eJ9YyiF+cZRDZzcYzLOG5zIaEk9+V 3aaR8EKpB6nVuO77VCOPUGplnzF6TP6pMldJH4eGgnzkaCggAYz4xaKwOn+LQo0aCqSXdnbDyPdC V6ejWoaj7Ehy+GQWVsS5kX9pnhkj45rtJkjSqCI+p/mt+etzNIiLWnsbmhKWOC0NiMopi9l2wOOc aohgLc9XcF6CJkvGIRAHOqlq/loVyc7VpX7NjMqAlY1qQfUc3ugCCPSsNFFJHiMI9ayJy7rfhW22 lEMLVa3p7ASsMW1GW97dWVtudXqIDMgU9mWgjo5VjRvfE/bs0e3tkZyy7s2OsxgYAgGwty4sDfz4 Fp+Z7qd3xVbHaC6Pd24+s73UVvmCxtkXRJC8cs0yseoXivdnzbyNhw4+u6tVF2Im4LfKeSrPegAp wGGxFpc5VtPKcy7eCuyDMI5tEI0yjb99+1Yhz1RE+7uM4eWFvBCa2DJXIFJWiyElu9KTc7x2ZvLz 1y4x/w9QSwMEFAAAAAgAM4kZKWWXB8MsGwAAllMAAA4AAABtaXNjL2luc3RhbGwuY7Q7+3PbxtE/ 0zP+Hy5MI5MWRNGOnSZSFZcPUMKYrxCUZcf2cEDgKKICARQARcmN+rd3d+8OOJCUnc73VWOLxGF3 b9+799Dx86dP2HN2lfhZxkM2v2fTZbRyUnbBg4AnBhs49+xls9lEMAL9i+WdMD9MMycIGq5xy140 fiSI4+bPxy9fsxc/nrx6efLja5YJQuZdzP6CmMdPnzx9cizn80Mv2qTMEnR4wuIkuk6cFVtECfP8 NFtnfpA28llrDrsBHBYtWMqDxRG/yxLHzfzwmn3x46OFH/B6DtzKWLIOM3/FDeCCM37HEYAtgR0n jnnoce+EII+YG63ihKcp94Bwto6PPCdzQD745x8BMysnMwAozBwYgNmQ3iIKgmiDTykHHqIwJWqV jyueOYj/mR6dNaggOTtP+DW7chJPG5zxleMHZ9cbGP57fA9DYSPkGUF4PHUTP0a6Z2N6xbqgkMSf r3GMXYJm/MznKUEHvstDl0tIGgqdFT/rKh3S0DoJzpZZFp8cH282m4acMUquj1P/Oj3OFX4Ej8eE ccuTFDloNn4B/SjVVj7aqCQhnx8uojOWgSlYFrE5R7vFgXMPqgT9keI9PzuaR3cEHmdL4oxMjG8b MMLIMDV/wULOwSxkxErmZwEAblMF78yWfqp8RYA6yTXPZpJddsaAFBqUh2A3ISdTLxP+z7WfcC93 lCPmMNDs2s0Ymm6GtpstPXB7YYS5srgzj255jqI8bscxVpG3DngqGZdBwj1yY8ZywYVbgfOAS2pG uQFv4A1wyGNw0jDKeGOZrYKc2asl4HgRkteUACNvJGNIWvfhlK1Dzb0dCJ+NjHNg0AHLreIocZJ7 MkJDUilT+OeaJz4gb3yw1TnPxol/62R8nESE02gwF0RMJW4RAPCA7oEkdrzC850gumbSLwByCoMQ JOjk94iRcidxl4CACpNadCjOMP7j3NMl6jqF/OE6IWYGiEeaY8vyIC9ANTQkAXCkUwfGEsCPgIla ep82QHEL/65ekkFaEiSB+dC9QXc88BpAk8AUAWRnLgKAe4bQvR8EEn1OTINJUmI2iaLsqMBVbvJV bzoCf+BCnzCeQJitswxkIM8ggxtk1pQtkmhFcOi2qFhfujJj4G9MZlLgBuYh78SIBPnBPRqsFQQQ p8JDMHpTwkmBz5IuWADGU4xZC1SOrllNOM9fLHgC0Sn4KvQsqS0diHMOkqUxd31QLmpPSxUgn5tw JxPuVKDT5HqJmUasG4ksT85I3ACpJQ9iqSyDbZa+uyTLKBNvhTv8qASXSVdTJNNltA48HAaNgIEc FkdpCjkDsvM9IiiKDpuYre7AJAEU1TkHM0vbqfRRckbMiVHIlUFRYzJ+pA3rihFIB+EN8rzOIOKV n+R8rnAeyAMrIJFKsA3mEqTlRh6npFJ7U9TPLZpgTI0sk5AIxW+j4JaLfOSHlFQWa9DlHMpj7gGE 8kYgkYG+90M3WMO8f9uINqCx/FUfRV7dLAm2htNlEM3/UR6sgmaideJCqqyWSaeZ50fbFDIPqgUN 6jSkPiWJ4+es7SxP2DXM5gTs1kl8Z45xhMxfXA27bLkJvQFk/VP13KWEdorY7tJJ2HOoCDM09mml UgF6PdRJ7Ij6hymMegv0ZqSJABgKpUGigxn046vmLz99PiU6svgyUXhzMKqWH39ufpbTKTBZRXM4 WYAlpAaYV+aCZKmqfnyBGDrl0uszaVfCpDqaT1OoBJRM5VXyuOIrzAYrbMc85dFEp3s1mnRxZJb6 X5QGw/VqDn4EqpvfZzylnKPhCPEoD3wctN7Pxq3pBU4utUhuOIMcVHr59El7NOqzdO26kC/lRJYe gvIVuvQb5bseTAJReTWYDS8HPatv2vj90jYnhy+ePkESm7EDdfmENQ0WyK9ZBEQ1IURiRoo6PfP9 FAnm9F6W6RXoFG+5qyCMmiiOfAxyiMTc3QTfHLDZv9jl0B6bHatnmV2Dtey38Kt/1fpgG2xovjMn 7IE52NrOIP0l2CtwaKg0HNIaKCjzXXYb+R7kBeiTnBg6OGFlqOAQ5/+CUIcfMeSlGRCBF6f6aJq4 e0Z5FOrP7pImxGdI1NgnItrBAaHXGUxTgSRZE8TO2LNPn56JUcRIoWWB3F57fniYQxNlJ+XsWfgM SkOlgtwdHjLEDZ+dbo0kYmQO5ebmtISd7GA/Dtt8diK/vci/vcy//SgoAaNnQod10EkWBSSqwQ44 Vqmf60QcZUVAwW0dh3CaXS7yEVJgpSKULZRLKA/w+cB4kHI5kGOgLg8PpREexIc04bNPTST/oPkA BZBNrYKZJNC21MD9GMevhjTpKr3e8oj2GjsAyCkvX32WEyFWmNsa5SQaZDQmf/rjdyOry4J4kF4D CRSlR330AELUueY1JmXpjSaD1nQ2MG27dW7OWv3+qNOamrP2Za8HLv7HI3C9yWgwsz/YU3NgSIjh Zb+vvguh5MOg9dbst4bnVreGHxC6l9NJq28w+7JNA12z17rsT+sKodYf29NJ/UBxr8ab+lSKsfpp ITV4Q+hC/1UTWjNy+Q2G6RGSgXxTJx/pR9CO9xJYWNQUoKKW21vqv/m5sCm+x7VTANNBn5fTlK9m aRgnYKN8ssNwZ/ojGEJbSxRplHZ0x2qqXhpMCVGdiOU5I6+pGmzQno3egmng0+qMhvZ0NFaUEig5 Sch6rb5t7nO/VnozyrOVTEOqWy08Dz0MeoV1kBFZ5xr4OSncbSfrncnEiFEmOZhOLs3Tr6JQDtUw FM9fm8V+Wy+sLfFqVvcD1BV4vVeNGNLkKErMYqRaqILfQUuOnSVCvakWMKBjoD4cFer+7dK0p9Zo SD6ktI66Yo9y8NhE6ZtPIbRRVfF7jCsRhrJARRIKZdEjiIZAocULA+4AQ9SkP4XQaQ07Zp+msd+C tT3/1vfWoPD7hhBdqVhXUUSbLKnSjVKMpLWrHs2USj9njGyFRt+tnEJiiYXRt4M6HO3HJMk1xP3k 7bcS5DrC3vta9KQ7ERJGmb+4F7kZ+32VmherzGCwhP92fr51ZrjAg3YtueGqZBPt3E/06IB5HIPN c2cCdFrnsJogACvTVZYnl9vt7LKTWwjekLMXPqoqPMpEpQIaod/WPBU7Bdj3kExYZ8GksxGo9Gpi Tc0TilDJdzl9FHkvL+VE1grFng12haRO3xUPpVm61mTWgbXe1OyeaMPY1D06rriamsOT7VlFTZUR uCXR732rPTMnk9EE0fQoPedZL3LXaa2uJdxHEu1VazK0hudbAueTiHJYTFMq9TBP30kzeirmeowU dMszapeRjgOKB6eAVUThEuABAvcr72wOCUiICtlILLsMvRc3sOum6jxuTVoDVoNHp/4NXNl3g8ca WKgRsa456EPuxEBB8aRelmpUXmD0EBSxNnBiU2avHnWyYlh16QYTy57nMbp+EZAXrWEXVgTLHu02 0gdQioGKnF+ghTZg9aONIb5d+NfLUy2in9PCS5mDqICSO7SNIrjJ+QBFnZtDc2J1ZrhpYQgntS9a E1MOUFPERmNzODPfW5AYh+eIRXCt6XRitS+h2Rpic9UX0HrelJND7hu+a/Wt7kxIOIOHS1MrnYgn 0ZRwwDK6NuDjgCQFLXIusppHV1NJTjUmUWE2IcwY+z+UbjTsfyAXapY57wRRyi+c0AvUvEUWyqXK Z/xvhBO/abcVaq0Tv/P5ZrQQRtGp5ioetMbSEILNZsHJLpcSWYkhvAsmUio9Lbmv9JJd5zXFFqEV +rrvIrjy27LXQuoCnXviCEAc2rg8BBqBtkMKn1Hi5UlNbsND2p+5AAS8IqO1neH6Ac77kQQ5koWC yjd1N9vw9c8lPVNlwp0FqkZnrERlFxlexfzo17CNew6dLkx/BFPhULSg58IJgDCMAcmC/A7d0hFD YTalrfy12DnfUkwJGbSz8jT1bL2UOgKGlPgSboGv8VcpO9BKExd5pdF8D0sbxBOD3W0UUgCIiYrJ nGv23Rlr3jV/ar5+NX/dFAvvUuEAr63SRlJ+huGHt07gg6Mk4IQryNBelXL2brw8lCZcedqML17+ +Or1T3/9hf3xB9nib+x/NjlS1Xull69/QlVUNul2J1OFoDmiqCFf81P2gwd9q8GId3E+QxtdNOVo ncXrrMvn62s7SyhVlVdiOQdiSV+ToVgHauStW0RV4pWmBIwVtpEuqykL1k/R/2gDfM5lIsAt9zRi XoStDlvgatLPcn9ExX+nKO5PagQCuXoK7jKGygJ+KiNBOhB0C+obEAB7KWjU1BB3rRQkaPDf3rpK qS6fdI9Zt5uRaoc251EAcVywddr1FRPjh/iNkdLQ1An6e0TDYodk5cSzkG+Ermui45upDTbFvaqg Bws6aBTNuV4ivwNi+/W64ivaCwAAg1HU7vMihLwMV3otQYyt9bQW3nrCp1298XoV511nDYeK3D6w z3GdL4nJbbkx5zd5b3UAr5WQokaNB1CyBtDp1ks7OtPECdMAbFNCVXziT9dPoTNxl3sBHiTn/Ylp X/an0OP3++1W5+3TJ+J2wThBR8937A12aQ2njJi7Et2h2Fk1mGwWxSaq1nx1O2zpuXK6i94I0Je9 KFR5EpO+6rPGLSBuwyKoM2VxKgfVAgWZVoJTMwxdJyFgLwwzgOu0+bUfjh0kWRPcHsQp+ehS9D3C 2wcc0oILRrEHs84HG1zMHNbZMXvRJFBkruh4IiKWNwoG+2sTfuFCrdgMaBp7/lWnPp70TaKVE4pA UZRtOmEdzf+B56w1YN0QGpEddta+GeCBkngznbSGNqjWHE7p/ZTfZZDh5NsXr8V/OqUwmNp5okfV sWeI0okCjHBCmpy3We3la0BTv+r7SDfF/8dJd0GOjCs5HpWKYM3Q22sYGUjNcuaQo12+0L1QYJLv KaeT3rYVf+Suwn5tx725TqI1LjpEmhcC5P4JoJ1+y7bZJvdR5ezymdDmokaJc6R8P91tpNm9WAfY s3cTsztpXcG6EB4uxMNpDhjEi/AKlICSnLFCrALCncN76hIBoKmPd4J0z/iSjllClwvfHtBBt+pc 9cabYF2616HlQRztrJMU3OKM9SPHkw81kXSsbmfWgiXrlU5lnmj6VCFiR1D428k6hSAl1xL+/+Ll z/W6Ln/6ZcDDNRWmbUbwZSdw0lS+Fc2FUBKNV0/1luW7Cd1z4Am9g4S2ceuY7B/d6ENErZglEp2J o1Pm0hQFJM3e4HdcrfWLPrNoTuaqORGN0A9AQMRKvoLaaEoSsrDarmQyjUhy4qGZf+Zf92ev9z3Q o8xgXwX8sAuoNubLX/d7kganxLOX0UZJJSLTvoI17ugKuiJrYP1udvM6GnuaBhB2q4zKYHsQOzZP 8Vy8A0sdMJCjTBTJWxrQh3C6tnJcrrYCXs2Rh7CI88rEhIqSYKxVMAfBEl8cilVAWoEzEVlL5KbE pdy0ebRovJeaPP1TpQWhBtEtL2urtoFes5a4jQRW3dkRfAn4ArLl8Ut4t5Tv5lGWRSt8mUUxvUND bCMZbBvUENvmeWIsju/jJF1m8vSeNh+Lim/B6jLqBtf/55rfHw8HF90JC+JwpSfRdjmJ4vjXqrs1 tKZdq9UfnWOJL1sYb1E5dANGOJQw2PbKQUR0la4VXflfnERcIMovsvyQomPdR+uErjCuYYIGq0qs TuC7N2woL67gJTU/XHNc4XQw6wY4yu98cQVEJAExR75Znh/jq0oMyrXAS7DQKjfAPDu1prhzpu39 PQ4LppiMZlPz/dSgJa5eRdVRSVmNw9HU6n2Qe6b4g2bBdY80U13aL0fU7YKwR7/mm8MVIjq2hzPb nLY6U+sdbQQjBnhNbC85z2Y2BtWXNt0OSgtLCUNBI2tfWb+3aceQmEfkYq+zmAGgEObkKyDQtJo7 AJUK/Pf4wlkH2c67h319RulYTCagHvoJWhb37OdQUfKrVHiDknI7XedDNyrfk0vZAusjUZGXjdS9 vIaCMbCOYSmiI0twKVhXZfcGLm0RXkIRCXXfUt3N0g8lULc09zs1tR62dFyqaBXRKTabII74ndZQ iLsCUcLz+yri6gm+u3hrfmDLt/xePj96aCFIQymTq7qiZNPu98y+7HRM6LW+O2NQwkcxD4GoCdUa Z5jhEXN/Nmh1Lqyh7K7FiVPVjhYZ3uv89EmIqz47wG9Vh2waFaQk9vYOkOX6I0eJkkm5f4XLal34 vHERS7My92fEvRmuV5J7nMcQGpXMADc6OeBFzmdotRahRLNV/JbLcrJGup7f8Pv8HpBBptQe993J OXzxWVU5H7IH8aQGbp1gzdWCuyKMKiNqz55JtTe6BFd6Z05sazRkYgmzB25bbXtpfZJLIHQFdZ0U r6AovPxiyT7koWl27S1GHoHV+XiMnOIF72982wsqh4eFEvdzj98hut1VnL82SuYnH6yoCiI0XtSq 3KrQS8qr6jKcsT7VKJlgIlFJpF7dok6sKWPT+lI/pBGpoD1rdbuQDvCgQfWUlfygRt6syDnZqqaa IxpfD8ZPn35IP32S979w10qVwh2GC2fUlK9NREDfTBKsxBq0y3r03ygav615cv8OJ6RovTF2wq4U TLLZPShYVITocAC4QSKyTu9TNRQla2oOuq1pyyjCsDhB31I7GNWD5qGmsbDvtE2j3rmc2GZfpy2O MJC4LG1lbjERnpZqXvmY7Xtw7WZe+9pJtEnphr0qbeX747Kq0Q6duOO8pzYJIr0okT693ZTDvN+D fP5iTycq9hIE4v+gIZXS4ps2rHBt0xr2Rmzun2qlUN47xgVpaadekEPzWt2+ZU9Z7HvBqS4LQvz5 tnZPCT/Pmz+98ZP5z57hrGpBxrZukZLb0EUGseiSkShOWfadKAM/ndFg0BrioXpFsd0fUSGvCbXW tdZvhxPVYSnUC2sPqqhHuMariNL23I1Viiay/TZ2lP3ORWt4nneUbEcIuub3ZxtNkeMqst1Ex2J/ 7DSfFd+TGVOqfCveduTNSzdE4nkRieoQUVwwRKJnCAGNg9QAivNfck4oBfeCPA4+vjpAL4UUXS1g sTDF96XkUgCI62z/XwzuUy9ZOBarDcx1j2pakiSER5VOb4Xi8wSrv/LLdJp/XmVu/A2VKYCHp8Xt T/zcXpYgSZFUTkSieSEBtzenwApDWADcc4iMVRxw/MsC7lXROEIIecuksnvLBLNNce107jeQ3mgT ctzKk5sp6hWmp0kUZcWeW/4m/dItkhy811KeBoZ7c1Pc1xL7cvTHQaUL3l11Gl3VsNZBL3Cu8Sy3 bfWgIk8vJ0O8GNCzu9bEBk9p3r1qlmZZhLssijwuVylq0LfwfFEflB+dyAr9zHcCqNj5Bii9QSVg mF/kRakXBR5Pagdzv75Fhc5EER66OvuCPD9b4t8WQL7H61v00tCVpZJcfzyge7IsTpcDOiIkj/mW 6+mU8gxCaw2za0ImJSYG8sjxIKddr2uZJR89+jWI32Xz4D/VHGtP2lD0F/AfGpMtQnDoZrIsJksY VCEb0rQas8zF1FkHmXaEwphO//vO475biiCa7X5R2nNfp+ee97lb7zmBVb2oExI0kRf0COHjIgnr TsUk3/p5nA4Vpr1NhJLij4ANp74lbJ0DcrYPRlXw+ajTp6ytnMLwEDlIK5Rn0JbBT+L/IApRwmy+ N2RFsUJzz5EsNKwrXCqPEohqXMFO1itbceAVHTsAsg96UtR5Bu8Pkul9oTuUmByGfrNn9Iouq0DO c3ra7stzDI3m6+PA6HqRaZdn9xKdod4sTqnTOPk1TGbonoKFpkC9cXqDXchhKvvYA2bJBNPzMhCY ND/Gi1yXaoH7dLYux2mxiiszGyn9svRQBmH/AOgqqnvBhx4e6xA10rquQ6JZ7Ng+PbLz253pRXLk CtMH/UhFO+nQ4bjbC9CC5kxdalyPWPa/5TiuKA5ZynYey1Uc7tSoeSISFvNhEiXCTN5Utkr1Ywgr EmK1EqbH6MU/wFaejpP8GdTZfFRqBvTBpXl6XOh/Ducou4qzgX5KssBwAXKE3vIifEVPK1V0IfJQ r40nrilweqo9akPOsyNPlgUlqrhpmCTFfZwZdd4WqPVDJ+bIjaAbbkRImIzj4RW65PTeKPve2GH5 7rZ2jOob6qCnEdmW5J6nQgddwW3WPBK4qFCEsabp7XB0JgHsfcnaS4MOZX1lbp/PIa1y8mofdLJs kFw8gaxaViZRkF6gtSq2tYhdbVhGxSXQRgICoYypPzF7IjJKsWyZyIbRK4+/Ip5lw17MgP5L/YgC 7eE0FZFU16FH2Aj7QdTxQW41D3wPrQy0/bn92b7fY6iOAxYPAO7LLp5mA0oBdfxm2w/RYnHGYjj4 TMKOFZc9UFxUFprIjEuY4dXFLGJ/s2jsdgZzh2x7DSVNV25BFMhSxDv8v9Nt+7wko5OZjIOtNCEH OyjTVrRt4x3YwvIQ03szMG+CgWGeXI8w+Y/gsGQDw8N+1D8OW/5mt93mcHFV4YoxTVWLqnGCCtJx Mp7cEC0HoCGgqTmqmlgWxn/hrSAOnlfAoLsbb86OwCjyW0dsNlZLkIatwI/soGLHQgW2B6ND8Cvl Cs+KcSA0ljVioHsYHQHXJ412EQYKjBgHA69XxwCmACnpCVYCMu3puJwWsK0VG8wHdbbRPEw44tHB wpvVscCAfGGOgPYyBDfwMMjxHmyK/wz04gc5VoJtATsZkAdQJMSoXkIJlSCjwYj9Zkajze+Zqyz6 Wh2UN82w3ai9e1trNGp39Kh55Ie9ZviRfvHnqzXM+bLb8+sTQM0Yq714SCPtT4F0kviCPJfcHJA0 wjqQwFr5tvk+IGvG2tWu+jzW5yPnGSKNpBl6cU66h82gi9mYmCqIwQs8Woct36OPUPeMBwFYw/Sw IjxonF5BqYvXF5+GKaiBqGWl8AsPhlMQyqIpdcNJDKE+r07d56ik7qXrOfWzqkWHvZj16uR38m06 Ib2FInTAoMVFIZIepSrrUbWUXVJnzvhSKriS0kivk72XKyCA76CuG7HqBnbE2PfGVqT2zpfrpJfD 79OxMJa4tKfg6i1dW6ELNdyaK6XDe4U7U7URtLP8+vBPUUYBcKAtunRkQw5XAKUGnw8iUxMUHkIs abKMxSLV5sC9UUyNR1lpGFKgxFSOLYiE7op0Jii64uRVo0JELFRfT2Kltz5gVnEljph3pKsjnZnF m7XOjYgSE+O/BbNS9lzZlDK97qE4tiKxRiCHZrXf6tPsxG+NHubCFi1CXhmHs2qU67GUQ81gI8rH VjonChFijjKT2cyoVx+FYQ3bQHazJeVVgtdgjRTlOhU2+oCax9Isk+KSA4bNr9U2WP4CUEsDBBQA AAAIADOJGSldLdc0VAUAANgXAAAPAAAAbWlzYy9pbnN0YWxsLnJj5Vhbj6JIFH438T/UstmkJyEq rTO6+8alxMoiGKroy2YSwmBpk1EwgNPdm/7xewrw2jqOmXHSm6l0WjhV59S5fHx1oNkcRmGaZMkk Rwb/wmfJgqeI5stxlKApj3ka5HyMUp4lyzTkKAvTaJE36rVms177PYrD2XLMkbSabzxI9RpMjPkk ijlSR5R5BnF8F6uGY1v3Pr0fao5Fhf4PHKU7zSYy1x5P0mSO8geOGL5jxNYtz8Doeh3IqwiCyRPM Vf6f3vGMAbssY0jI17JxgXwgmy/zNJitQ86KykQT9FtZnfGV2r8DX6jjuTr2Dct6h15e0PYkU13T t7H3rlAUMfi3xG5f12uWapueamIkLsQS5qqWjKinbQtAbZEG03mAwmTM/UUw5VfK9ftrYY/HY/Cl 2VxZvBQktCifB4vytl4jhuZrhA3VEdoZK5lBqK66hqpZuJBLo+f8IYlHySNP+bjxab6Q1r7DOJzm 096dMYTXl4CHydN5EKOr8vf53XfjxDiNExO7Q9XewKS8Pw8l1Qbrh4nYN87f2LgUfLboY4UhZYdT thFTr2nYJBBQAZ0NKX5sAWqwbQjt62/U3lDThpukj+nHWKoWbBttf6PRY/o7iH6d2r0FX4PO6dSe MS6FfRxPZ1H2gK68Bm18P/KxfRL52DYtQgcb6FcC36NvgSSNKJgl0w1JGlB75jqAJNVyTHyHWrL4 aytdGSndXr1G2T2A65b6+oBYBnoRlwA7AbnqTldHjDgAvOoCSZTnS0GffcdmqCcjaUgRDeIMUZ5G E2kHqZbA8xY/S+whytBt9G+QjtFjNJuhKM7yAH7/yFASo2coIORvvljmPG0gfRaFn4Gan3KUJyCP 8yhecpSkSA/ikM+ElD9FedEhFH5VthuSXDqwP4ih+4wwC8tQG1lpyUr3T7mtyLbDRLSm63ijUhMb hG17LzSLbPpCWqh3lEJdabdkTP2hZzFiERtD4uB21R3A3WFXYLsbqruOZZWZHpQ35WLdEVtZ68UK uCo8oExlRJclmgd5FEoypatz8AXBtY5thl0yBMDKH+TekSQorY6sfGjLsCm+83WLCC3DxGseEcih 2MI6G92zART97QCI8hkPc7QozvMVeiAXcANgWGb8L0l+VeQjaTin9COVDSBpUPH3XTALwOmIoqse cwbrKm6VvbQ08uhA8xiDsEv3G41G6Z/mOrcUy9e9TmGxNFi5ckMogQQeyYARpZCBJH2uIq0gUYT6 vici6lWahDLNuVtrisU32KVQBOqLyR0Qt1qypVGfOi47ClmxwHbgKcAmtIUDTMwBK6u8g2SmapQ5 o7eCZGLDXpbVJxambwjJu+T2iU+juOCxbUw3EJkIUkSPQVwsS/mXiD8KBgwfgnjKERzcKJmUxLnz NGQ8B7acZjIKi420IPy8YtQD7PnDeHO/3tIoTaZwNGdKCdeR65hwFlNZmmdhPsv8RTXfvpZEHTXH NbB7rN4FyLslYjvVhvuJJdtpWFmvHhZi950yhHZppfdWUNonNjQSgLW3hlCBjn4Ui0br0zLPS6Ld O3UfL4Wen1QHMfsq/B0ciaZkxsUniWwZQo+ZTZaz2XNjD1VApsfPGugT1hW/WAeIKTFt4c+qCzz6 omV6xMCiX6FbWsdfOtbdpFwhtBRvrRDDwn2oigsyGXU3YlecFCt5W2ltZuBAYoUnsni4D8rbrc5G DufKAfuaA2fscDWhdJXN1MBx/6kM9Q5KO9XiqjLicr//+UVC3j4of5GQV6z7zeF++B+GW/w779vA 8Vfr02R0xiipsCCp+Gd+Djrxgbm9/4H5AoS9k+44yQ/W5D9QSwMECgAAAAAA/bgQKQAAAAAAAAAA AAAAAA0AAABtaXNjL3BhY2thZ2UvUEsDBBQAAAAIAHi/GCn9gv/6tgIAABYKAAAWAAAAbWlzYy9Q eXRob25Qb3dlcmVkLmJtcOVVPY/aQBCdSClIqkXCFiXNWUFK45IOuwgXpBTQHJgyd2265Beg/IP0 aez2OjpEl59ASUsHnaUzJ29mdnbt9QcnJV0Uo515MzB+nt03JvzkvgV1fcP1DtcXXO9xvYLXKv/z DTQuKSUcj0c4HA6w3+9hu93Cer2GMAxhNBqB7/swHA6h3++DEAI6nQ7AQUL8metPf3f9L3VnKbVD YFnZyMtKHcY5OwSWbeZVbOrOHBuKylXP23Vys6NYbpJkJzHYkCVczSfk7LrLfEW3yuZBGKFdziOF V5TPT2eFKUPOrksHHtXFAsB5jEVPkAXwfmE+P6m8pyx4lbpsPMWyy8wPAj+aoTbJBkFk5SNlxbTK Jxx89HTgJLFwkK5H9uHr90S4WJcOFFbfujW+LnZGd8/Gk/EH/EwwE4QLxZcV+Glc58NHd+juyKw/ NC3oH3EbNXZlG1/gLzTf7XzBfAJtlGHEeJrNGv31Hu7FjeD+3CRR/d0Tq/MD84wRQhuf2kPNeqtx 1zd5sn6dbwB8ctQlnhmep8Y9YfJke7X+LiQF1khEGsGl8XJu8mjDu9p+svRyo8mcdKnxJjFaJVvj Q8E/o9KLkaPILHJs6CSrfMVEaC/VQPAyc0ErHXi1Ola+8bpHq88irs77ydyJfcp7au0rx9R7tY6V L9mfWKn2OXIs9evF4lPKl7nyyqZGrayhUpttfPquJd/E2FKbNT5HnVFME2C4NBOxunGhzRpfV2kC hz0yfHoKFN9k5l/hg/LdovnM1KX6HXCNT2l+OfNXLXxdv9BmjY+7IUqvpT9+G7TxfXx+0rtnr4Iv yl7kU+dGKCneNvo50hf607M+D0Q3rM79VF7hUxPPOnQIw41o6rNZxxPPmo8QY9AyD+bX9vwl5awT TnbVuc+LWajUFX9x9p9dHRdlZd0fXv9M3W9QSwMEFAAAAAgAM4kZKWKe3Pv/AQAAkgMAAA8AAABt aXNjL1JFQURNRS50eHRtUz2P2zAM3QPkP3BrAjROCxQdMt6WLpfhCnQraIu2hciSSknnJL++pBJf 74ACBizI5OP7oF9Gm0AeBE8zMDnCRBB6yCOBsSmXbF2C2XoTZqn0KaNzxM169SIVZx9mD20ZYNOG oSQg5sAwUUo4EMwjeUAPNMV8hd46klnrFV0yY5fJbHV0by9kBG+9epahDN2IfqB00Jsd6JSMPFDe dWGKCoHeLFchZjvZG0HvcEjKu1XSv4WvUl2vAJAJhuCpgWPWcT6ACzKAIYaUbCuAOcCCrbLjNY/B a68yTmAKWz8s2jHb4BtYuN2cbWEKplRt79CZ/hTLZED8KEne7fUjueYu8Cjdr/K5Gk7Kg8U9mbF/ 2CRHoWcE3gtRhEQRGTMtBGHzKGy6bfPPtLeoQEJs79xmWPDvfH6efsEmUYUac46H/b7ES5PTpQk8 7LeNIEmjqCidGKEUk7r92A+61M5NDWQs9wIRwyOhWYp669G9YxM5DIzTttLnMMG3L3B+0gy+fpfD fxWIbdHhVdd0CpJniTkYsUCNZVnOG7LZOXuudOqdeEXcY0efAV3SfH1G9X0QDJkfR9sd4EdJ+VOC Uw0cTmEmDcyFITRV2FH6ijPiXFaEV+s7gumayPVKuOiv4t/seKLnKPuu7UmT+KCirs1dvNgPLXLN Q7NPgs1MXXZX6foLUEsDBBQAAAAIADOJGSm2jsJIswEAAP4EAAAPAAAAbWlzYy9yZXNvdXJjZS5o jdTvb6MgGAfw9036P5Ds/Spd96MvrdCVHIIR2q2vSFfx4sXoonZ3l2X/+9DsboNiMt+YwIcnD1/Q 2ez1lXGFcIIZwiwiWLy9TSezGYiLY1O3dd4BpF90WT/rBojulBU1+Kkr3Rw6nYGiOpanTIO8KPXl sGzbmuGnv2am7Q5ledkc++Hp5CLTeVFpQBBSiISU30Pge2AAv+KVWhEZh8kYvrIrEyZT7qU9vrWx wBRHMtnLDWfn+M6tLGRI6ZpQLM7x0sZrwojYYOTCAcPAt0EfPcORwohIfxZ9G4GjJZEUf1ubDaZy XENbJym/T7E4C+NDX9masPXYufR64dQezgRej+gbR4dy45Mf+tZb+2ZE3/n0PBjRS1uvUv4gRgI3 FztwMzGXVUn86AkdBnMn7x1OBeFMKEqEu8Do+XQyfH9M/+mAWXY4lR14OZQn3YK8bkClf4P66Zc+ du3gTPEiNw6EiZBbRLhpZ8d/YDRMVNZMikPEGd0rsY9XnIrPxpQxipkdGCP4No2w2oV0+z8CCOc+ HPE4DhmyLVgE1iX7yvukqMPNphc+bZrEbul//xVdZUX++X4HUEsDBBQAAAAIADOJGSka2lvYHQUA AK8RAAAQAAAAbWlzYy93aW5pbnN0LmRzcO1X227iSBB9Xyn/UOvZh2Q0AUJGmRFeVgIMLJpwETA7 O6NIqN1uoCdtt9VuB7Jfv9W+gEnCZS4P+7BSCH2pOnWqunzavII+p0pGcq7BYQ9MyJApmOjY4xJG Sn5lVEOHCwaXMCA+q1srHvAg0hYujAi9JwsGw1XAVP33t3+cnf3y6hBgl6Eh0cyDZsyFlwC/gY5U PtHwF1MRlwHclCqVBOj1a3CGMBhOoe30pjjF1WRj2hh3p59HbbA+8eC6Cufr9zcX0AhDwSnRiGFB ZV25qlylDq1Ot56xRtKpi8PceIF7v/bbk0mj24bpkkeAf4HUQOCBCO6BT+7ZHCmWYCrBTRhrYxZm dYkjHixg0G98aL8pYsURQ0MG7XUolYZ+BgNU+j4JPDAfFQdFl+I4AYTyHPJal5CIVdpn/lnGQEkA Ucgonz8ieyqDOV/EKqkFrJYsMOGCDdmit/sIHrJLNg1nn+DpAZYM0NUs5KQFD7AQeFbA1sQPBat9 G3+Dueme3XOw9iGNZBRx11RuKTllEcwx/G52RO0n8izamAlGImbBuYtfnklxbwtdHERKeX8zTt7B TbbgQf58JSuj8XAEDSHkasRUK0nRYSELPBZQjplXtlYTSmfG1TyPYFm7G7eSEjEiepnutEajOhUl tmY46U9v6z738ul40qormk0My14HwPrtHA/qwoJ6fX/98jSSqM3GpA0fIzbrd1pFmpv1pFazW+4q op6kktgMYx3GeuZwBVYhQtGkF2imfOZxFI+DhlOiFizDKuy9QO8IsyKpUgHpORPN/PBSPaPTWwRS sVmqASZGEf05zYbjpBngiUE5kEIuJJQ/XUO5+zeUh1UoO9hjvcF11UqGA6fd/NhNxzNcd4afJtms 32yZ4Wf06zhQphv8Hei+k8IPr6DcA+sfwV3rZwRJksBO20YqAvn3+hGfDbdawdAr01Qbx+/xSYJh H0NZoOS/rbyDsrfx3FgdMGhOWtfVuhtRo/XZo1CATrZzVtutJ6u3vcEHREGFvH8OkW7CPVMBE9fV EiZiLgiVDRcez0aYWRRKKZIJqq4nFtkO8R5ImJtFSyZyHCnYdkRincPH3EtXPZfmBjikYTbZlDmK 3egxwg6uYXRPriKsNqFLlPpa7/r9zSaTLIltPNMukSY6J0t1zul4onvTOZWWMcRLi8RCo1vNuu01 W9gnOA5R+GpJL98ZdhyzT9sgFdyJuSKJyN4+plhs3JwMP45b7ToKXy/AR95o54VxwstHJ4azlu9F dVq7izUXd3G4NocMl5cuQ2nMr7j83Nt4Vb4Yxghs+3bSPiqymyvxByT26oDEbvAPC+yLZj8mrwVW 3yiv3hMyP1Vcv/RQBb2n2jc7Wfu6X46K7Jd3aYh9Qns8WGd8stjOvkNsT/F5WWxnx8R29r/Y7lW1 pK+filvouXgGrBaxUP+HFBhp1QIZsD2sX5RkGeuaVSpnEjfzzIkdVOpEJQcOiuTZzqty+kzna+mb 74G3030mBVFLcbtKxiFYExkrypLfo9Gu9DppUjPcQmUCi4ahTW26XtuK2pixrWzpCRvfqu1l+NV2 id65cLa4KWp22ZTu2ForQnUpfZaTW2PH9jiCSYwI8RMQ1H4Is5bU6HnN/mTEw4qcULMllia0l1iz pW/zQJxWIaKwvR5Yafk95MYsOvlIOZU2jZXt+qGNOoAHW8WPtl0e2GoR2Qs+t7+GC/yw5N9p9EeP eimDkVwxxbwSYp+Yhpltuj2dbn8n/gtQSwMEFAAAAAgAM4kZKagJj7rVAAAANgIAABAAAABtaXNj L3dpbmluc3QuZHN3vY5BS8NAFITvQv/DWK8aClYPoSkUs6nBmg1JaC5e1vQpa2Ne2F3tIeS/25Ke RJCCOIfHY4ZvmEddGbb84hDSJ9XckkHuPjaaUbLZ2lZVhEjXdImIzbtyWJOxmhvcepPJaHR2gXKR JXGy9BFKJLKACOMCMkMoVqIQKO7jHKXMHvJ0cScQxStxvucO6N9qKE0Nv1HlfIx3utGNdePAezq+ 3sa2uEKqqq16JchdQyaYTedHcrCD2c3B6Lpuf/u+/xZOfwh/33aShtJlzc+q9k/Zdv1f274AUEsD BAoAAAAAAMiADikAAAAAAAAAAAAAAAAKAAAAbWlzYy96bGliL1BLAwQKAAAAAADIgA4pAAAAAAAA AAAAAAAADgAAAG1pc2MvemxpYi9DVlMvUEsDBAoAAAAAAMiADikAAAAAAAAAAAAAAAATAAAAbWlz Yy96bGliL3N0YXRpYzMyL1BLAwQKAAAAAADIgA4pAAAAAAAAAAAAAAAAFwAAAG1pc2MvemxpYi9z dGF0aWMzMi9DVlMvUEsDBAoAAAAAAK9b2igAAAAAAAAAAAAAAAAFAAAAdGVzdC9QSwMECgAAAAAA r1vaKAAAAAAAAAAAAAAAAAkAAAB0ZXN0L0NWUy9QSwMECgAAAAAAc0y/KAAAAAAAAAAAAAAAAAcA AAB0ZXN0ZXIvUEsDBAoAAAAAAHNMvygAAAAAAAAAAAAAAAAMAAAAdGVzdGVyL3dvcmsvUEsDBAoA AAAAAHNMvygAAAAAAAAAAAAAAAASAAAAdGVzdGVyL3dvcmsvb3Jpb24vUEsDBAoAAAAAAHNMvygA AAAAAAAAAAAAAAAWAAAAdGVzdGVyL3dvcmsvb3Jpb24vc3JjL1BLAwQKAAAAAABzTL8oAAAAAAAA AAAAAAAAHQAAAHRlc3Rlci93b3JrL29yaW9uL3NyYy9GcGFuZWwvUEsDBAoAAAAAAHNMvygAAAAA AAAAAAAAAAAkAAAAdGVzdGVyL3dvcmsvb3Jpb24vc3JjL0ZwYW5lbC9QeXRob24vUEsDBAoAAAAA AHlMvygAAAAAAAAAAAAAAAAuAAAAdGVzdGVyL3dvcmsvb3Jpb24vc3JjL0ZwYW5lbC9QeXRob24v ZGlzdHV0aWxzL1BLAwQKAAAAAAB5TL8oAAAAAAAAAAAAAAAANgAAAHRlc3Rlci93b3JrL29yaW9u L3NyYy9GcGFuZWwvUHl0aG9uL2Rpc3R1dGlscy9jb21tYW5kL1BLAwQKAAAAAABpkbYoAAAAAAAA AAAAAAAABQAAAHRleHQvUEsDBAoAAAAAADWTuCgAAAAAAAAAAAAAAAAJAAAAdGV4dC9DVlMvUEsD BBQAAAAIACmHGSklj/6ScjYAAAA+AAALAAAAd2luaW5zdC5leGXte2dUU1vX7k4PJCGhBAKhBCmi CUjvJVRBWmihSwsQICSYQhEVMKCEgAd779jOEUVFqiBFBY+iIEoRFCxHQaoNUEpu8D3vV97vfvf+ uvfPvXOMtZ455/PMmbX22Bl7Z4ws34hyAAIAAFQ6JBIAqAP+YVTgf2+j0iGn1SAHVMt0adeBfLq0 g5kpPFIGl5PMjUsnJcSx2Rw+KT6RxBWwSSlskpt/ECmdw0g0wmBkdf/u8enZwdJrtxZH/jleXJ8f uS5Fw+vfR65KMWC/5Bc+vjo2cvGX5ufI3N/a87/4z78w5fbyr7rAlATmKvfPNdLcAcAHBAF8RRdt /n3dWBAKBP/HJnHSkS9126VYLh3dqwrqP/Lgf1yXVfsn/tr03wH414z7h/bf8N/glxn3AEAGCPjV 1xgE/F+zEFqY8S8nH/j3Bf3bJoB/UqNSncmvgAr8Y/+W/1UnpUaNuDxuwmqw2qv7b43tf9G1AP/P mSyg68VO4tiSft38SSmsRNLqlyAuIS2RQcpK4TNJfGYiSXqdSYnZiQkCfly8VPGL5pKYfH6G7YYN goxsIz4v24jDTSbprvZj2P4qMDEyNiG5cjJyuCnJTD7JwHUdycTGxtLQ1NjY+N+6BifGpRuRnFks UuCqikcKTOQlcjMTGUarvaQKbbQMWHb9oVyjBvMnivsuAoCpmXTZZwBAHwT0Se4uS4JC6GK+rlLR XCg/U7wN2YSLpQL5jgCfmRpFZ0nm5iT4WRpGPBuuGc4PzdcHQuVZEqsRyYBwUSLQTMVmFLUI5G3c dNX5qNDBlxJJSCpMEqxrILyHnmvHCTSYtQCgy5f4D1QKo9UB7QfwKA/B/lRQWMzmu4sSSXRke4h4 UjiJE7srBdFDxVRlsUO2uch9wWyucW56Jcu1xUaAFCA63JEgNJ2ZT5dPGFmZo9ODYGhJv3BBsm4J W1Scvu1lV63TAkRA1CZIBLgxvASYS5//sOUytlDWeeKGFo0vQzu6fCM9d2JDFIHwOQidCpaEEIpu D9783GKUjEvqm2VMCvSM2pjBxuNBtYunZkDf7BDhcku6fFnFqeg3nZAyd+/hJLGnLKT99e5pKjog N3/T9iVVyPVcMwyt0G5BIIMqPnmWP4LeLUdPhdJxjMJmuEqO2KG4fBeWac2qrfkhsp/Qv0oGB61n No+87Au6htTLRNo9EKisxVmaC3MMCg/Km7Wkv1mrsi3yoXWQODpQrD1XNVsbetYDmeSABAJOAdbH eENTbZ2TtLE+excfnGVodE1beucaBWoj8rHy5ld50zXwAT3m5bD1n2mi6OeGCvMq7OrJ1xEt/CwJ 34DGLD/97JXjiKo3VAl9kK+ohsm7xhvZtg/avXdOW0vhRFE35n15C2M4TO21yRzwoCFp+4QkU3k8 qP3V8cWz9jqHN08M9hZMEqYweRuzxL64QTR9G+pnmRvq0z1yjYSz5IkmPxWOJ/VAfhZY07xhcFHI t+lNc+/mZoyEiTggSZgtu7zHjAwRq3bNLUrEPlrry6BaZebykK9GIDBZs2BmgVXriIJArRQ6jPaV KWlhpzm1U3fDNH1n4TQShKoO6YV07Lg9NzRVZo/DeKhD6GqQTkhmsI75jvoSNc3JsqKxlZPRwawf DckoZtU07bEfTuvo6y7lb1FlhTCMCh91fMhHjUbUgwCzmhVD+ScnvaHRoZ4eStt8dszn34F9JEbx jSUCpTBaPfwWeUAb2MVWIsrafW0ET9K3gSGKNsJ7U7Zqh+oIC9TWpWeytLSTQwPWqXBnJW0FiRre +sTwtA289Gnos2MXZmpeR03Mi1WgbvIlyMKHy9vt3knyf2wQQB4AUVTBDI8ahcbyVZ51zRZnnnB+ qB4QuKepxxbmJ4tqCaUp6QZ00TPsv27ZhCaljiQ9ksgeDZ//YfaQWR0bAGgy74CBrn0p2RicMZlC S0pLJZr2q2GU8AY1/MKp5tEcKF01nGaEBa3tf1VG0tAlSHqZ6/oXXxYIEmg6siB87xWz5IZ+VIz1 6VNprMqjhG+f59ocX9ZkjdTUAXDAIeqNHz+2AIbLa7tBTBZsoxtZB7yBzXZAdXmX3rTHltQDsz9a KiYPJ8nNWxjDutSgYxBM43LYN0kfk7qVwFyWe9mUdp4/tTayIBtp3SRQ3cbhRkpSNTOgqYEUDCKp a93JlIjZyMIBknl6kGlf7V+1KAPxQrA4ZEnc+U2e3L1CrC0ivw3ELpB7Ia2BR8ltPQtxfQO2yFn8 wgAGdOYsTtX++2ck9jF4hi4c8wvV+x6bEfGzwNCI7+653mDvhQe7sijY2s6C97Jb+Ltn1Dg1aBVc 6xjOk4NHHEs1ZrH+mmYeyP6LEkelkvBU5WPTM2rMbvHKCt3Tc/PZFmfE+YTJiejKJlhG02KdcFHj sUX1DcpKr5xicYL11FS+jVt3iZJA4evNuYkkI4O7mRO67vIbCic5qfkE5lF7vVDmzL44s2Q5Y3TL g/sZyFeGogn3t6Ry60aHlhWQmSQ0NF8A3TYBZru5LESo36ZfV/+L0Uq4GVkw+GbqgUr1tyCzIZQq gA5i1qkzRBeuMfH5SkslwEv4rkw+wlTfMQj4S0Fj2HAhKPSI1QLNyK3GHy74tha6xR8EupUxfUds QbM1aM3daBlFGwg+QpNRijlTXlHx/VY7X9868GYb3HPNSbzh1fRKyjr8EiUnjGPT72gm8D0S8NtE /dS90pj8q6rJ35MQr5MXWHEL73AXYik91/JA7xoK9Lpuza7zlFCduvQnI+IDZZQVSUnHcWe/4RWs xk52vXg9u0wDXt1G97BuzSORWkT0mfB923a/ejTLPJYZhNmliXylEKC/5FPYCt98dbTqmkIw2JSS pkBHKHzbP5ykuO7od7nNhp/BXS0JvXgHI9ANSF2SzyE12NCE7ofHcY1c5iTO2G/T1XaH+jjHOo1B kIVcmHcFwAx9HmcVGe4VEOK7841ef41HFNLBxO3j1WRxh0MTZB8kUDJwX3siazO9eTGUft44bGyx ohTsmV8nH+WGMTx4yeQxXcVPJ7tGY/oIGny3Rc12Dcral+RSq8D7fjbjeGM9Me3MXUeWBRUOu6yY 3R5rAf6idN66NDXurF3FQwJwOAgbeTjXKCoLR3u5dPsDvqLGNuMi+twVz0iBR9r2CUgw2NZTsDXP cNnqrBjbOooLvULbyBk8S7Z/MO0Wugd3smfQkD/hGkNLpO3qT7WcRgko1wjMAV5bJz/eR5uKNevK ntCukakYELerpY5kHq/roNucapbll/XMOUeuQe5dQ7srT5TLnX1MLXqObJuk7X0lv2a3J20zvLg+ +xnjSNQ+8iz5vPezWQX6PA6XyqhLZnO2XegbFlcUtUXuxtSfLU/eD+Z7EcZrfZvw7nxXKIjvkqrD 5yR/SEsgxVv1EeB85RFJrUIeHIE92OolfAN2Freed5kwOqU+09EBQwwjNyP3l7VwIKm6zNL4Rzjq 2KUJygp88/wAsYWKUi9lDJ7JF5s5U06/f8y/9kdfj5bsPabM/CjjQ+yaiSGBc4flexFzba2DgcvW CzVI23P1zkqm2lsm9DZAOVmCzmj+oVRUuHzZ9nujfVMeO7/+Af8mIv7xR03Z9pexbtPoP9TKFUuJ FsOms3cBZPjhFmNAVG/84swGlw3rbtd2VKrPWyhZEQfoeMTH+EP1ax6nvfYim2Ym2yqwSEHKVNVv 3n6notI3qy7wnj/Zz36ofvpN3o2jDbWl5lHbjgCwAzsaE80+w66W5pWTjguqt1WnD4LvXMZWrLAJ piy3zsYTUPfj43jLc7qqSKI6bfmdkpn8wSfY0fDzjDCm7fH7glN3kh5xnpWrqLSScWHmGrNX95ci 72A5OywONV9AbGBWOfSlmqc/1HTbJLfmyNJea0x108lUWkho4+WmkT6H52egQfoh4uxwwxZgblmD OSoOOKLOvOGVNbbHSascc7zUPo4qy+zOp2+Yc1gbW5KdzaqMuPXn9Gf5FNr5J18wpKsXRFn0s2et 2ot2P92jcDDwAK3gHs38e4FqqJ14VitkaOhuqX+UwK3EE0RFGm8bg5oNSYIe7VBmW3EFgw/gGI+J Xpjs2ugsw29rU5EBcmP2d+tjxLIbtYrhgVqVxXIe1AdB5NaJSze3qwU0BT3NL1MKfQqh68+KTGyR +dPZlQvCTQiW+QxZdamgdDT/AcT9sxM1CELgQ18SNbp38lOg95noB8eAWvFhEfLoW93jXGI91A6p 9tgHDBl2W/wUSnbGgWU0C2wym0CvU8vMzYueAJty6OYKCzdkbqHaaKUNv2VCX7tYWt0dXVFnKG3N I1BON/qJV8g7xJQ38Qd+xtUyd1GUwtsWhjViw3sfnwz7pvSVENKtuTRYruYg9oAyDziAbDWJwtEv V8CaoWdALxdIQ2f3tebHUUOTRZvulHLSJzSZCysTiAwvXMUHDBWR+Mb4vVjOYG9I7vtnhx3oLQOQ 4VylHXVH794WvPcYlfQzgbzSMdEn9O7m3zNOV5+cndN8dPSmpdpAI+vemmMtZT0LEJaevAr42hvl iViVIehHbUwHfHlgJsD8eYajBZ3sQHohn9xlkTGvB0UZ0uV4OrLOmLAAp7UnnrBko+SDpx5L7oLi gWmzZ3ZtdL6Z2FPd7k8+ZUhyeEpEUwIjCeIt6PnXxLlA4QfENRMVVl36XnWSUoAsgbW76nrcxOa2 groXEmQ5UKSQde8ksmjuxvF8+uvb6n3BfrpFDx0+HIqeqJQ95KRfitRUi2yovGdge0UX0wEAwg/g I8GnJ2Jhkbdu2HVozZeAMKmFgwM1tq05Hy+UJd22+F12uGaq+WjE5LxA1ultFYMk2kFY2VXbZ6sY S8JZF+wwsNmhK0A0PHsyLKdrXJBKiCwk6Y+//PBsrWiX45JPc1U35qcoO4au8lS0FT03k4W5VD0/ 2EFFg7J/ILeFQ2vmYuaxecFadfK9o6JNuMD+AE22RMXqJfEZbf5ZwdtRy8RAuvlkTTbmjWqxs7/z 1sjM4sp7WDO23MOkV+98clB04sO1FNU3MXU/U3Bbgg6gaKdCcI1Q6PH0LLtM2R+Qs44AclYc7PSz UlZHKPwJvbuodbC9dvfcjHcTrPXdoihKVYTsxGDxmiv3dt/boltmbKAKrRl46XHLodhLU4TBIWs/ V9423AATy5XIq0MtehruP1DGQd2xLpM7ebBmI2U+vsM/5BVr7pXhV8JzBmvi3BoxDdc6bqCPyHzX iozOJOi2PO1/KRem5KcCa4LKD+EjzD0v70lCUjMd2JG54s3qqBy4qEkLIikzqlIUWbpC4UhI6/z3 omf8hiO5M9odEPqBnlcxlz9YOuYw51pJegUJ66zj258g9NUHYBAn2bSXqifCK7QH5sFRywLCeXDI 1/TxSbd0StE+8L4Llo3pa0D+KWDeGbN6T+LtsjFEoKZCV82eLrdg9A/UANrGOHnzl3dIQ3DC+7La D5un3mwabn1D8DQcfMlDvfcyl0mzUpcdtBN6uojgtrXXaAR1pfICT6u3uId6kDnInyJPG9nmKFNd FSSqkP2465Clk42n+S7kI3UFy4m/yiGtLLPw8XLXmgJcBRM8fFPjm0BG3BHahryUHM5EfOSmJlQo 07BVdvs3sjtAEBtlz2cZ3kh/qxJZIq1cJ/nRmx5HOhiK3O8lJ/eMpFda5SoyuKVdg5LR1sr2M/4K p+gMptUt2KUkwdrNKfkZQC3+UJdeKrCMdh3eZ/gQtG4Z/oi9eN8alazr8xryXF/u0cWUQ2t9i5+H 6LU9Sho0nzfRT0MbEAp0Z00j83q/Z6SNht6FbbUXuW57GTn0+xZ3KBYKE8g1C2KFVhMbDQKPh/7Z Cc9sEsAFGMfQgE/GlIEa4oxBxxeQhznYWM7682AEbjoASeLLNd7WR081d2vFbjRuGTOzYLXn3U9P DRA+sWhgJJC6v8lF8Alzz+63i/0N8s3eM4O8ItWeRQePxgy+EocalE6bKNwqf9TOpXar14AENAMD rQLeJd5pcoCmkYya7tVzluDKI4Z3BJABTdFmyh3rTl3xvXKo1++GDV06psJJY+sgjrVj34Aac3Gd 6800Bc+xob4aI28JEYczptt1Rq5ER/4eLIt348HIrZ4TMAri4xdYlGYpRLggo4oW3G1tLfKh7iAI lyE8+3Ac8dpa12+HMA/ee66s3J0qwXYo+RwQ94i7et8K7yMTUF821s5fmzARWYs2cJ9MQK2uC0cX +5QXEOLOnrHbIIamNyFrb8JU+OhFvnAKogrqUtdgbZUgWqchvdPkcadbqq+dPWuLMkM9SYFlVYVl GOOA6Pa1mXLWgU+s7HWjtM3fTqltXRAEYCmBOPyYI+01zsBeSXQtadLm6+2ZqLAtcKv3LfFxSpCF 6DuC3cthSk9IPMqVn4bdGeyfZ+BOPhT/xjaHw3PbqGvXcJ/fIVt8FveJn+x8g+B+wpn1vBzKQ10/ Zz0lbrW7/xMqYkWZTJJeeeuDxCLIuL5traHPM5U76zvUYZiR2+1FJ5W3qbnZ9Ql07opn1O7ezzUw 5KuK++1u4HkIcltHDarIM5RB/sITWQiS5Zq7BdU+zp7QIFGQOWFaXHnQCrHROLXvfDWGc8vH1oT8 p5fEm4LwaB7iQR1DBKT4+b507lfnL37iJ23izopdcW0nN1ehYGdzhUUPM0+22bXCWh0PD5y5qOSm 0lMA/jq7UDR9QfynofoIhNz9teKlx9Dr6Sg9N0ggxjsav+sJf2qWjFYWZauv0x+IQoGY0QzCov0D nLrz+kNyPGtC6MMCU7l9XT3bO5/pSZz0OklHdjUnirV2a8D7uu0Rr4Y1kAU/z8AUv8DS5RbgkbDt Wh5lhUjw27JbfF4WxNPgBy1OkWN/Gl0Gk/OU63BlP3h9UTQLnUBe2xJU5GF1bB9SXlYYb3hw6Ukv jxlu2mwOl0+JM4VQkH6/+Rv23BAv5Yd6o++Tq+FD0L1xSCRkV+pyVe6RZO4R4zrFs5087dnNxyft zTtMUiyqT7KvnbEicUcy1HTRmEPNHFdcWVBAoHloenLvh8/vaAHGPuWEItbxwdki7UXkBxjBcVuR f2K3+Vstq8y3UxQLcDRWmPssfG6H/U+7MZ7Zu012sImfzOmmmh+bjsx9+zEexnNF/DT60SV+eDtr Nss4u15J58GH4FZQ2YfGSniXeWZ1CO6wOW9nWnot8SH5Uw/avVCBbRfVXrKFWmGldUZHob7jHWq5 iw8x+yIcU+gKX9bLEpF1F1BaLSi7cZ5dn2H57qOjUC3jk7c36iDGH05uu94z8yQrRIwuu6LzRF/u XRM9TSn+eTmx/0liYRBe/U2pbNPrytOakG679buvCHpTD4T9ud4GN37USoWnMrtzPx7zUqNkaXbq QtsEGLiMdvY8+tuS4Pu9gsK5LNHmrTuLsPyhR0fwVF39ABrV1jLhYtmIDEU3QCGwLg/Tb29p5xTg AgPZY9wsZdOeKiXKhGceSUZQ4ViLq7rn9l/s0ML76FouZoz2/qln/jRrzgFT53DankRWzzllt6uF VuFXGAqFQliocPg6T+y521UtvM1p9saHY2obBgag3eST1hC6T/UxocrYE99ptZM/1T4GbPO6cZD5 YTCXyqdHj769P1gTDGisTSo3sPd1xOgQUt7SMm6se6xNiG2mg0XPALkP+1gU4OzJp+LGyn5Lfeax Qy/HD/oEFPQNp2UVvVSpKp/M7NQ7awY3bh/1Ie62DIiKW3506rjFazMCLdEpJOCL6uTukff9qcvk nnbIJ5qfd2LuTbJPmYk4xSZAXFW/q5sMStr3aQO+S6EzMzDA1rXoZeRcpWlqhzPBWOjtgeQ59VE9 PQNEOVAPN0U59TiCvDdp7FY4tJ959UvhpUKFAWIhPrDzgdnoW4fgP+8BT+hj9z7aOEP3l+xudRAu kuch08IA/56wamgQuM79jWuYseLpp6dSl2gHKs7iwDnl6MI2u4rSp+Q9VgqeBYSTy4JcQuIteOQF /4DLfSYDa2z71zAPVCW6eSptO9VATyxt3BuIbit49IoGt3i6MxcyOMt4uVJAiC/yWY4xrOBp6/rg wklv8icJgYWOOkUOLjJ2UQ6R63I8aYEXEeis3f0T1ItJH51p9KD5Tq4L3zuoh291dkqnuj53jGRl JKJD8xiRvy/RyC/EbOQ79nbHB6AvlUlIgsntWQdTVyNxhw895H7KTQtmgqs3/Shu32ZZu5OFMqDx I2cOY5z1C7QJe4MSpv6Q8a9acXf1tDrVtnm9q+TbOqWp9dz6KDYkliym2BpqGw2aP/orw1jFYkdb 2PojoONJmQPhJsQFeF3FDPocOhWghx48ByAIG8O4oFNtKa/EYR4G+V9zywgYAjL0RotcRsK4/3Cx 8++1jTOvBLJizFb4ZBu6IerHjMZI0xB214x8SMFiFf5oOxdWh8TnDd8nD+zElp6tHGudCigeOTcU hytRFj4gvi+/lXWV/hnyA/nla7mrnM2373PS+f38wg/pXP5zcWmZ9bHcdUUC8YWfgxLvME6nkL/X CPDKCh6KnoJvNzCNnISs+s9f5j/73EWKLebnXzZEpk+Iv+9WNIlWidRvfVO5FINqRZ52GYQ6HUTS 2A6ztOjmD8paRLU5aPuh4PPvsFrqZ62G8amTRWtK/M+7F9Nw3cSCrAh0sae8AACwu0FZWE9C+4hS HimO+Qaf+QTi4d0dZrxvlt75kn27qp6JbkWbt+6YSzmWcf8Ors2DgoDIfmsVmfnajtwu27xlBc5S ph7feKZITl3t5BOcLEInOV12H8vAY+vAny++UEQ77ErXkW9XHlJek1v5o0gE/+YetT5xOIRQGLgH RMxc4yvvH4LLsj5BN2289Knz/A71Os+hqOSGkwYY6rUlwvm7HhBVY+4FviJLAFrwmh8kPtQRts74 Bk/Vx8QZNCUl7N0ZSrl9wrfG/SYe+wcxfoHnRo2C3jc6JW6Quz1lDHhPw7Jv7nnaO9oNdDTO8aaR qE7LnFGKs5Mshftie/L5O9eKFnRIyLseZYb0Ti9CrFLv2Le0wo117FZ38oL7W8M6agnovrLY67fz HT63DiLh1y/j+I3xlW5Zo9hr4uuwNTVD+uNaYOp19/bLJATGhtf9bq0WYvuH8ic7X7qoXfe0osTO DOd0fxwwW6v1ENkshvrUR6RNbfeFQjqfVO6tel57++g4F9LfSyV8L481Nnd/nLj5kHHJ+0MQN0RF nAID7QYtmsWxldGBiegydGsx+D3IxXkALL2HVNFomBzMwJizA/IqPwGShn8hgLSRP/r4frKi9mlN se64VOscuiFzaNNS9p/0w8/9KIYHLIcu7RFoOxrbtcoj1h5UCzZch17005CvQU5g85J3HXNL0VEK LOKaMjw84u3R6cKTw9T46IS4NYZ7Nbibf4s/5Sijc28IVO7yVaZ4k8QR+XFF3tnTjoZUQ+D27Pno h07yittlTmDetaoCtgWfaXk36ksYWGTIFsu6eLo1tShmuM89VRKTCxL4j2TfdrhqkbsU1zC6qCry v28ze+X1Tal9k4wxgZBE1ZmFI+Npiankx5gvy+SuIDrNq9Ml8TgwUX2kZPHsVXsRxFEoQWTinV6T W0fshTPIvT4ipUPdqj5WtBrxY1il7c1P8bcCL1pl+pFsyelse/oYZuVHEHlZnMaYEaEiV9zazssr OB/tVH4Islupjfy+pvx5814bCMv2L+4gZfaana69i8Mf8paPVJx+83V8C/2xlSH/Hk0KCBoPk9Vk kQIUM3Evukg9yQNDApnld+cTzkaGC9Rv0kPELJAVrVamrCFoghQY8s3tAnkrSPHb0rnKGp9zvStW am/dpmIigwI7NhIYWSWhsjtyD5tHb/bRXOTDhds/nLsYOYPWoja3GfuHUSjrnhZMztZc4+adK9X9 Bl+qHgGNK18ueBH61A3ieTHl2EUfWnBY1DGpF8tgsjL4nbg7KdnbRFd1U+ZQepamoJkdUYVuZW6Q V7CGb66bRA1TNkiB1haC1go5puAAu0W0TrS+tOBeMyEy+ze1Eyr18mUbWGcuHbFztTFwcBa2VDtb 5UP1M79m/phs/LzQxYMfi2/Akquzjdjf8myMBMhNwmmo3QuY3c8LRInlECVTL/hnc4DIrvfDdR68 sVaiUBZV6kY2y9YLaof2yHO/cN4kFXcfPF+kjnYrO7/5TCSE/LmBmoOTH53wszwHefJXMQX1anjk 5dym3WZDEB91T6+/StVLPC4tqghmXkE5tR7wn9VdEnV8aSErtEdO3UG2rBTj+uZzpigq20Ukr5Cr PqTx2RfpajfIvR8qHpl3KfW7tfeGksUBkXb0Oz4GBtmiKy4MrO0VXOz4XaJwT8Mea2Du+Pa3ArCZ eeLuphbXvZh6WTuvomec45Gjk2RH0rKdL3YPIvx9bG6sknUfRaJCqTdcYDVYQ0bIve6QQ2NHx57a 9c/qq/X7g20/qZO8HtWVbaf0+EhAdh2Za4VPJfNqhh0Uyqglm+AMvba9+f7XvleG6aNaCHKHAne6 UFf3+eGpsLt2H8U3tkEWCiS7zSy5xQMz+iTy1qr5XkrbhrIDhQOWImvx9ytERL0T39q12Kcmxm3g THUhpe9RMcxkaatIv+lBv3jT0oz4e8KbSMPeVlfyrEjJjn+6Pdc/a0JmE8FgdBbeLt8Q/5skopRd 0i1DPM3OVV/fW+xgIkai9+Zxzw0NtCAeyLVMnLZahy6SjDXu/8xTKlh5SHwmfHtmDvL84KvY4i0T JJLS26y03u0fwCVKJmhcfpu3uYn2hgi2+AZ0Tm73jdt7i3Q3Nry9U20XyVexxPM0a+8DQuMs0ZDq ns82ZfYvKrZAd2lwP7yIOko4q7S1rM3EvW5ZpaCojY806+4ZQwgWwuTV5Co3yRnElqq7LMZWl8FM dP11fj6yXQyYbowhCMeg/sX65BGbE9Z9MDOkjmBYcLldMQHfuYlEfvcuLvVZm3pgOXWC8+7FeOsx Tb+9xFcvrHxc+u2+81X2UkD82Moiiu8iCG1MARvJ6mK/UMnaMefjrEEVBR1MBQZB3W/0JComyTzk xTtdDINgHtjr/BR/Z4CZH0iHPphTGMCHBGYUzfX3unO0w2IdrRcfoHueMJJ9DDytc60aeHbKPtlB ULrm5cDXPx2qArwFumuFtsrIgmVoC7CUmqXopJFkU1D7x3v/AFdH1kNctuaiQGt0L6bg2zudJb6O GPMD3L1BB2wHgXtfdYk91BJb6q7TVEfdhx3BWC8BrzHnXv88ay87w/4z+oQIjDvQAaLKd4CpmQ/G 83dTOwOm0Al/gFgtaf25LZnpi1tSl1uzMiF4ivw7TD8xd8ZuLOzuFB9rurR3VyVpHvmJRFci34e8 2Fn0ctMHY/oha3ZwcUyGnNjbPgRm6Wof6MAGK3SJ5ysucq84xof/eRFyP9Wu466KNwWyfE5WsMOZ 3VNf6WaA2SvQ4pnLRg6c/HSMPH0aV2hT/tf70I2hdMPnYdLfkNu6Ni9UzUeIC3N3vi8tMT6xNSAu wkChOTA6WBTAtSBslmvKbtV6HI5SYVv9EKecCCDZbTG2snZSbwzQsJsOcFa34cmQXwRGv/rud0/p iZdJ17j+gdwCy2o59S695goKSbhgv0bsNfDpsqKzvPhC5+tp7wNqcUhU30YN7tuwBeKd++dCjXX+ 7CxRf1Jm/qTFrqOMUrinzdQP1PuJGX2ADE2esYFiZ4WwZp009MnYzQA3thZqCXlkHQJriJXwO4Tv sOR2cxM/jP6+yu1/PNKpwGITvY95kcxPDCJtTE1goAO5wGufp3btPHI4QXgacgz14+OL3f2DCjG3 nfUPcxH24ectUh/5/Xya0ToNvmZwvOO7Z79VHa7wwB0vA3m7ea3JkVauinjevUTOo9hXAhdOgCfs +orhoIm1WyhaK32y2+xGMhXFGuqAu4e/YG7oaOsTggHO+9SE6l0Hp1o9OFQ1w92rYONkMThOgWsr Z7tx6hPX7If1wu0TuHehRS+9oIp88lfHhaKtx6/O3qy0+4rdOXxcNQK69kqkYeTAECzifmLrhOYg D/y69AXqmzX5h1mZUtextjpoAuue+k/lIA9kqMEd4aenIkdyMh3TdiVcjz7Oi7/qCZoj8emhT4H6 qsGIIQLjfe4U1wmXtPI93Y78opgJITuHbY4XsqliE2ebrBiRs+8Mfzb52HLSaYnqoNp9vW8i2MJS frO66mVowOPHAQ6LypmxGYZI7u5xlCF0uMF6rgikwps8cg8tfhNXc3xT7FNa+2MrpJHTQqBBqoQ5 62vsxzhb9f3Qz+M0th5CgVl27nPgfVHiWN0XdolRyDV8dZ0QYz/w5EO+DZyq1NI5V33lCKZiAomp Kx2b6Txz9g4aOO92ddjj/Q5HDRuNfIKpJmtwemTQ7zEByUTH7kTGri0+dmYefPaE08YDzJrjkfZH 0DInaJDyM83w1CvenRCoKfDTCHD1PDvANp7LykOp5juuEdh6IEvgtu18qD2mxoE08kUBSsr88rzb r0fZqqvCZ86921D+29Mh4h/PJ+TIpMyBie+psmEyL9dH/LbDLf2P7DOOcnhRVfcea3DTm0k/GZFv 8f2lcB3WhjqokURQrPX++Gi2jk4CbPj5vQYiezIyEgIFNZhaXG3XiWyT3QdsqLpasnPSDAsAFSnN 9HN4nLyC9AWAiIQgZOCyq+8CMBQUDSm/OH4MA3aSA2EX8xbzSCnsJFYcP5FkYgQy+/d/5GCTJCPb bWwsDKHWJN84bhrJmcFK5JK8c2ea5kMTOLnCvNzx5vnXWWkxlxRvqaz2JmrpkM1W3zPsXIMSeELc qYsp59vfgfS0VW+KQRDwPm3VfRAo7GbiJVUgI2Zjc21h+Ia8+a+q0spxJ20T57iCi4OCS63UAggI DFltA4Uj0ThCm9QlGVNjP77p9Kjp74BfaivUpfxx/RZc9X0kBIXG2AwAzkbPfU+UyZIeQ4C/8qgH 4a7cROl+3FLmJCOSBD6Hm0My0OOtU/GNy6CnJGb5J3mksBLxg41WKDJOIyOFnayyqGrsjdvnzmaQ VONah/P4Ai6bR9JjBKkoGVdpURS92Cl8U8LcBYj6k4So4JT0RKWhHY3LgZz0ODaKmSIbmrI1jhuV teVuvVUsS8LjxyGySRw2KUcywq7lUEkJ6zIEQVwjkisrJSGN5JeYfbtm6iWf9EqFzTcS5I/1pc9U qnonJLLw6ikaTPxUe+yroO0ZkUYQPw4hMq3ydo5SvN/LnfaJaVNDnMNBnCR+FikxipZj5g/PzOQh XDnyBVFepbSej+ynw0wnIoku4qUgzkb2o9MNkk7jCz8ld/IXavNQGeuS3d3dgvTdA4O8/P1IjEc7 oE89/EP83BSz+qPDUMS/4sPZ3deaLAvVSrc75ffL7kbJeyXp2K5QhhwJDbsy/8IlMBWSzYrcsyOh Oes3UhOmdrXxZBySeZT1HBdQoXZ1HDTOV+V5c2HWRncuN1avrV3NcpH/Jwnrn6n67nzTVBZ3Q6JF Ci3JrWoZX+MEEHlOsrK0al5huqRpU7h7EMfZJ9Q5XIZjdHZ2jwNFNsPQz5/CpKkvBh0luzr7ubr7 RAV5V2FULCGMFB2GAJFjdLjQyNqek6H81Uu/xpKHTYrznv+kzGhsmhvCx6HYcRgEhpusjHpwZEtM pqKEc/4z+0ab2RpXPsugrFciLo308zL08PJxJ/1hX11jc4jFPpibmOLFMYsi3zpGqbvDSebedq1P c6nKjGP1bquQ4VFMk6vtEioH+iwjXvdkrHHNWWLtzZwCdrzpSDG8f2xrx+QWrsPukhiHsiM3jDe2 BicXfSjLwjM4WXH2ZKMbNx7KhrWHariq7/ZIwyISfztsRpaLqeRtkyQUbSOte3mz1qZINm2tijxR +THeLVH1FX+85jPsCkBPK89iz+u1v8G17srVwh97d5OxIf7Q4Kdq7K5r+LoMkJjDWbvbDpo7SzB5 9ijIe642LCc9nsPiOSmnTnap23mwONMbnsYcodrVEPg5EaHOOqlA4bfUXn40onkMMQB5XCc3n+R7 uZz48bbtvKHqrvgsPBAvSEr6bljHCUxcn8yTt0oZaK3i7RpO59iZaO9OPJ7m/Tx9w/NHhzIYRDZ2 rBtMZ+6I7oAUx93qeiaz4a3G3j1hD9JgsYWgXouuQRqAwAXztALhxPcMLSDDmNoCV60Y16LJxpJi nc84n8E5CdGmnfnUUTjGtDNWK4xQjjb17M0Lssu2Rj8zF3YHyDNNO0lCgyqkdEYXe86aCzGm0GCE Uog07HuXR+av1pt3YhhSIOlehq6qC93GnOHHWaejtNSd4SnHjgQHbWuFx5XbD5xWkcBVGeUsSh1a Cs6lPgvSGQ4JVJDOqud1uNKZYXoPtaqJX1MBXtXsdHm/qkFEqK1qDrhuXdXYPldc1aSur5Zd1ZRs +pYkZWF0ZWlwrAUwy1zVWj7GrmqT9K+uauG7PCZXtTKbNVf7nUjYUSVlHYeJWq1Smm10ByuFKjmt PX5L5c6EfZIAiTyjXDtFKNliIkXVtjjt1Z7nQAXSgOH8NnwVVPflrILNs5TVD1p3U0YalIu8vpT7 cspD8CoSMGifM7xeYPHnammi3u+rKliRuxT2fYrWWIVj2x1W4WW64eoaGzBlvtLI+WeQ4iq088xW 4UGCzurCL0KE0gDu+iFyFYiHclfBri9tdTfkGpQ0UBV7z6m6wFVDVbJWOasnyavc2muIVW73xulV iNE6tQp5Tq9vSZtwtDY0Y9GmA4zTv2n5r7g+pHlJWs+aHkDrvdmrJ416bhxAH0R/fih1Ta+MH10l Busf0h7SftyXuq4X/lolDr64LRXpfe+S+gcqp1aJk6+kGtOmZan7sP38u1Vif69U43rrq9RFP/pj lZg4PrRKNC6uflLHpVXi4+FVor92XuoffHp9lZg5vUqM3HV47TUiyYOdDkXMXOT592LlI3EjWNip i+GnwqEhztFU/vT4EycINgx8Hat9aXy4N4p0GisTcetSyiEkvaAlNk9OegnBBaqE8v2ufgh4nI3N +/exUIiJNJIzxqDlbO/ta70ud+9CnZIzI+dGSoIB/m1iBI+U8oI+ILkWyxPE8xK4KfGJjLU3ynGP vDM1lWRYjI06JYcL6+7zc7qUBluQoUTN87cO3axlGTgkaB27+CMQAoIgsDnSR6aWU54EtPpUlsZa Tnvx9sV53+e1r6yvApQxblSDRkeQ/SM2BfrqjIzR4aFNAPAReA30/cWtjwKagELABbCJMjr8CDAB 1gEEAAcgSXY/Kp1eS4ALCdPAGQ9ajZXGkeO398EBmOSq98ABFYkVdgUeGd4yjISpYBM5poNWM3Dg SWgNRcVKUnPXknftFfziRSRaDqUyA8lVuQi3WgyM3DREbFz8GejsEgELD4xARaqsnXGsmo9HycOt 5kj6HzNB2Rey8ddhSjjiYDqU9kBlZVof1vij5TXc6id102KASQBosSHTJAIGRKAiVKIiB25EwHCb OLENkomaPgEsGM9WgiUKdl3EKd+8EcazUkFpKHM+vD5FlB+MhmykeoBgk4yEV/JdYZyfqB9UjrC+ v6wBH50DAnhmwlyFMQ+UBmc/4gfgbBLmGRg2mHytHgcrwqA2/QwYIf5476+UyMDp4ZQvXmQI8gVm 8/iDKihZgJOeORDnKvBEqcQzRspNYCYc9AcZuZ+38Befbm+XbUWFq8CUPpZ2lI8syupEWD024UFQ tiqwB6racS6h/ltX9u+yu0pE3kXVwE57a2hHcmaXuCtzu5p0MRA41CtiIO4hR17veFMsAgbJstRh zKDmrX4g9CIHiLCPWCtipvbMtBcCNtml0DYXil20ss6dMawfRMB+ljeFu3RgtTmsuYjSH6nS4qpE 9Du863HOrUc7MSGcjTDbCyzV45yCDYOP+V9AaSmCki0F9cofOfKKT/UxaZMRHBhnY8DgzV3lJkAk J+764QoBB8IhDz0gfA0HR3I4BQ4+KsdHugbI+du5+iMYjh6rTcVr6YcDZI3uvv2ciJ+1g4yZzzKL KbvnRq6nl4MnAvvl73qRvVU3WH2O+O1t6W78Qsh+eo3paavP+e+HVb9GoNDYit5NazhJExzt24dR 6HlUE6Pq5orVWxnSn/GFqN037pbGgh5SgRZPiIy3G/StA+jm90d8YQhFfiajBTRv+6nBV5EEiXPg yWireES6cbckWdJossol2zG3AobWO0KPSnYGMfUaugSnTUIRW50sGJisx9uvpbFAJEQAXxXblc6e 1DPk4GE5iCJpuoErk5D+m2BdjlG/ILpf0XVDimoayg+fTXTMSrJcx9/ARkULJh40fyQGbHRtTZBn kScxc3o2KXZMssQhzrWm1mgSirwRbcntnVm3E1guUAeXnXtzEyJHgzsxZWYNhlUZOxEXNrh1HsiD r1XfPN/AgiSM+Oe8IxZ6WenlxKmmqCwVCl7l8WxsY/ORBbSzg4E3go9mh8x8rRh0JA5S1UFaSl+m O0/F5VuAAPAfVWyFhlNXkES3PO4fSOyga2VOLgR0luOzt9SeAawIoXKmLoX747UpKbYpyWzhyf2L niNe6RCfrEE7E7Ev1ylzrv7hACzrVUKIXnJkFaNig0yOd1LujPbe+Rk+1hXjkBV+lRLU42IoUw2k 6G4PIX6IK/Lyzre61YDtN59I345gIWIuE8fVDnO/JvNAZp2Em2uFNLxJArw+jgESnUYCk16EjYfa FhNsI/dBSpViIDrqLkCox/WUCX6COTNR8IL/ZhCpCs6aP9Kyj/4IcV23alPyw4MuVg8gjxhZApWE HOfqp5gkjEVOWWsA6MDgvdGZ3405+z043PQ4vu8Q3fmK0Rpn7MZPeZLaRDSHIWAlesaxGSx5H05C HMuDid9mhFAPqu9bH7b+idd1w7uNsvANfnHpG/wF4HtzQ/wMsFtivCCZwqXXUoobFUPY6Z5etmkB 6Sye2jGXYGtFN3ETGVPFZjhHKvraRvKcao2RzvyoBAovum1ntmWzfNAkqIet5xPHSKAPr53EbFFz 4/DciAO5jaSoYI62jNNg4dxNtCtLF5dn+TgkI4jbtGJX1QdekE2lXRDOstmZMXBOkoU88GjDvZ09 n2UCE5P9M7wpJK3FxBz3bGc5d7YgfRu+piMKiw4QJL6m/3arl3UNrun+Wml056ILj7HpVE4QMzG7 279Xj6VoOkEKMr7TnteQzXflsOCy9bvk0f42LmkvoCya9hqZaf/4VJibw8BdX5ctQfYpDBeugMdc mDUfYlGSvp+J6ctMbx/XzkAi2AlmSIFVFgURk7DpJCtJPcYiq/DujoTEDH4Mk8E1k7eeBnpu+MVA Y3yxLw1r0mRM0tOPEhipAgx954BW0kFi0i0L5Z2qMSlqLuky5yz+TM7GsXh1yixegLlaGixrYSjq Gz9ld1hCxjPz4hvpTmEJ6QVsZNLnzVeBNz97Tq8ffug8/YjPYWXkMC15M3hSCRbBUBk8Xt/xGuuE 3fB4asEqfSaTx86Q5SehZOWngw6qEJzhb1vxm8zvKtKTTvXgZOw6EwKDcvgaF/o8km95J/S7JCHM 3MYNs3ibsN6p6guW/S/cTnTJTbOSvazGN4YGvuh3XDN8Je6Lq+/i464ItBqK6sLJduWGVykruYVt DD/ru0mtIn79VdDnmzohGeeDik2O77XFvL/9rKrvGFK9vfW9YfhZjSD7jsTENNkP7DvBXG0ey0lh Z7azGz6fOFL8PfI60VXA5b1wBlWdxKPdpV866uPmwtVTW/KuWBDK21kDIFCPxDoi9Z2AQz7dVIZJ pzvkK4IV6FOjUvUJfWcSM4lDwIGloKV8a5zrkTH5mkhQ4LFL2SDN2NNv8Eb88YeO5fHzsoPUIzLL RlzvIxo6J/eggiC3crsSwVQjfXtPCitozi8WsbbFnzcYK0x/D0yUr833r/bvj9DC0CcrIP847KMA SP7z6Z/YZqCcCpQ1A/kSSaiwSzKBK/9lJXCPYsRG0JAAIdYUTi/JD3Gn6laPf/2HjHwLaIg3I5D5 O+S9N3koHINwMa2jSGm1cFbC54vu/0f9w/8UCEjO/0L+p2bCVnDBMvBVIhH2gMqUNgiXlzKxJWAX 6aK8BPPjCRKJpFwMFrZBRQhhB1Q4Ds36DHo67iNNbxbN1xdLV1qC2EgZswdlzec7gQRfxIiSGGhS 6xiytQW36966hfyJMdDsai1MNPB2ULr/MwAgRsi08O3FMdCyQmPjVulev9KEHUjJoTtS/6C0HbKF Pyz6Eer55VqI5FCLNCmVI0QQYTt04o3k0D1pIm4cXCz5lyv8/+3/noF/nWkkAUA+TIqx/zg9+B8M BLCls/X/JL9qNOkw3gsASFngvzEokAb8OmaYzwJ+nTXNTwd+HanMX+2LBP3XvjJQALgs9ayPA8CO //b85D90q8cS604AAPt/o1uQeganACAC/L/WkaR9is8AQNR/0+9bDwDc6fnPOdAzAHj8Lzk5ae75 v+SI0tzwv+T0pLn3/5IzluYm/yX3T7OVcp7SEfbsH3HS38j/Gwv/xj1/44G/0ds90M/dx8zUyM3H B3B2ozvTvKQBg8UCXP19XYN9/g42uv0z7RtEdw0M/uWGBLkH/p0FfDhxDJ+UeG4cN8cZADYm8mlc ToIzg8FN5PEAwD075VfiVwBIn9iuLA4v0TsxRxpJ8xmJXP7qQzmRL60NTszm+wtWvURplbSWzaDF pbD5wP+3/8P2PwBQSwECFAAKAAAAAAAQuBEpAAAAAAAAAAAAAAAABgAAAAAAAAAAABAA/0EAAAAA YnVpbGQvUEsBAhQACgAAAAAAELgRKQAAAAAAAAAAAAAAAAoAAAAAAAAAAAAQAP9BJAAAAGJ1aWxk L2xpYi9QSwECFAAKAAAAAAARuBEpAAAAAAAAAAAAAAAAFAAAAAAAAAAAABAA/0FMAAAAYnVpbGQv bGliL2Rpc3R1dGlscy9QSwECFAAKAAAAAAARuBEpAAAAAAAAAAAAAAAAHAAAAAAAAAAAABAA/0F+ AAAAYnVpbGQvbGliL2Rpc3R1dGlscy9jb21tYW5kL1BLAQIUAAoAAAAAAHylCSkAAAAAAAAAAAAA AAAEAAAAAAAAAAAAEAD/QbgAAABDVlMvUEsBAhQACgAAAAAAYZG2KAAAAAAAAAAAAAAAAAMAAAAA AAAAAAAQAP9B2gAAAGRkL1BLAQIUAAoAAAAAADOTuCgAAAAAAAAAAAAAAAAHAAAAAAAAAAAAEAD/ QfsAAABkZC9DVlMvUEsBAhQACgAAAAAAG6nCKAAAAAAAAAAAAAAAAAUAAAAAAAAAAAAQAP9BIAEA AGRpc3QvUEsBAhQACgAAAAAAJnsOKQAAAAAAAAAAAAAAAAoAAAAAAAAAAAAQAP9BQwEAAGRpc3R1 dGlscy9QSwECFAAKAAAAAAAIihkpAAAAAAAAAAAAAAAAEgAAAAAAAAAAADAA/0FrAQAAZGlzdHV0 aWxzL2NvbW1hbmQvUEsBAhQAFAAAAAgACIoZKTHYaCE0RAAAH28AACIAAAAAAAAAAQAgALaBmwEA AGRpc3R1dGlscy9jb21tYW5kL2JkaXN0X3dpbmluc3QucHlQSwECFAAKAAAAAAAoew4pAAAAAAAA AAAAAAAAFgAAAAAAAAAAABAA/0EPRgAAZGlzdHV0aWxzL2NvbW1hbmQvQ1ZTL1BLAQIUAAoAAAAA ACZ7DikAAAAAAAAAAAAAAAAOAAAAAAAAAAAAEAD/QUNGAABkaXN0dXRpbHMvQ1ZTL1BLAQIUAAoA AAAAADxa8SgAAAAAAAAAAAAAAAAEAAAAAAAAAAAAEAD/QW9GAABkb2MvUEsBAhQACgAAAAAAPFrx KAAAAAAAAAAAAAAAAAgAAAAAAAAAAAAQAP9BkUYAAGRvYy9DVlMvUEsBAhQACgAAAAAAgKUJKQAA AAAAAAAAAAAAAAkAAAAAAAAAAAAQAP9Bt0YAAGRvYy9kaXN0L1BLAQIUAAoAAAAAAIClCSkAAAAA AAAAAAAAAAANAAAAAAAAAAAAEAD/Qd5GAABkb2MvZGlzdC9DVlMvUEsBAhQACgAAAAAAPFrxKAAA AAAAAAAAAAAAAAkAAAAAAAAAAAAQAP9BCUcAAGRvYy9pbnN0L1BLAQIUAAoAAAAAADxa8SgAAAAA AAAAAAAAAAANAAAAAAAAAAAAEAD/QTBHAABkb2MvaW5zdC9DVlMvUEsBAhQACgAAAAAAPFrxKAAA AAAAAAAAAAAAAAkAAAAAAAAAAAAQAP9BW0cAAGV4YW1wbGVzL1BLAQIUAAoAAAAAADxa8SgAAAAA AAAAAAAAAAANAAAAAAAAAAAAEAD/QYJHAABleGFtcGxlcy9DVlMvUEsBAhQACgAAAAAAaJG2KAAA AAAAAAAAAAAAABEAAAAAAAAAAAAQAP9BrUcAAGV4YW1wbGVzL3NhbXBsZTEvUEsBAhQACgAAAAAA NZO4KAAAAAAAAAAAAAAAABUAAAAAAAAAAAAQAP9B3EcAAGV4YW1wbGVzL3NhbXBsZTEvQ1ZTL1BL AQIUAAoAAAAAAGiRtigAAAAAAAAAAAAAAAARAAAAAAAAAAAAEAD/QQ9IAABleGFtcGxlcy9zYW1w bGUyL1BLAQIUAAoAAAAAADWTuCgAAAAAAAAAAAAAAAAVAAAAAAAAAAAAEAD/QT5IAABleGFtcGxl cy9zYW1wbGUyL0NWUy9QSwECFAAKAAAAAABokbYoAAAAAAAAAAAAAAAAEQAAAAAAAAAAABAA/0Fx SAAAZXhhbXBsZXMvc2FtcGxlMy9QSwECFAAKAAAAAAA1k7goAAAAAAAAAAAAAAAAFQAAAAAAAAAA ABAA/0GgSAAAZXhhbXBsZXMvc2FtcGxlMy9DVlMvUEsBAhQACgAAAAAAL4kZKQAAAAAAAAAAAAAA AAUAAAAAAAAAAAAQAP9B00gAAG1pc2MvUEsBAhQAFAAAAAgAM4kZKRwV1hGRAgAAFAcAAA4AAAAA AAAAAQAgALaB9kgAAG1pc2MvYXJjaGl2ZS5oUEsBAhQACgAAAAAADrUSKQAAAAAAAAAAAAAAAAsA AAAAAAAAAAAQAP9Bs0sAAG1pc2MvYnVpbGQvUEsBAhQACgAAAAAAibwXKQAAAAAAAAAAAAAAABcA AAAAAAAAAAAQAP9B3EsAAG1pc2MvYnVpbGQvYmRpc3Qud2luMzIvUEsBAhQACgAAAAAADrUSKQAA AAAAAAAAAAAAAA8AAAAAAAAAAAAQAP9BEUwAAG1pc2MvYnVpbGQvbGliL1BLAQIUAAoAAAAAAA61 EikAAAAAAAAAAAAAAAAXAAAAAAAAAAAAEAD/QT5MAABtaXNjL2J1aWxkL2xpYi9wYWNrYWdlL1BL AQIUAAoAAAAAADxa8SgAAAAAAAAAAAAAAAAJAAAAAAAAAAAAEAD/QXNMAABtaXNjL0NWUy9QSwEC FAAKAAAAAAAntxYpAAAAAAAAAAAAAAAACgAAAAAAAAAAABAA/0GaTAAAbWlzYy9kaXN0L1BLAQIU ABQAAAAIADOJGSnQ5TOW0AgAAKMYAAAOAAAAAAAAAAEAIAC2gcJMAABtaXNjL2V4dHJhY3QuY1BL AQIUABQAAAAIADOJGSlllwfDLBsAAJZTAAAOAAAAAAAAAAEAIAC2gb5VAABtaXNjL2luc3RhbGwu Y1BLAQIUABQAAAAIADOJGSldLdc0VAUAANgXAAAPAAAAAAAAAAEAIAC2gRZxAABtaXNjL2luc3Rh bGwucmNQSwECFAAKAAAAAAD9uBApAAAAAAAAAAAAAAAADQAAAAAAAAAAABAA/0GXdgAAbWlzYy9w YWNrYWdlL1BLAQIUABQAAAAIAHi/GCn9gv/6tgIAABYKAAAWAAAAAAAAAAAAIAC2gcJ2AABtaXNj L1B5dGhvblBvd2VyZWQuYm1wUEsBAhQAFAAAAAgAM4kZKWKe3Pv/AQAAkgMAAA8AAAAAAAAAAQAg ALaBrHkAAG1pc2MvUkVBRE1FLnR4dFBLAQIUABQAAAAIADOJGSm2jsJIswEAAP4EAAAPAAAAAAAA AAEAIAC2gdh7AABtaXNjL3Jlc291cmNlLmhQSwECFAAUAAAACAAziRkpGtpb2B0FAACvEQAAEAAA AAAAAAABACAAtoG4fQAAbWlzYy93aW5pbnN0LmRzcFBLAQIUABQAAAAIADOJGSmoCY+61QAAADYC AAAQAAAAAAAAAAEAIAC2gQODAABtaXNjL3dpbmluc3QuZHN3UEsBAhQACgAAAAAAyIAOKQAAAAAA AAAAAAAAAAoAAAAAAAAAAAAwAP9BBoQAAG1pc2MvemxpYi9QSwECFAAKAAAAAADIgA4pAAAAAAAA AAAAAAAADgAAAAAAAAAAADAA/0EuhAAAbWlzYy96bGliL0NWUy9QSwECFAAKAAAAAADIgA4pAAAA AAAAAAAAAAAAEwAAAAAAAAAAADAA/0FahAAAbWlzYy96bGliL3N0YXRpYzMyL1BLAQIUAAoAAAAA AMiADikAAAAAAAAAAAAAAAAXAAAAAAAAAAAAMAD/QYuEAABtaXNjL3psaWIvc3RhdGljMzIvQ1ZT L1BLAQIUAAoAAAAAAK9b2igAAAAAAAAAAAAAAAAFAAAAAAAAAAAAEAD/QcCEAAB0ZXN0L1BLAQIU AAoAAAAAAK9b2igAAAAAAAAAAAAAAAAJAAAAAAAAAAAAEAD/QeOEAAB0ZXN0L0NWUy9QSwECFAAK AAAAAABzTL8oAAAAAAAAAAAAAAAABwAAAAAAAAAAABAA/0EKhQAAdGVzdGVyL1BLAQIUAAoAAAAA AHNMvygAAAAAAAAAAAAAAAAMAAAAAAAAAAAAEAD/QS+FAAB0ZXN0ZXIvd29yay9QSwECFAAKAAAA AABzTL8oAAAAAAAAAAAAAAAAEgAAAAAAAAAAABAA/0FZhQAAdGVzdGVyL3dvcmsvb3Jpb24vUEsB AhQACgAAAAAAc0y/KAAAAAAAAAAAAAAAABYAAAAAAAAAAAAQAP9BiYUAAHRlc3Rlci93b3JrL29y aW9uL3NyYy9QSwECFAAKAAAAAABzTL8oAAAAAAAAAAAAAAAAHQAAAAAAAAAAABAA/0G9hQAAdGVz dGVyL3dvcmsvb3Jpb24vc3JjL0ZwYW5lbC9QSwECFAAKAAAAAABzTL8oAAAAAAAAAAAAAAAAJAAA AAAAAAAAABAA/0H4hQAAdGVzdGVyL3dvcmsvb3Jpb24vc3JjL0ZwYW5lbC9QeXRob24vUEsBAhQA CgAAAAAAeUy/KAAAAAAAAAAAAAAAAC4AAAAAAAAAAAAQAP9BOoYAAHRlc3Rlci93b3JrL29yaW9u L3NyYy9GcGFuZWwvUHl0aG9uL2Rpc3R1dGlscy9QSwECFAAKAAAAAAB5TL8oAAAAAAAAAAAAAAAA NgAAAAAAAAAAABAA/0GGhgAAdGVzdGVyL3dvcmsvb3Jpb24vc3JjL0ZwYW5lbC9QeXRob24vZGlz dHV0aWxzL2NvbW1hbmQvUEsBAhQACgAAAAAAaZG2KAAAAAAAAAAAAAAAAAUAAAAAAAAAAAAQAP9B 2oYAAHRleHQvUEsBAhQACgAAAAAANZO4KAAAAAAAAAAAAAAAAAkAAAAAAAAAAAAQAP9B/YYAAHRl eHQvQ1ZTL1BLAQIUABQAAAAIACmHGSklj/6ScjYAAAA+AAALAAAAAAAAAAAAIAD/gSSHAAB3aW5p bnN0LmV4ZVBLBQYAAAAAPQA9AK4OAAC/vQAAAAA= ------=_NextPart_000_00A6_01C00EBA.5D323010-- From mwa@gate.net Fri Aug 25 22:56:08 2000 From: mwa@gate.net (Mark W. Alexander) Date: Fri, 25 Aug 2000 17:56:08 -0400 (EDT) Subject: [Distutils] bdist_sdux.py version 0.0000001 In-Reply-To: <20000824224529.A1044@beelzebub> Message-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---656673009-1108563448-967240568=:31668 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 ---656673009-1108563448-967240568=:31668 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="bdist_sdux.py" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="bdist_sdux.py" IiIiZGlzdHV0aWxzLmNvbW1hbmQuYmRpc3RfcGtndG9vbA0KDQpJbXBsZW1l bnRzIHRoZSBEaXN0dXRpbHMgJ2JkaXN0X3NkdXgnIGNvbW1hbmQgdG8gY3Jl YXRlIEhQLVVYIA0Kc3dpbnN0YWxsIGRlcG90IiIiDQoNCiMgTWFyayBBbGV4 YW5kZXIgPG13YUBnYXRlLm5ldD4NCg0KX19yZXZpc2lvbl9fID0gIiRJZDog YmRpc3Rfc2R1eC5weSx2IDAuMSAiDQojaW1wb3J0IHBkYg0KaW1wb3J0IG9z LCBzdHJpbmcNCmltcG9ydCBnbG9iDQpmcm9tIHR5cGVzIGltcG9ydCAqDQpm cm9tIGRpc3R1dGlscy5jb3JlIGltcG9ydCBDb21tYW5kLCBERUJVRw0KZnJv bSBkaXN0dXRpbHMudXRpbCBpbXBvcnQgZ2V0X3BsYXRmb3JtDQpmcm9tIGRp c3R1dGlscy5maWxlX3V0aWwgaW1wb3J0IHdyaXRlX2ZpbGUNCmZyb20gZGlz dHV0aWxzLmVycm9ycyBpbXBvcnQgKg0KaW1wb3J0IHN5cw0KZnJvbSBjb21t YW5kcyBpbXBvcnQgZ2V0b3V0cHV0DQoNCmNsYXNzIGJkaXN0X3NkdXgoQ29t bWFuZCk6DQogICAgIiIiIERvZXMgbm90IHN1cHBvcnQgc3ViLXBhY2thZ2Vz LCBtdWx0aXBsZSBmaWxlc2V0cyBvciBpbmRpdmlkdWFsIGZpbGVzDQogICAg ICAgIGluIGEgZmlsZXNldC4gSW4gb3RoZXIgd29yZHMsIHRoZSBweXRob24g cGFja2FnZSBoYXMgdG8gYmUgc2VsZi0NCiAgICAgICAgY29udGFpbmVkIGlu IGl0J3Mgb3duIGRpcmVjdG9yeS4gU2luY2UgdGhpcyBpcyB0aGUgcHl0aG9u IHBhY2thZ2UNCiAgICAgICAgc3RhbmRhcmQsIGl0IHNob3VsZCBub3QgYmUg dG9vIG11Y2ggb2YgYSBwcm9ibGVtLiIiIg0KDQogICAgZGVzY3JpcHRpb24g PSAiY3JlYXRlIGFuIEhQIHN3aW5zdGFsbCBkZXBvdCINCg0KICAgIHVzZXJf b3B0aW9ucyA9IFsNCiAgICAgICAgKCdiZGlzdC1iYXNlJywgTm9uZSwNCiAg ICAgICAgICJCdWlsZCBkaXJlY3RvcnkiKSwNCiAgICAgICAgKCduYW1lJywg Tm9uZSwNCiAgICAgICAgICJNb2R1bGUgbmFtZSIpLA0KICAgICAgICAoJ2Nv cHlyaWdodCcsIE5vbmUsDQogICAgICAgICAiQ29weXJpZ2h0IiksDQogICAg ICAgICgnb3MtbmFtZScsIE5vbmUsDQogICAgICAgICAiT1MgTmFtZSIpLA0K ICAgICAgICAoJ3JlYWRtZScsIE5vbmUsDQogICAgICAgICAiUkVBRE1FIGZp bGUiKSwNCiAgICAgICAgKCd2ZW5kb3ItdGFnPScsIE5vbmUsDQogICAgICAg ICAiVmVuZG9yIGlkZW50aWZpY2F0aW9uIHRhZyIpLA0KICAgICAgICAoJ3Zl bmRlci10aXRsZScsIE5vbmUsDQogICAgICAgICAiTmFtZSBvZiB2ZW5kb3Ig IiksDQogICAgICAgICgndmVuZG9yLWRlc2NyaXB0aW9uJywgTm9uZSwNCiAg ICAgICAgICJEZXNjcmlwdGlvbiBvZiB2ZW5kb3IiKSwNCiAgICAgICAgKCdw c2Ytb25seScsIE5vbmUsDQogICAgICAgICAiUHJvZHVjZSBqdXN0IHRoZSBw c2YgZmlsZSIpLA0KICAgICAgICAoJ3Byb2R1Y3QtdGFnJywgTm9uZSwNCiAg ICAgICAgICJOYW1lIG9mIHByb2R1Y3QiKSwNCiAgICAgICAgKCdwcm9kdWN0 LXRpdGxlJywgTm9uZSwNCiAgICAgICAgICJUaXRsZSBvZiBwcm9kdWN0Iiks DQogICAgICAgICgndmVyc2lvbicsIE5vbmUsDQogICAgICAgICAiUGFja2Fn ZSB2ZXJzaW9uIiksDQogICAgICAgICgncHJvZHVjdC1kZXNjcmlwdGlvbics IE5vbmUsDQogICAgICAgICAiRGVzY3JpcHRpb24gb2YgcHJvZHVjdCIpLA0K ICAgICAgICAoJ3Byb2R1Y3QtYXJjaGl0ZWN0dXJlJywgTm9uZSwNCiAgICAg ICAgICJNYWNoaW5lIGFyY2hpdGVjdHVyZSIpLA0KICAgICAgICAoJ3Byb2R1 Y3QtbWFjaGluZS10eXBlJywgTm9uZSwNCiAgICAgICAgICJUeXBlIG9mIGhh cmR3YXJlIiksDQogICAgICAgICgncHJvZHVjdC1vcy1yZWxlYXNlJywgTm9u ZSwNCiAgICAgICAgICJPcGVyYXRpbmcgc3lzdGVtIGxldmVsIiksDQogICAg ICAgICgncHJvZHV0LW9zLXZlcnNpb24nLCBOb25lLA0KICAgICAgICAgIk9w ZXJhdGluZyBzeXN0ZW0gdmVyc2lvbiIpLA0KICAgICAgICAoJ2ZpbGVzZXQt dGFnJywgTm9uZSwNCiAgICAgICAgICJOYW1lIG9mIGZpbGVzZXQiKSwNCiAg ICAgICAgKCdmaWxlc2V0LXJldmlzaW9uJywgTm9uZSwNCiAgICAgICAgICJS ZXYgbGV2ZWwgb2YgZmlsZXNldCIpLA0KICAgICAgICAoJ2ZpbGVzZXQtdGl0 bGUnLCBOb25lLA0KICAgICAgICAgIk5hbWUgb2YgZmlsZXNldCIpLA0KICAg ICAgICAoJ2ZpbGVzZXQtZGlyZWN0b3J5JywgTm9uZSwNCiAgICAgICAgICJE aXJlY3RvcnkgZm9yIG1vZHVsZSBmaWxlcyIpDQogICAgICAgXQ0KDQogICAg ZGVmIGluaXRpYWxpemVfb3B0aW9ucyAoc2VsZik6DQogICAgICAgIHNlbGYu bmFtZSA9IE5vbmUNCiAgICAgICAgc2VsZi52ZW5kb3JfdGFnID0gTm9uZQ0K ICAgICAgICBzZWxmLmJkaXN0X2Jhc2UgPSBOb25lDQogICAgICAgIHNlbGYu ZGlzdF9kaXIgPSBOb25lDQogICAgICAgIHNlbGYudmVuZG9yX3RpdGxlID0g Tm9uZQ0KICAgICAgICBzZWxmLnZlbmRvcl9kZXNjcmlwdGlvbiA9IE5vbmUN CiAgICAgICAgc2VsZi5wc2Zfb25seSA9IE5vbmUNCg0KICAgICAgICBzZWxm LnByb2R1Y3RfdGFnID0gTm9uZQ0KICAgICAgICBzZWxmLnByb2R1Y3RfdGl0 bGUgPSBOb25lDQogICAgICAgIHNlbGYucHJvZHVjdF9kZXNjcmlwdGlvbiA9 IE5vbmUNCiAgICAgICAgc2VsZi5jb3B5cmlnaHQgPSBOb25lDQogICAgICAg IHNlbGYucmVhZG1lID0gTm9uZQ0KICAgICAgICBzZWxmLm9zX25hbWUgPSBO b25lDQogICAgICAgIHNlbGYudmVyc2lvbiA9IE5vbmUNCiAgICAgICAgc2Vs Zi5wcm9kdWN0X2FyY2hpdGVjdHVyZSA9IE5vbmUNCiAgICAgICAgc2VsZi5w cm9kdWN0X21hY2hpbmVfdHlwZSA9IE5vbmUNCiAgICAgICAgc2VsZi5wcm9k dWN0X29zX3JlbGVhc2UgPSBOb25lDQogICAgICAgIHNlbGYucHJvZHVjdF9v c192ZXJzaW9uID0gTm9uZQ0KICAgICAgICBzZWxmLmZpbGVzZXRfdGFnID0g Tm9uZQ0KICAgICAgICBzZWxmLmZpbGVzZXRfcmV2aXNpb24gPSBOb25lDQog ICAgICAgIHNlbGYuZmlsZXNldF90aXRsZSA9IE5vbmUNCiAgICAgICAgc2Vs Zi5maWxlc2V0X2RpcmVjdG9yeSA9IE5vbmUNCg0KICAgICMgaW5pdGlhbGl6 ZV9vcHRpb25zKCkNCg0KDQogICAgZGVmIGZpbmFsaXplX29wdGlvbnMgKHNl bGYpOg0KICAgICAgICBzZWxmLnNldF91bmRlZmluZWRfb3B0aW9ucygnYmRp c3QnLCAoJ2JkaXN0X2Jhc2UnLCAnYmRpc3RfYmFzZScpKQ0KICAgICAgICBz ZWxmLnNldF91bmRlZmluZWRfb3B0aW9ucygnYmRpc3QnLCAoJ2Rpc3RfZGly JywgJ2Rpc3RfZGlyJykpDQogICAgICAgIHNlbGYuZmluYWxpemVfcGFja2Fn ZV9kYXRhKCkNCg0KICAgICMgZmluYWxpemVfb3B0aW9ucygpDQoNCiAgICBk ZWYgZmluYWxpemVfcGFja2FnZV9kYXRhIChzZWxmKToNCiAgICAgICAgc2Vs Zi5lbnN1cmVfc3RyaW5nKCduYW1lJyxzZWxmLmRpc3RyaWJ1dGlvbi5nZXRf bmFtZSgpKSwNCiAgICAgICAgc2VsZi5lbnN1cmVfc3RyaW5nKCd2ZW5kb3Jf dGFnJyxzZWxmLmRpc3RyaWJ1dGlvbi5nZXRfYXV0aG9yKCkpDQogICAgICAg IHNlbGYuZW5zdXJlX3N0cmluZygndmVuZG9yX3RpdGxlJyxzZWxmLmRpc3Ry aWJ1dGlvbi5nZXRfYXV0aG9yX2VtYWlsKCkpDQogICAgICAgIHNlbGYuZW5z dXJlX3N0cmluZygndmVuZG9yX2Rlc2NyaXB0aW9uJyxzZWxmLmRpc3RyaWJ1 dGlvbi5nZXRfYXV0aG9yKCkpDQogICAgICAgIHNlbGYuZW5zdXJlX3N0cmlu ZygncHJvZHVjdF90YWcnLHNlbGYubmFtZSkNCiAgICAgICAgc2VsZi5lbnN1 cmVfc3RyaW5nKCdwcm9kdWN0X3RpdGxlJyxzZWxmLmRpc3RyaWJ1dGlvbi5n ZXRfZGVzY3JpcHRpb24oKSkNCiAgICAgICAgc2VsZi5lbnN1cmVfc3RyaW5n KCdvc19uYW1lJywnSFAtVVgnKQ0KICAgICAgICBzZWxmLmVuc3VyZV9zdHJp bmcoJ3ZlcnNpb24nLHNlbGYuZGlzdHJpYnV0aW9uLmdldF92ZXJzaW9uKCkp DQogICAgICAgIHNlbGYuZW5zdXJlX3N0cmluZygncHJvZHVjdF9hcmNoaXRl Y3R1cmUnLCIqIikNCiAgICAgICAgc2VsZi5lbnN1cmVfc3RyaW5nKCdwcm9k dWN0X21hY2hpbmVfdHlwZScsIioiKQ0KICAgICAgICBzZWxmLmVuc3VyZV9z dHJpbmcoJ3Byb2R1Y3Rfb3NfcmVsZWFzZScsIioiKQ0KICAgICAgICBzZWxm LmVuc3VyZV9zdHJpbmcoJ3Byb2R1Y3Rfb3NfdmVyc2lvbicsIioiKQ0KICAg ICAgICBzZWxmLmVuc3VyZV9zdHJpbmcoJ2ZpbGVzZXRfdGFnJywiRklMRVMi KQ0KICAgICAgICBzZWxmLmVuc3VyZV9zdHJpbmcoJ2ZpbGVzZXRfcmV2aXNp b24nLHNlbGYudmVyc2lvbikNCiAgICAgICAgc2VsZi5lbnN1cmVfc3RyaW5n KCdmaWxlc2V0X3RpdGxlJyxzZWxmLm5hbWUpDQogICAgICAgIHNpdGU9Tm9u ZQ0KICAgICAgICBmb3IgaSBpbiAgc3lzLnBhdGg6DQogICAgICAgICAgICBp ZiBpWy0xMzpdPT0ic2l0ZS1wYWNrYWdlcyI6DQogICAgICAgICAgICAgICAg c2l0ZT1pDQogICAgICAgICAgICAgICAgYnJlYWsNCiAgICAgICAgaWYgbm90 IHNpdGU6DQogICAgICAgICAgICByYWlzZSBBdHRyaWJ1dGVFcnJvciwgIkNh bm5vdCBmaWxlIHNpdGUtcGFja2FnZXMiDQogICAgICAgIHNlbGYuc2l0ZT1z aXRlDQogICAgICAgIHNlbGYuZW5zdXJlX3N0cmluZygnZmlsZXNldF9kaXJl Y3RvcnknLHNlbGYubmFtZSkNCiAgICAgICAgI2lmIHNpdGU6DQogICAgICAg ICAgICAjc2VsZi5lbnN1cmVfc3RyaW5nKCdmaWxlc2V0X2RpcmVjdG9yeScs c2l0ZSkNCiAgICAgICAgI2Vsc2U6DQogICAgICAgICAgICAjcmFpc2UgQXR0 cmlidXRlRXJyb3IsICJmaWxlc2V0X2RpcmVjdG9yeSBpcyBub3Qgc3BlY2lm aWVkIg0KICAgICAgICBzZWxmLnBrZ19kaXIgPSBvcy5wYXRoLmpvaW4oc2Vs Zi5iZGlzdF9iYXNlLCAiZGVwb3QiKQ0KDQogICAgIyBmaW5hbGl6ZV9wYWNr YWdlX2RhdGEgKCkNCg0KDQogICAgZGVmIHJ1biAoc2VsZik6DQoNCiAgICAg ICAgaWYgREVCVUc6DQogICAgICAgICAgICBwcmludCAiYmVmb3JlIF9nZXRf cGFja2FnZV9kYXRhKCk6Ig0KICAgICAgICAgICAgcHJpbnQgInZlbmRvciA9 Iiwgc2VsZi52ZW5kb3INCiAgICAgICAgICAgIHByaW50ICJwYWNrYWdlciA9 Iiwgc2VsZi5wYWNrYWdlcg0KDQogICAgICAgICMgbWFrZSBkaXJlY3Rvcmll cw0KICAgICAgICBzZWxmLm1rcGF0aChzZWxmLnBrZ19kaXIpDQoNCiAgICAg ICAgIyBTcGVjIGZpbGUgZ29lcyBpbnRvICdkaXN0X2RpcicgaWYgJy0tcHNm LW9ubHkgc3BlY2lmaWVkJywNCiAgICAgICAgIyBidWlsZC9iZGlzdC48cGxh dD4vcGtndG9vbCBvdGhlcndpc2UuDQogICAgICAgIHBzZl9wYXRoID0gb3Mu cGF0aC5qb2luKHNlbGYucGtnX2RpciwgDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAiJXMucHNmIiAlIHNlbGYuZGlzdHJpYnV0aW9uLmdl dF9uYW1lKCkpDQogICAgICAgICMgYnVpbGQgcGFja2FnZQ0KICAgICAgICBz ZWxmLmFubm91bmNlKCdCdWlsZGluZyBwYWNrYWdlJykNCiAgICAgICAgc2Vs Zi5zcGF3bihzdHJpbmcuc3BsaXQoIiVzL2Jpbi9weXRob24gc2V0dXAucHkg YnVpbGQiICUgc3lzLmV4ZWNfcHJlZml4KSkNCiAgICAgICAgc2VsZi5hbm5v dW5jZSgnQ3JlYXRpbmcgcHNmIGZpbGUnKQ0KICAgICAgICBzZWxmLmV4ZWN1 dGUod3JpdGVfZmlsZSwNCiAgICAgICAgICAgICAgICAgICAgIChwc2ZfcGF0 aCwNCiAgICAgICAgICAgICAgICAgICAgICBzZWxmLl9tYWtlX2luZm9fZmls ZSgpKSwNCiAgICAgICAgICAgICAgICAgICAgICJ3cml0aW5nICclcyciICUg cHNmX3BhdGgpDQogICAgICAgIGlmIHNlbGYucHNmX29ubHk6ICMgc3RvcCBp ZiByZXF1ZXN0ZWQNCiAgICAgICAgICAgIHJldHVybg0KICAgICAgICAjc2Vs Zi5hbm5vdW5jZSgnQ3JlYXRpbmcgcHJvdG90eXBlIGZpbGUnKQ0KICAgICAg ICAjcHNmX3BhdGggPSBvcy5wYXRoLmpvaW4oc2VsZi5wa2dfZGlyLCAicHJv dG90eXBlIikNCiAgICAgICAgI3NlbGYuZXhlY3V0ZSh3cml0ZV9maWxlLA0K ICAgICAgICAgICAgICAgICAgICAgIyhwc2ZfcGF0aCwNCiAgICAgICAgICAg ICAgICAgICAgICAjc2VsZi5fbWFrZV9wcm90b3R5cGUoKSksDQogICAgICAg ICAgICAgICAgICAgICAjIndyaXRpbmcgJyVzJyIgJSBwc2ZfcGF0aCkNCg0K ICAgICAgICAjc2VsZi5hbm5vdW5jZSgnQ3JlYXRpbmcgcmVsb2NhdGlvbiBy ZXF1ZXN0IHNjcmlwdCcpDQogICAgICAgICNyZXFfcGF0aCA9IG9zLnBhdGgu am9pbihzZWxmLnBrZ19kaXIsICJyZXF1ZXN0IikNCiAgICAgICAgI3NlbGYu ZXhlY3V0ZSh3cml0ZV9maWxlLChyZXFfcGF0aCxzdHJpbmcuc3BsaXQoUkVR LCJcMDEyIikpLA0KICAgICAgICAgICAgIyJ3cml0aW5nICclcyciICUgcmVx X3BhdGgpDQoNCiAgICAgICAgI2lmIHNlbGYucHNmX29ubHk6ICMgc3RvcCBp ZiByZXF1ZXN0ZWQNCiAgICAgICAgICAgICNyZXR1cm4NCg0KDQogICAgICAg IHNlbGYuYW5ub3VuY2UoJ0NyZWF0aW5nIHBhY2thZ2UnKQ0KICAgICAgICBz cGF3bl9jbWQgPSBbJ3N3cGFja2FnZScsICctcyddDQogICAgICAgIHNwYXdu X2NtZC5hcHBlbmQocHNmX3BhdGgpDQogICAgICAgIHNwYXduX2NtZC5hcHBl bmQoJy14JykNCiAgICAgICAgc3Bhd25fY21kLmFwcGVuZCgndGFyZ2V0X3R5 cGU9dGFwZScpDQogICAgICAgIHNwYXduX2NtZC5hcHBlbmQoJ0AnKQ0KICAg ICAgICBzcGF3bl9jbWQuYXBwZW5kKHNlbGYucGtnX2RpcisiLyIrc2VsZi5u YW1lKyctJytzZWxmLnZlcnNpb24rJy5kZXBvdCcpDQogICAgICAgIHNlbGYu c3Bhd24oc3Bhd25fY21kKQ0KDQogICAgICAgICMgWFhYIHRoaXMgaXMgYSBu YXN0eSBoYWNrIC0tIHdlIHJlYWxseSBzaG91bGQgaGF2ZSBhIHByb3BlciB3 YXkgdG8NCiAgICAgICAgIyBmaW5kIG91dCB0aGUgbmFtZXMgb2YgdGhlIFJQ TSBmaWxlcyBjcmVhdGVkOyBhbHNvLCB0aGlzIGFzc3VtZXMNCiAgICAgICAg IyB0aGF0IFJQTSBjcmVhdGVzIGV4YWN0bHkgb25lIHNvdXJjZSBhbmQgb25l IGJpbmFyeSBSUE0uDQogICAgIyBydW4oKQ0KDQogIA0KICAgIGRlZiBfbWFr ZV9pbmZvX2ZpbGUoc2VsZik6DQogICAgICAgICMgR2VuZXJhdGUgYSBwc2Yg ZmlsZSBhbmQgcmV0dXJuIGl0IGFzIGxpc3Qgb2Ygc3RyaW5ncyAob25lIHBl ciBsaW5lKS4NCiAgICAgICAgIyBkZWZpbml0aW9ucyBhbmQgaGVhZGVycw0K ICAgICAgICBwc2ZfZmlsZSA9IFsNCiAgICAgICAgICAgICd2ZW5kb3InLCAg ICAgICAgICAgICAgICMgVmVuZG9yIGluZm9ybWF0aW9uDQogICAgICAgICAg ICAnICAgIHRhZyAgICAgICAgICAgICAgICAlcycgJSBzdHJpbmcucmVwbGFj ZShzZWxmLnZlbmRvcl90YWcsIiAiLCJfIiksDQogICAgICAgICAgICAnICAg IHRpdGxlICAgICAgICAgICAgICAlcycgJSBzZWxmLnZlbmRvcl90aXRsZSwN CiAgICAgICAgICAgICcgICAgZGVzY3JpcHRpb24gICAgICAgICVzJyAlIHNl bGYudmVuZG9yX2Rlc2NyaXB0aW9uLA0KICAgICAgICAgICAgJ2VuZCcsICAg ICAgICAgICAgICAgICAgIyBlbmQgb2YgdmVuZG9yDQogICAgICAgICAgICAn cHJvZHVjdCcsICAgICAgICAgICAgICAjIFByb2R1Y3QgaW5mb3JtYXRpb24N CiAgICAgICAgICAgICcgICAgdGFnICAgICAgICAgICAgICAgICVzJyAlIHNl bGYucHJvZHVjdF90YWcsDQogICAgICAgICAgICAnICAgIHRpdGxlICAgICAg ICAgICAgICAlcycgJSBzZWxmLnByb2R1Y3RfdGl0bGUsDQogICAgICAgICAg ICAnICAgIHJldmlzaW9uICAgICAgICAgICAlcycgJSBzZWxmLnZlcnNpb24s DQogICAgICAgICAgICAjJyAgICBhcmNoaXRlY3R1cmUgICAgICAgJXMnICUg c2VsZi5wcm9kdWN0X2FyY2hpdGVjdHVyZSwNCiAgICAgICAgICAgICcgICAg bWFjaGluZV90eXBlICAgICAgICVzJyAlIHNlbGYucHJvZHVjdF9tYWNoaW5l X3R5cGUsDQogICAgICAgICAgICAnICAgIG9zX25hbWUgICAgICAgICAgICAl cycgJSBzZWxmLm9zX25hbWUsDQogICAgICAgICAgICAnICAgIG9zX3JlbGVh c2UgICAgICAgICAlcycgJSBzZWxmLnByb2R1Y3Rfb3NfcmVsZWFzZSwNCiAg ICAgICAgICAgICcgICAgZGlyZWN0b3J5ICAgICAgICAgICVzJyAlIHNlbGYu c2l0ZSwNCiAgICAgICAgICAgICcgICAgaXNfbG9jYXRhYmxlICAgICAgIHRy dWUnLA0KICAgICAgICAgICAgXQ0KICAgICAgICBpZiBzZWxmLnByb2R1Y3Rf ZGVzY3JpcHRpb246DQogICAgICAgICAgICBwc2ZfZmlsZS5leHRlbmQoW3Nl bGYucHJvZHVjdF9kZXNjcmlwdGlvbl0pDQogICAgICAgIGlmIHNlbGYuY29w eXJpZ2h0Og0KICAgICAgICAgICAgIyBYWCBtYWtlIGEgY29weXJpZ2h0IGZp bGUgWFhYDQogICAgICAgICAgICBwc2ZfZmlsZS5leHRlbmQoWycgICAgY29w eXJpZ2h0ICAgICAgICAgPGNvcHlyaWdodF9maWxlJ10pDQogICAgICAgIGlm IHNlbGYucmVhZG1lOg0KICAgICAgICAgICAgIyBYWCBtYWtlIGEgcmVhZG1l IGZpbGUgWFhYDQogICAgICAgICAgICBwc2ZfZmlsZS5leHRlbmQoWycgICAg cmVhZG1lICAgICAgICAgICAgPHJlYWRtZV9maWxlJ10pDQoNCiAgICAgICAg cHNmX2ZpbGUuZXh0ZW5kKFsnICAgIGZpbGVzZXQnXSkgICAgIyBzdGFydCBm aWxlc2V0DQogICAgICAgIHBsYXRsaWI9c2VsZi5nZXRfZmluYWxpemVkX2Nv bW1hbmQoJ2J1aWxkJykuYnVpbGRfcGxhdGxpYg0KICAgICAgICBwc2ZfZmls ZS5leHRlbmQoWw0KICAgICAgICAgICAgJyAgICAgICAgdGFnICAgICAgICAg ICAgJXMnICUgc2VsZi5maWxlc2V0X3RhZywNCiAgICAgICAgICAgICcgICAg ICAgIHRpdGxlICAgICAgICAgICVzJyAlIHNlbGYuZmlsZXNldF90aXRsZSwN CiAgICAgICAgICAgICcgICAgICAgIHJldmlzaW9uICAgICAgICVzJyAlIHNl bGYuZmlsZXNldF9yZXZpc2lvbiwNCiAgICAgICAgICAgICcgICAgICAgIGRp cmVjdG9yeSAgICAgICVzLyVzPSVzLyVzJyAlIChwbGF0bGliLHNlbGYubmFt ZSxzZWxmLnNpdGUsc2VsZi5uYW1lKSwNCiAgICAgICAgICAgICcgICAgICAg IGZpbGUgICAgICAgICAgIConDQogICAgICAgICAgICBdKQ0KICAgICAgICBw c2ZfZmlsZS5leHRlbmQoWycgICAgZW5kJ10pICAgICAgICAjIGVuZCBvZiBm aWxlc2V0DQogICAgICAgIHBzZl9maWxlLmV4dGVuZChbJ2VuZCddKSAgICAj IGVuZCBvZiBwcm9kdWN0DQogICAgICAgICAgICAgICANCiMgWFhYIGFkZCBm aWxlc2V0IGluZm9ybWF0aW9uDQogICAgICAgIA0KDQogICAgICAgIHJldHVy biBwc2ZfZmlsZQ0KDQogICAgIyBfbWFrZV9pbmZvX2ZpbGUgKCkNCg0KDQoj IGNsYXNzIGJkaXN0X3JwbQ0K ---656673009-1108563448-967240568=:31668-- From gward@python.net Sat Aug 26 02:17:40 2000 From: gward@python.net (Greg Ward) Date: Fri, 25 Aug 2000 21:17:40 -0400 Subject: [Distutils] Opening up backdoors to 'setup()' Message-ID: <20000825211740.A625@beelzebub> Hi all -- in the last couple of weeks, two people (Amos Latteier & Paul Dubois, to be specific) have asked about better programmatic access to the 'setup()' function. The two cases are sort of opposite but closely related: * Amos wants a "dist-bot" that pulls Python module distributions off the net, unpacks them, and extracts their meta-data. Running "python setup.py --name --version ..." through a pipe is an option, but it would be much nicer to import (or execfile) setup.py and query it programmatically. * Paul wants to run a setup script with specific arguments from Python code. Again, he could just spawn "python setup.py ...", or hack sys.argv and call 'setup()' directly. But those are both kind of gross. In both cases, what's needed is a bit of "backdoor" access that skirts around the usual convention: setup script encodes useful information in keyword arguments, which are then passed into the guts of the Distutils by calling 'setup()'. I think Paul's backdoor is easiest: add a special keyword argument, 'argv', to 'setup()', which overrides sys.argv. Or a possible variation on this: call it 'args', and have it override just sys.argv[1:]. Subtle distinction, but important. I'm not sure offhand which is better, but I think it would be excessive to support both. For Amos, I can see a couple ways to do it. I think the cleanest is a global variable that tells 'setup()', when to stop. (It can't be another keyword arg, because you're just execfile'ing any old setup script: you can't get in there and add arguments to the 'setup()' call.) The default, of course, would be to do everything: create the Distribution instance, parse the config files and command line, and run all commands (modulo help options, of course). But you could stop after initialization (Distribution object with just the info from the setup script), after config-file parsing, or after command-line parsing. Of course, there would be a function to set the global variable, so you might do this: distutils.core.stop_after('init') execfile("foo-1.0/setup.py") But that's only half the story: you really want to get your hands on the Distribution instance that 'setup()' created. The obvious answer is another global variable, and another function to read it. Yuck. Or rather, getting yucky; not bad enough to out-and-out refuse it, but I'd like to know if anyone has a better idea before I go and implement this. So: any better ideas out there? Does anyone think these backdoors are useful enough to slip in, or should we make Paul and Amos live with whatever gross hacks they're using currently? (I hate gross hacks.) Greg -- Greg Ward - programmer-at-big gward@python.net http://starship.python.net/~gward/ ... I don't like FRANK SINATRA or his CHILDREN. From gward@python.net Sat Aug 26 02:45:39 2000 From: gward@python.net (Greg Ward) Date: Fri, 25 Aug 2000 21:45:39 -0400 Subject: [Distutils] Was I asleep? In-Reply-To: ; from mwa@gate.net on Fri, Aug 25, 2000 at 11:15:39AM -0400 References: <20000824224529.A1044@beelzebub> Message-ID: <20000825214539.A586@beelzebub> 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. From gward@python.net Sat Aug 26 03:39:27 2000 From: gward@python.net (Greg Ward) Date: Fri, 25 Aug 2000 22:39:27 -0400 Subject: [Distutils] New bdist_wininst In-Reply-To: <00a901c00ea9$99eafcf0$4500a8c0@thomasnb>; from thomas.heller@ion-tof.com on Fri, Aug 25, 2000 at 05:31:55PM +0200 References: <00a901c00ea9$99eafcf0$4500a8c0@thomasnb> Message-ID: <20000825223927.B586@beelzebub> On 25 August 2000, Thomas Heller said: > This is a new release of the distutils windows installer. > The known bug (bogus error message when an empty file is > extracted) is fixed. Great! Just checked it all in. Please "cvs update" and make sure I got everything. I'll also be putting out a new code snapshot in a couple of minutes. > Greg, the zip-file contains complete files, not diffs. It also contained a bunch of other cruft -- (empty) CVS directories, and bits and pieces of the Distutils source tree. Please be careful to just include your code -- misc/* and distutils/command/bdist_wininst.py. Thanks... Greg -- Greg Ward - just another /P(erl|ython)/ hacker gward@python.net http://starship.python.net/~gward/ A man wrapped up in himself makes a very small package. From gward@python.net Sat Aug 26 04:02:48 2000 From: gward@python.net (Greg Ward) Date: Fri, 25 Aug 2000 23:02:48 -0400 Subject: [Distutils] New code snapshot Message-ID: <20000825230248.J594@beelzebub> Hi all -- I've just created a new code snapshot; this fixes a rather embarassing bug, and also includes Thomas' latest version of the Windows installer code. Windows folks -- please try this snapshot to build PyXML and/or NumPy under Windows! The bug affects any module distribution using "old-style" extension descriptions, ie. the big ugly list-of-dicts-of-tuples instead of Extension instances, and only under Windows. And of course, give bdist_wininst a good exercise. This will become Distutils 0.9.2 if I don't hear any loud squawks. The URL for snapshots is back to python.org: http://www.python.org/sigs/distutils-sig/download.html#snapshot Enjoy! Greg -- Greg Ward - Unix geek gward@python.net http://starship.python.net/~gward/ Animals can be driven crazy by placing too many in too small a pen. Homo sapiens is the only animal that voluntarily does this to himself. From fdrake@beopen.com Sat Aug 26 04:04:09 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Fri, 25 Aug 2000 23:04:09 -0400 (EDT) Subject: [Distutils] Was I asleep? In-Reply-To: <20000825214539.A586@beelzebub> References: <20000824224529.A1044@beelzebub> <20000825214539.A586@beelzebub> Message-ID: <14759.13225.240113.787424@cj42289-a.reston1.va.home.com> 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. BeOpen PythonLabs Team Member From dubois@users.sourceforge.net Sat Aug 26 05:08:18 2000 From: dubois@users.sourceforge.net (Paul F. Dubois) Date: Fri, 25 Aug 2000 21:08:18 -0700 Subject: [Distutils] RE: Opening up backdoors to 'setup()' In-Reply-To: <20000825211740.A625@beelzebub> Message-ID: My not wanting to run "python setup.py ..." in a pipe has more than just persnickity wishes for elegance behind it. (a) I would have to write setup.py somewhere, with all the usual annoyances connected with creating a temporary file; not serious but annoying. (b) I don't know WHICH python will get run by the above statement. In particular I might not get the one interpreting me now; again, solvable but annoyingly so. In my case this would be a VERY bad error, as I would install something into the wrong Python. From gward@python.net Sun Aug 27 02:57:42 2000 From: gward@python.net (Greg Ward) Date: Sat, 26 Aug 2000 21:57:42 -0400 Subject: [Distutils] bdist_pkgtool attempt In-Reply-To: ; from mwa@gate.net on Thu, Aug 24, 2000 at 10:23:22PM -0400 References: Message-ID: <20000826215742.A982@beelzebub> On 24 August 2000, Mark W. Alexander said: > As a first pass, it takes somewhat of a sledgehammer approach, > but it does work for at least a simple pure-python module. "Sledgehammer" is one way to put it. It might be a more convincing translation if you finished the s/rpm/pkgtool/ job. ;-) The major problems I see with this adaptation are: * reuse by cut and paste doesn't count. I'm going to stop accepting patches that just copy an existing module and hack into shape... *now*. If you want to implement command bdist_foo, and it's very similar to bdist_bar, then refactor first! * it shouldn't be the job of a shell script generated by bdist_pkgtool.py to go from sys.prefix to /lib/pythonx.y/site-packages; that is already done by the 'install' command when run with a certain prefix. Or you can use the 'get_python_lib()' function from distutils.sysconfig. Two places with this logic are enough... Oh, and of course I have a burning and irrational hatred of Solaris which, unlike my burning and irrational hatred of Windows, stems from actual use. So the idea of lifting a finger to help Sun, even as indirectly as this, really sticks in my craw. >grin< Greg -- Greg Ward - Unix nerd gward@python.net http://starship.python.net/~gward/ Pointers are Arrays; Code is Data; Time is Money From mwa@gate.net Mon Aug 28 03:47:36 2000 From: mwa@gate.net (Mark W. Alexander) Date: Sun, 27 Aug 2000 22:47:36 -0400 (EDT) Subject: [Distutils] bdist_pkgtool attempt In-Reply-To: <20000826215742.A982@beelzebub> Message-ID: On Sat, 26 Aug 2000, Greg Ward wrote: > On 24 August 2000, Mark W. Alexander said: > > As a first pass, it takes somewhat of a sledgehammer approach, > > but it does work for at least a simple pure-python module. > > "Sledgehammer" is one way to put it. It might be a more convincing > translation if you finished the s/rpm/pkgtool/ job. ;-) Told ya so! I was only trying to convince myself that I could do it without disrupting my production schedule. It's a testimony to Mr. Gebel's rpm module (sp?) that I got it to work without knowing poot about distutils. And by finish you mean "finish destroying Mr. Gebel's code"? I don't think so....When I get back to it, it will be to do it right. > The major problems I see with this adaptation are: > > * reuse by cut and paste doesn't count. I'm going to stop > accepting patches that just copy an existing module and > hack into shape... *now*. If you want to implement > command bdist_foo, and it's very similar to bdist_bar, > then refactor first! No problem. For me, this was jump in, get my feet wet and see if I could make it work. bdist_sdux is better in that at least I understood the steps. My first priority is to package a bunch of local mods, and this has got that licked. I'm more than happy to take advice on the distutils way and improve it as time permits. > * it shouldn't be the job of a shell script generated by > bdist_pkgtool.py to go from sys.prefix to > /lib/pythonx.y/site-packages; that is already > done by the 'install' command when run with a certain > prefix. Or you can use the 'get_python_lib()' function > from distutils.sysconfig. Two places with this > logic are enough... The problem with that is that you either A) get the info at build time or B) run distutils to do the actual binary install on the target. In my case, A is not a reliable indicator of where python is installed on the target machine. B loses the advantage of the native packager in that the file inventory is not registered. The script you're refering to is created to be placed into the package to be run at "request" time, where packages can ask the admin what to do. Instead of asking, the script figures it out by itself. This means that with one pkgadd, I can install any number of modules with no further intervention. Anyway, Using the standard package install scripts to find python and automatically relocate is best of several poor solutions. If you've got a better idea, I'll take it. > Oh, and of course I have a burning and irrational hatred of Solaris > which, unlike my burning and irrational hatred of Windows, stems from > actual use. So the idea of lifting a finger to help Sun, even as > indirectly as this, really sticks in my craw. >grin< There's nothing irrational about it;-) But, distutils really needs to support it, along with the other big unnamed ones. Having to work on Solaris and HP are bad enough, but to do so without Python is simply cruel and unusual punishment. And, since most my sysadmin scripts are in Python, being able to effortlessly maintain package modules for both is why I need distutils. If it was just rpm, I could manage without. So...don't help Sun, help me and others like me. First, forget this one, I'll clean it up later. Give me constuctive criticism on bdist_sdux (which has a completely different relocation nightmare) and I'll retrofit the advice to pgktool. At the very least, point me to some description of the inputs to the bdist_XXX modules and the setup and use of bdist module options. I mean, if you want quality bdist_modules, you need to give quality instructions. And I DON'T mean now as in "drop everything, this is important, I gotta get it done", either, cause the time I have to devote is pretty slim anyway. That's the biggest reason I wanted to post something, so that maybe someone else would be interested. That, and I think I promised to do it sometime last year(?)... Unfortunately, from what I've seen on this list I'm the lonely Solaris/HP repairman. So, what I did will hold me for a while. And finally, the reason I'm suddenly pushed to get things packaged and out the door is because I've finally got some help to start dumping on^W^W training. I would like to note for the record, that without distutils I'd have spent at least days, probably weeks, getting things organized, packaged, and prepared for moving to 1.6 on all my platforms. Your work is really paying off, and it is most sincerely appreciated! Mark Alexander mwa@gate.net From thomas.heller@ion-tof.com Mon Aug 28 14:03:20 2000 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Mon, 28 Aug 2000 15:03:20 +0200 Subject: [Distutils] New bdist_wininst References: <00a901c00ea9$99eafcf0$4500a8c0@thomasnb> <20000825223927.B586@beelzebub> Message-ID: <02f401c010f0$56fa8cf0$4500a8c0@thomasnb> > On 25 August 2000, Thomas Heller said: > > This is a new release of the distutils windows installer. > > The known bug (bogus error message when an empty file is > > extracted) is fixed. > > Great! Just checked it all in. Please "cvs update" and make sure I got > everything. I'll also be putting out a new code snapshot in a couple of > minutes. Thanks. Everything seems ok. > > > Greg, the zip-file contains complete files, not diffs. > > It also contained a bunch of other cruft -- (empty) CVS directories, > and bits and pieces of the Distutils source tree. Please be careful to > just include your code -- misc/* and distutils/command/bdist_wininst.py. My fault. I created the zip-file with WinZip by zipping the whole distutils source tree, and then deleted everything not related to bdist_wininst. Didn't know (and winzip didn't show it) that all this crap was still included. BTW, what do you think of the changes I made, especially this one: - The target-compile and target-optimize flags of bdist_wininst are gone. It is no longer possible to compile the python files during installation. Thomas From amos@digicool.com Mon Aug 28 18:29:27 2000 From: amos@digicool.com (Amos Latteier) Date: Mon, 28 Aug 2000 10:29:27 -0700 Subject: [Distutils] Re: Opening up backdoors to 'setup()' References: <20000825211740.A625@beelzebub> Message-ID: <39AAA177.5C17DC14@digicool.com> Greg Ward wrote: > > Hi all -- > > in the last couple of weeks, two people (Amos Latteier & Paul Dubois, to > be specific) have asked about better programmatic access to the > 'setup()' function. The two cases are sort of opposite but closely > related: ... > In both cases, what's needed is a bit of "backdoor" access that skirts > around the usual convention: setup script encodes useful information in > keyword arguments, which are then passed into the guts of the Distutils > by calling 'setup()'. I've thought about this a little. It seems to me that the basic desire is to be able to run setup from python, not the command line. I think we could accommodate this with something like this distutils.core.run_setup(file, commands) This would return the results of running the named setup file with the given commands. I don't really care about how you spell the file and the commands. For example, perhaps file should be an open file object rather than a path, and maybe commands is a list of strings instead of a string. Whatever ;-) This facility seems relatively easy to understand and implement. And I believe that it accomplishes most of what Paul and I want. The remaining problem is that most commands don't return anything, they just print information. This means that when you run a command on a setup file from python, it won't be easy to figure out whether it worked or not. I haven't looked at the commands very much but perhaps they could be retrofitted to return something in addition to printing information. Otherwise there could be new commands that were meant to be called from python. Or failing that you could capture the stdout and try to deduce from there how things went. In my case I'll probably write a new command called something like 'metadata' that doesn't do anything but return meta-data about the distribution. This would allow me to do something like this: meta_data=distutils.core.run_setup(open('foo-1.0.tgz'), 'metadata') which is what I want. -Amos -- Amos Latteier mailto:amos@digicool.com Digital Creations http://www.digicool.com From gward@python.net Tue Aug 29 02:31:43 2000 From: gward@python.net (Greg Ward) Date: Mon, 28 Aug 2000 21:31:43 -0400 Subject: [Distutils] bdist_pkgtool attempt In-Reply-To: ; from mwa@gate.net on Sun, Aug 27, 2000 at 10:47:36PM -0400 References: <20000826215742.A982@beelzebub> Message-ID: <20000828213143.A786@beelzebub> On 27 August 2000, Mark W. Alexander said: > And by finish you mean "finish destroying Mr. Gebel's code"? > I don't think so....When I get back to it, it will be to do > it right. [...] > No problem. For me, this was jump in, get my feet wet and see if > I could make it work. bdist_sdux is better in that at least I > understood the steps. My first priority is to package a bunch > of local mods, and this has got that licked. I'm more than happy > to take advice on the distutils way and improve it as time > permits. OK, good, one more budding Distutils hacker with feet wet. Excellent! Need all the help we can get. I will take a closer look at bdist_sdux; I was worried that it would be a hatchet job similar to bdist_pkgtool, and I hate reading cut 'n pasted code. But first, you have to tell me what "sdux" stands for. I keep mentally dropping the "d"... > The problem with that is that you either A) get the info at > build time or B) run distutils to do the actual binary install > on the target. In my case, A is not a reliable indicator of > where python is installed on the target machine. B loses the > advantage of the native packager in that the file inventory > is not registered. Ahh, gotcha. Idea: don't use Distutils to do the install, but do take advantage of it for the install-time scripts. Or rather, take advantage of Python and assume that the Distutils are installed on the target machine. Then you can do from distutils.sysconfig import get_python_inc libdir = get_python_lib(plat_specific=1) ... instead of that nasty shell trickery-pokery. Of course, you may have a slight chicken/egg problem in getting the Distutils installed, if these target platforms are running 1.5.2. Umm, left as an exercise for the reader... ;-) Note that the other Unix bdist_* commands (dumb and rpm, at this date) don't do anything smart about install location. They just mimic whatever the structure on the build host was. This is just fine for bdist_rpm; if you're building and RPM for Red Hat 6.2, you should be doing so with the Red Hat 6.2 Python interpreter. For bdist_dumb, it's just laziness on my part -- and the only real way to deal with the potential prefix/exec-prefix distinction. General principle: when writing a bdist_* command, I won't bite your head off if you assume that the target system's Python installation is the same as the build system's. At least for Unix: I think on Windows, it's important to adjust to the user's preferred location for Python. Probably the same for Mac OS... someday. ;-) > > Oh, and of course I have a burning and irrational hatred of Solaris > > which, unlike my burning and irrational hatred of Windows, stems from > > actual use. So the idea of lifting a finger to help Sun, even as > > indirectly as this, really sticks in my craw. >grin< > > There's nothing irrational about it;-) But, distutils really needs > to support it, along with the other big unnamed ones. Having > to work on Solaris and HP are bad enough, but to do so without > Python is simply cruel and unusual punishment. Yeah, you're right; no point in punishing the poor hapless souls stuck with the evil spawn of Sun. My sympathies. > So...don't help Sun, help me and others like me. First, forget > this one, I'll clean it up later. Give me constuctive > criticism on bdist_sdux (which has a completely different > relocation nightmare) and I'll retrofit the advice to > pgktool. At the very least, point me to some description > of the inputs to the bdist_XXX modules and the setup > and use of bdist module options. I mean, if you want > quality bdist_modules, you need to give quality > instructions. What, the source code isn't documentation enough? ;-) Well, Fred has been pushing me to write some "Distutils Internals" documentation. Back to the docs... Greg -- Greg Ward - Unix geek gward@python.net http://starship.python.net/~gward/ Very few profundities can be expressed in less than 80 characters. From gward@python.net Tue Aug 29 02:41:31 2000 From: gward@python.net (Greg Ward) Date: Mon, 28 Aug 2000 21:41:31 -0400 Subject: [Distutils] New bdist_wininst In-Reply-To: <02f401c010f0$56fa8cf0$4500a8c0@thomasnb>; from thomas.heller@ion-tof.com on Mon, Aug 28, 2000 at 03:03:20PM +0200 References: <00a901c00ea9$99eafcf0$4500a8c0@thomasnb> <20000825223927.B586@beelzebub> <02f401c010f0$56fa8cf0$4500a8c0@thomasnb> Message-ID: <20000828214131.B786@beelzebub> On 28 August 2000, Thomas Heller said: > My fault. I created the zip-file with WinZip by zipping the whole distutils > source tree, and then deleted everything not related to bdist_wininst. > Didn't know (and winzip didn't show it) that all this crap was still > included. Damn GUIs. I mean, a visual representation of what's in your computer is very nice, but only if it really is a complete representation! > BTW, what do you think of the changes I made, especially this one: > - The target-compile and target-optimize flags of bdist_wininst > are gone. It is no longer possible to compile the python > files during installation. I assume "installation" here means "final installation on the target host", in which case this seems fine to me. If this means that the Windows installer will now be roughly as big as the RPM, because it includes bytecode files, that doesn't bother me too much. Not as much as the "what could go wrong?" aspect to byte-compiling everything on the end-user's machine. ...hmmm, I just whipped up a wininst installer of the current code, and it doesn't have .pyc files in it. I don't see an option to compile at pseudo-install time, either. Are you just assuming that the normal compile-on-demand approach will work on the target machine? I thought NT had sensible permissions, so that ordinary users couldn't necessarily write to a "system" directory... is Python normally installed so that ordinary users can write to its library directory? Greg -- Greg Ward - Unix geek gward@python.net http://starship.python.net/~gward/ Think honk if you're a telepath. From gward@python.net Tue Aug 29 03:00:37 2000 From: gward@python.net (Greg Ward) Date: Mon, 28 Aug 2000 22:00:37 -0400 Subject: [Distutils] Re: Opening up backdoors to 'setup()' In-Reply-To: <39AAA177.5C17DC14@digicool.com>; from amos@digicool.com on Mon, Aug 28, 2000 at 10:29:27AM -0700 References: <20000825211740.A625@beelzebub> <39AAA177.5C17DC14@digicool.com> Message-ID: <20000828220037.C786@beelzebub> On 28 August 2000, Amos Latteier said: > I've thought about this a little. It seems to me that the basic desire > is to be able to run setup from python, not the command line. I think we > could accommodate this with something like this > > distutils.core.run_setup(file, commands) Hmmm, that does look cleaner for your needs than setting a global mode variable. (Of course, it might end up setting a global mode variable behind the scenes, but never mind that. If I break 'setup()' up into its constituent parts, or farm more of it off to the Distribution class, that shouldn't be necessary.) However, since I just went ahead and implemented 'script_name' and 'script_args' arguments to 'setup()', this is not needed for Paul's case. There's still a fundamental problem: the interesting info is encoded into keyword arguments, and the only (clean) way to get ahold of keyword arguments is to be the function that is called. That means that somewhere along the lines, the function 'distutils.core.setup()' is called with the keyword args in the setup script. To get our hands on what's passed to 'setup()', we either have to: * write a custom 'setup()' and replace the "real" 'distutils.core.setup()' with it (yuck) * modify the existing 'distutils.core.setup()' so that some external stimulus -- ie. something not passed in as keyword args from the setup script -- can influence its behaviour, eg. tell it to stop processing once it has "parsed" the keyword args and created a Distribution object. When I see "external stimulus" I think either "global variable" or "instance attribute"; since 'setup()' is a function, it has to be the former. Merde! > This would return the results of running the named setup file with the > given commands. I don't really care about how you spell the file and the > commands. For example, perhaps file should be an open file object rather > than a path, and maybe commands is a list of strings instead of a > string. Whatever ;-) What it returns depends on how far you want it to run. For you, it's enough to construct the Distribution object and return it (along with its slave DistributionMetadata object, of course). In some cases, you might want to do everything up to running the commands; other times, you actually want to run the commands. Again, this can't be specified in the keyword args in the setup script, which implies some external stimulus is needed. > The remaining problem is that most commands don't return anything, they > just print information. This means that when you run a command on a > setup file from python, it won't be easy to figure out whether it worked > or not. Well, the Distutils commands are all about side-effect; what could be more side-effect-ful than dumping a bunch of stuff in /usr/lib? ;-) However, they're not completely unresponsive: several commands (notably the build_* and install_* families) have 'get_inputs()' and/or 'get_outputs()' methods that return lists of filenames. This is a very informal, not-widely-implemented interface -- ie. it gets implemented when it's needed. They're essential to support the 'bdist_*' commands. Generally, you need to actually run a command to ask it what its outputs were, so these methods aren't quite as useful as they could be. > In my case I'll probably write a new command called something like > 'metadata' that doesn't do anything but return meta-data about the > distribution. We've been down this road before! The outcome was the DistributionMetadata class, defined in dist.py. Once you have a Distribution object, you can query its metadata using 'get_description()', 'get_fullname()', etc. > This would allow me to do something like this: > > meta_data=distutils.core.run_setup(open('foo-1.0.tgz'), 'metadata') > > which is what I want. I think I would spell this: dist = distutils.core.run_setup('foo-1.0/setup.py', stop_after="init") and then you can do this: print "%s (version %s), provided by %s" % (dist.get_name(), dist.get_version(), dist.get_contact()) Seem reasonable? Greg -- Greg Ward - just another Python hacker gward@python.net http://starship.python.net/~gward/ Sure, I'm paranoid... but am I paranoid ENOUGH? From gward@python.net Tue Aug 29 03:01:45 2000 From: gward@python.net (Greg Ward) Date: Mon, 28 Aug 2000 22:01:45 -0400 Subject: [Distutils] script_name and script_args Message-ID: <20000828220145.A779@beelzebub> Hi all -- I've just tweaked the Distribution class and 'setup()' function a bit so that you can pass 'script_name' (sys.argv[0]) and 'script_args' (sys.argv[1:]) in as keyword args to 'setup()'. Obviously this would never be used in the "canonical" case of a setup script run by the user from the command-line, but it's a handy back door for whatever trickery Paul is doing in PyFort. (Auto-generated setup scripts, indeed! Well, as long as m4 isn't involved...) Now we just have to deal with Amos' dist-bot needs, and that'll be that for Distutils 0.9.2. Marching ever onwards... Greg -- Greg Ward - Linux weenie gward@python.net http://starship.python.net/~gward/ A day without sunshine is like night. From mwa@gate.net Tue Aug 29 04:41:55 2000 From: mwa@gate.net (Mark W. Alexander) Date: Mon, 28 Aug 2000 23:41:55 -0400 (EDT) Subject: [Distutils] bdist_pkgtool attempt In-Reply-To: <20000828213143.A786@beelzebub> Message-ID: On Mon, 28 Aug 2000, Greg Ward wrote: > OK, good, one more budding Distutils hacker with feet wet. Excellent! > Need all the help we can get. > > I will take a closer look at bdist_sdux; I was worried that it would be > a hatchet job similar to bdist_pkgtool, and I hate reading cut 'n pasted > code. But first, you have to tell me what "sdux" stands for. I keep > mentally dropping the "d"... SD-UX is Software Distributor for HP-UX. I have the same problem with the 'd'. I'm not attached to the name, so _hpux or _depot (that's what an hp package is called) or even just _hp. I'm just not positive that HP is the only one that uses this format. > Ahh, gotcha. Idea: don't use Distutils to do the install, but do take > advantage of it for the install-time scripts. Or rather, take advantage > of Python and assume that the Distutils are installed on the target > machine. Then you can do > > from distutils.sysconfig import get_python_inc > > libdir = get_python_lib(plat_specific=1) > ... > > instead of that nasty shell trickery-pokery. Hmm, so I would then invoke distutils 'install' and force it to that directory? Then I'd either have to force the file inventory somehow. I'm not aware of a clean way to do that, although the inventory files are text that could be manipulated. I tend to favor letting the native tool do as much as possible, though. My assumption is that if you're building binaries, your doing it for people who don't care about distutils or anything else about how the binary was created. They just want it to work like everything else they do. Maybe I've just been around too many people who prefer ignorance.... > Of course, you may have a slight chicken/egg problem in getting the > Distutils installed, if these target platforms are running 1.5.2. Umm, > left as an exercise for the reader... ;-) I can cope. The package can be made dependent on python 1.6. If necessary, I can provide python binary packages for Solaris and HP and submit them to the usual sites. As long as the package criteria is known, making dependencies is a breeze. > Note that the other Unix bdist_* commands (dumb and rpm, at this date) > don't do anything smart about install location. They just mimic > whatever the structure on the build host was. This is just fine for > bdist_rpm; if you're building and RPM for Red Hat 6.2, you should be > doing so with the Red Hat 6.2 Python interpreter. For bdist_dumb, it's > just laziness on my part -- and the only real way to deal with the > potential prefix/exec-prefix distinction. > > General principle: when writing a bdist_* command, I won't bite your > head off if you assume that the target system's Python installation is > the same as the build system's. At least for Unix: I think on Windows, > it's important to adjust to the user's preferred location for Python. > Probably the same for Mac OS... someday. ;-) This assumption is too painfull for me. When I assumed my current position, I took over dozens of archaic machines where the disks where sliced horribly. Of course, I HAD to have python everywhere, so I built packages that relocated (and linked to /usr/bin and /usr/local/bin). Because of that experience, I've become a fanatic advocate of relocatable packages. If the installer doesn't care, then default directories are fine. If they have any need to be creative (like building an NFS utility partition) I don't feel it's a packager's place to cripple them. Making packages relocatable is not that difficult (even though making packages that make relocatable packages can twist your brain....). > Yeah, you're right; no point in punishing the poor hapless souls stuck > with the evil spawn of Sun. My sympathies. Thanx B-\ > What, the source code isn't documentation enough? ;-) Usually, yes. I must have looked at the Command class for at least 5 minutes before trying sdux! Time is just too short for me right now. > Well, Fred has been pushing me to write some "Distutils Internals" > documentation. Back to the docs... I did see you mention somewhere that there was some docs in CVS. I have had problems getting the CVS version since I'm behind a firewall. If there's something there that's helpfull, I'd appreciate it included in the next snapshot (or even a seperate doc-only snapshot). But rather than "Distutils Internals", may I recommend a "command writer's guide" first? My impression is that Distutils is both robust and enough for 1.0 and that those already involved are probably knowledgable enough to squash bugs. The biggest are for improvement now lies in additional package format support. And let's face it, making packages ain't brain surgery. If I can make a bdist_pkgtool_sux_but_works in a couple hours by stepping through someone elses bdist and typing over lines, it can't require that much knowledge of distutils internals. Actually, I'm now just sorry I didn't make the attempt a long time ago. Once I get the hang of it, I'd even be willing to install debian somewhere to try _deb if no one else has committed to it. (But do NOT ask me to do AIX!) mwa From amos@digicool.com Tue Aug 29 23:10:55 2000 From: amos@digicool.com (Amos Latteier) Date: Tue, 29 Aug 2000 15:10:55 -0700 Subject: [Distutils] re: Opening up backdoors to 'setup()' Message-ID: <39AC34EF.3D0BBE2D@digicool.com> Greg Ward: > On 28 August 2000, Amos Latteier said: > > I've thought about this a little. It seems to me that the basic desire > > is to be able to run setup from python, not the command line. I think we > > could accommodate this with something like this > > > > distutils.core.run_setup(file, commands) > > Hmmm, that does look cleaner for your needs than setting a global mode > variable. (Of course, it might end up setting a global mode variable > behind the scenes, but never mind that. If I break 'setup()' up into > its constituent parts, or farm more of it off to the Distribution class, > that shouldn't be necessary.) > > However, since I just went ahead and implemented 'script_name' and > 'script_args' arguments to 'setup()', this is not needed for Paul's > case. So distutils.core.setup(script_name=file, script_args=commands) is the same as distutils.core.run_setup(file, commands)? If so, is there any need for a run_setup function? > > In my case I'll probably write a new command called something like > > 'metadata' that doesn't do anything but return meta-data about the > > distribution. > > We've been down this road before! The outcome was the > DistributionMetadata class, defined in dist.py. Once you have a > Distribution object, you can query its metadata using > 'get_description()', 'get_fullname()', etc. ... > I think I would spell this: > > dist = distutils.core.run_setup('foo-1.0/setup.py', stop_after="init") > > and then you can do this: > > print "%s (version %s), provided by %s" % > (dist.get_name(), dist.get_version(), dist.get_contact()) > > Seem reasonable? Yes! I don't care about the exact spelling, I just want access to the Distribution object from Python. However... to me run_setup seems different enough from setup to be a different function. Also stop_after=init seems fairly close to a command to me. But I promise to stop quibbling ;-) Whatever you decide is great. Thanks! -Amos -- Amos Latteier mailto:amos@digicool.com Digital Creations http://www.digicool.com From gward@python.net Tue Aug 29 22:35:01 2000 From: gward@python.net (Greg Ward) Date: Tue Aug 29 21:35:01 2000 Subject: [Distutils] Re: Opening up backdoors to 'setup()' Message-ID: <20000829213301.A1129@beelzebub> [quoth Amos] > So distutils.core.setup(script_name=file, script_args=commands) is the > same as distutils.core.run_setup(file, commands)? No. Passing 'script_name' to 'setup()' is just a "fool yourself" thing; it doesn't actually change the script being run. It's mainly there for completism's sake; if you can override sys.argv[1:], you ought to be able to override sys.argv[0]. Here's a summary of what I'm thinking right now: setup(var=value, ...) - the traditional and usual way to invoke the Distutils - parses sys.argv (unless you override it) and carries out all actions implied by the command line and config files - currently returns nothing -- not much point, because it's all about side-effect, and the intended use is from a setup script, which is run by an installer who doesn't give a whit about the Distribution instance run_setup(file, script_args=sys.argv[1:], stop_after="run") - execfile's the setup script named by 'file' - this causes 'setup()' to be called in the normal way, so that a Distribution instance is created in the normal way, etc. - but some strings are pulled behind the scenes so that we don't necessarily run to completion - and something -- probably the Distribution instance -- is returned, which the caller can than query to discover the state of the distribution (eg. metadata, contents of config files, etc.) > If so, is there any need for a run_setup function? I still think so. The differences are subtle but important. Greg -- Greg Ward - Unix geek gward@python.net http://starship.python.net/~gward/ "He's dead, Jim. You get his tricorder and I'll grab his wallet." From gward@python.net Tue Aug 29 22:50:01 2000 From: gward@python.net (Greg Ward) Date: Tue Aug 29 21:50:01 2000 Subject: [Distutils] Re: bdist_pkgtool attempt Message-ID: <20000829214836.A1143@beelzebub> [quoth Mark Alexander] > SD-UX is Software Distributor for HP-UX. I have the same problem > with the 'd'. I'm not attached to the name, so _hpux or _depot > (that's what an hp package is called) or even just _hp. I'm just > not positive that HP is the only one that uses this format. Then "bdist_sdux" is the right name. There are already approximately 17,000 known installation tools and/or schemes named "depot"; why confused matters? [my loopy idea] > Ahh, gotcha. Idea: don't use Distutils to do the install, but do take > advantage of it for the install-time scripts. Or rather, take advantage > of Python and assume that the Distutils are installed on the target > machine. Then you can do > > from distutils.sysconfig import get_python_inc > > libdir = get_python_lib(plat_specific=1) > ... > > instead of that nasty shell trickery-pokery. [Mark responds skeptically] > Hmm, so I would then invoke distutils 'install' and force it to > that directory? Then I'd either have to force the file inventory > somehow Or just use the Distutils' handy tools for copying files around; see distutils.dir_util.copy_tree(). That's what the "install" command uses. Most of the distutils.*_util modules are intended to make writing shell-style code in Python relatively simple. (Then will someone please explain to me why the Distutils is 6,300+ lines of code... sigh... another great idea shot down by cold, hard reality.) > I tend to favor letting the native tool do as much as possible, > though. Definitely. If "native tools" means including shell code in your installer rather than Python code, so be it. It *is* icky to have the "prefix + lib/pythonX.Y/site-packages" knowledge in 3 places, though... 2 (sysconfig.py and install.py) is bad enough, but just because I slipped up doesn't mean we should let things get worse. > My assumption is that if you're building binaries, your doing it > for people who don't care about distutils or anything else about > how the binary was created. They just want it to work like > everything else they do. Umm, if they want everything to "just work", what on earth are they still using Solaris for? (Note the total absence of a smiley here: I'm dead serious! I used to think Linux was "just another Unix", so adjusting to Solaris at work wouldn't be so bad. I guess I didn't stop to think about what an enormous difference it makes to have "less" installed out-of-the-box... never mind Emacs, GCC, KDE, Gnome, Gtk, Qt, etc. etc.) > This assumption is too painfull for me. When I assumed my current > position, I took over dozens of archaic machines where the disks > where sliced horribly. Of course, I HAD to have python everywhere, > so I built packages that relocated (and linked to /usr/bin and > /usr/local/bin). Because of that experience, I've become a > fanatic advocate of relocatable packages. Ooh, that reminds me: need to check in to the relocatability of Distutils-generated RPMs. This is not a concern for "dumb" built distributions (they *are* dumb, after all), but I see no good reason why our RPMs (and other "smart" distributions) shouldn't at least be relocatable at user preference. (Note that I'm drawing a distinction between "relocatable" -- user specifies the installation prefix -- and "smart enough to figure out where Python is installed, and put itself there". I still don't consider the latter essential for RPMs, but I do for Windows installers. Go figure. Anyone else care either way?) Greg -- Greg Ward - Unix nerd gward@python.net http://starship.python.net/~gward/ I have a VISION! It's a RANCID double-FISHWICH on an ENRICHED BUN!! From hgebel@inet.net Wed Aug 30 00:30:16 2000 From: hgebel@inet.net (Harry Henry Gebel) Date: Tue Aug 29 23:30:16 2000 Subject: [Distutils] Re: bdist_pkgtool attempt In-Reply-To: <20000829214836.A1143@beelzebub>; from gward@python.net on Tue, Aug 29, 2000 at 09:48:37PM -0400 References: <20000829214836.A1143@beelzebub> Message-ID: <20000829232847.A29705@inet.net> On Tue, Aug 29, 2000 at 09:48:37PM -0400, Greg Ward wrote: > Ooh, that reminds me: need to check in to the relocatability of > Distutils-generated RPMs. This is not a concern for "dumb" built > distributions (they *are* dumb, after all), but I see no good reason why > our RPMs (and other "smart" distributions) shouldn't at least be > relocatable at user preference. (Note that I'm drawing a distinction > between "relocatable" -- user specifies the installation prefix -- and > "smart enough to figure out where Python is installed, and put itself > there". I still don't consider the latter essential for RPMs, but I do > for Windows installers. Go figure. Anyone else care either way?) The rpms are set up to be relocatable, although I have never actually tried to relocate one; it should work though as long as your python installation was relocated to the same place (or at any rate as long as the relocated site-packages directory is in your path.) -- Harry Henry Gebel, Senior Developer, Landon House SBS ICQ# 76308382 West Dover Hundred, Delaware From dubois@users.sourceforge.net Wed Aug 30 02:33:01 2000 From: dubois@users.sourceforge.net (Paul F. Dubois) Date: Wed Aug 30 01:33:01 2000 Subject: [Distutils] Re: Opening up backdoors to 'setup()' In-Reply-To: <20000829213301.A1129@beelzebub> Message-ID: Just to be clear, I do not have any "script" I want to run. The call to setup is "it". I am doing something like apply(setup, [], kw) having set up the dictionary kw. I do not have a file and don't want to write one. My problem was how to specify the command and its arguments in this context. That could be one or more extra keyworded arguments, or it could be positional argument(s), since normally setup doesn't have any. I morally object to stuffing sys.argv, is all. So far, by the way, I have not encountered a single user who was not completely and utterly mystified by the traceback, which as a nice side effect generally caused the compile error they needed to see to scroll off screen. I think as a long term goal we should be trapping all errors inside setup and uttering something intelligent. The fact that one is in the call to setup is not exactly illuminating. Perhaps I missed a discussion of this sort since I can't really handle this lists' volume. If so, my apologies. From robin@jessikat.fsnet.co.uk Wed Aug 30 06:49:08 2000 From: robin@jessikat.fsnet.co.uk (Robin Becker) Date: Wed Aug 30 05:49:08 2000 Subject: [Distutils] Numeric-16.0 problem Message-ID: I guess this error is caused by Numeric-16.0 taking the distutils version string list a bit too seriously. The setup.py script wants to do if vs[0] < 1 and vs[1] < 9: raise SystemExit, "Please see README: Distutils-0.9 or later required." is there a correct way to get this kind of version number? C:\Python\devel\Numeric-16.0>python setup.py build Traceback (innermost last): File "setup.py", line 14, in ? vs = map(string.atoi, string.split(v, '.')) File "", line 2, in map ValueError: invalid literal for atoi(): 2pre -- Robin Becker From R.Liebscher@gmx.de Wed Aug 30 07:18:08 2000 From: R.Liebscher@gmx.de (Rene Liebscher) Date: Wed Aug 30 06:18:08 2000 Subject: [Distutils] some small bugs References: <399BD06F.13FD9EAA@gmx.de> <20000821215505.A1131@beelzebub> Message-ID: <39ACDE11.B7F8AEE2@gmx.de> Greg Ward wrote: > > On 17 August 2000, Rene Liebscher said: > > If your distribution directory for bdist > > doesn't exist, distutils doesn't create > > it. (Even the default 'dist', so distutils > > fails if you use bdist for the first time.) > > Oops! Only a problem in bdist_dumb, because the other bdist commands > just happen to use sdist, which did call 'mkpath()' properly. Anyways, > I've fixed the problem by adding a couple of 'mkpath()' calls to > archive_util.py, which should handle all future tarball-and-zip-file- > generating commands. bdist_wininst has the same problem. The patch fixes this. It also changes two other problems. First it raises an PlatformException if you try to use it with modules which contain compiled C-extensions. Distutils doesn't support crosscompiling. The second changes the directory of the ini-file which is created. It is now created in the dist directory instead in the current. > > And a new introduced one in bcppcompiler.py > > It uses the first object file's path name to > > get the directory for its def-file. But if there is > > another object placed at the first position, this > > doesn't work. The patch moves these parts to their > > right position. > > Hmm, I knew I should have thought harder about that bit of code. Well, > I'll think hard about this patch. ;-) > > > The patch also changes the prefered library names > > from bcpp_xxx.lib to xxx_bcpp.lib. > > Good -- meant to get this into 0.9.1, but oh well. > > > The next is not a bug. > > I tried distutils with BeOS R5. BeOS uses also some > > linker scripts (as AIX does.) But in the Makefile are > > again the wrong pathnames to these scripts. So we have > > to correct this as for AIX in sysconfig.py. > > (Python doesn't install these scripts, I will > > put a patch for its Makefile.in to sourceforge.) > > Oh, bother. I knew that having > if sys.platform == "aix4" > > in the code wouldn't cut it. Need to think about how to detect this > situation -- "Python installed custom linker scripts to build shared > extensions on this platform" -- and deal with it generally. ISTR that > my first crack that the AIX problem took this approach by just > absolut-izing the LD_SO Makefile entry, but this didn't cut it because > the ld_so_aix script wasn't in the same location as the Makefile. Or > something like that. Can anyone think of the *right* way to do this? Maybe one should think about a kind of filter for LD_SHARED and other stuff. One thing is to remove invalid pathnames like -I.. or -L.. and add the right ones (sys.prefix + /include + /python16 ) if they are not already there. The other is to check the names of the executable file (using the new find_executable() from spawn.py) Something like this: ################################################# ld_shared = string.split(LD_SHARED) if not find_executable(ld_shared[0]): ld = string.split(ld_shared[0],os.sep) possible_places = string.join([sys.prefix + '/lib/config', sys.prefix + '/lib', '.'],os.pathsep) # for ld="a/b/c" try "c","b/c","a/b/c" for i in range(len(ld)): executable = find_executable(os.path.join(ld[-(1+i):]),possible_places) if executable: ld_shared[0]=executable break LD_SHARED = string.join(ld_shared) ################################################ This would work for most platforms, but there is still a problem: the path to the exports-file 'python.exp' on AIX. The attached patch uses still the old solution. > > And finally some corrections to the comments > > in my cygwinccompiler class. > > Oh good. > > Now, can you resubmit your patch as three patches: one for the > bcppcompiler.py fixes, one for sysconfig, and one for cygwinccompiler? > It's much easier to review and apply them one at a time like that. And > make sure you "cvs up" first so you get my fix to archive_util.py! And the patches: sysconfig.patch: * add code to _init_posix to fix path to the linker script cygwin.patch: * correct some mistakes in the comments bcppcompiler.patch: * reverse searched library names from bcpp_library to library_bcpp * move some code to the right places, to put the def-files in the right drectories again bdist_wininst.patch: * create dist directory * raise exception if using for modules containing compiled extensions on a non win32 platform. * change creation of ini-file, so it is now created in the dist directory instead the current one. Kind regards Rene Liebscher From R.Liebscher@gmx.de Wed Aug 30 07:33:03 2000 From: R.Liebscher@gmx.de (Rene Liebscher) Date: Wed Aug 30 06:33:03 2000 Subject: [Distutils] some small bugs References: <399BD06F.13FD9EAA@gmx.de> <20000821215505.A1131@beelzebub> <39ACDE11.B7F8AEE2@gmx.de> Message-ID: <39ACE22D.AFAB9E44@gmx.de> This is a multi-part message in MIME format. --------------E3F8885FAEBEE2CB962E4988 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit It seems I attached the patches to a wrong mail. Here they are. Kind regards Rene Liebscher --------------E3F8885FAEBEE2CB962E4988 Content-Type: text/plain; charset=us-ascii; name="bcppcompiler.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="bcppcompiler.patch" diff -BurN --exclude=*.pyc --minimal distutils.orig/distutils/bcppcompiler.py distutils.patched/distutils/bcppcompiler.py --- distutils.orig/distutils/bcppcompiler.py Mon Aug 14 15:13:04 2000 +++ distutils.patched/distutils/bcppcompiler.py Wed Aug 30 11:18:07 2000 @@ -224,17 +224,6 @@ else: ld_args = self.ldflags_shared[:] - # Borland C++ has problems with '/' in paths - objects = map(os.path.normpath, objects) - startup_obj = 'c0d32' - objects.insert(0, startup_obj) - - # either exchange python15.lib in the python libs directory against - # a Borland-like one, or create one with name bcpp_python15.lib - # there and remove the pragmas from config.h - libraries.append ('import32') - libraries.append ('cw32mt') - # Create a temporary exports file for use by the linker head, tail = os.path.split (output_filename) modname, ext = os.path.splitext (tail) @@ -246,6 +235,17 @@ self.execute(write_file, (def_file, contents), "writing %s" % def_file) + # Borland C++ has problems with '/' in paths + objects = map(os.path.normpath, objects) + startup_obj = 'c0d32' + objects.insert(0, startup_obj) + + # either exchange python15.lib in the python libs directory against + # a Borland-like one, or create one with name bcpp_python15.lib + # there and remove the pragmas from config.h + libraries.append ('import32') + libraries.append ('cw32mt') + # Start building command line flags and options. for l in library_dirs: @@ -377,9 +377,9 @@ # seems to have a different format for static libraries. if debug: dlib = (lib + "_d") - try_names = ("bcpp_" + dlib, "bcpp_" + lib, dlib, lib) + try_names = (dlib + "_bcpp", lib + "_bcpp", dlib, lib) else: - try_names = ("bcpp_" + lib, lib) + try_names = (lib + "_bcpp", lib) for dir in dirs: for name in try_names: --------------E3F8885FAEBEE2CB962E4988 Content-Type: text/plain; charset=us-ascii; name="sysconfig.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="sysconfig.patch" diff -BurN --exclude=*.pyc --minimal distutils.orig/distutils/sysconfig.py distutils.patched/distutils/sysconfig.py --- distutils.orig/distutils/sysconfig.py Thu Aug 3 11:00:00 2000 +++ distutils.patched/distutils/sysconfig.py Wed Aug 30 11:18:50 2000 @@ -254,6 +254,15 @@ python_exp = os.path.join(python_lib, 'config', 'python.exp') g['LDSHARED'] = "%s %s -bI:%s" % (ld_so_aix, g['CC'], python_exp) + if sys.platform == 'beos': + # Linker script is in the config directory. + # In the Makefile it is relative to the srcdir, which after + # installation no longer makes sense + python_lib = get_python_lib(standard_lib=1) + linkerscript_name = os.path.basename(string.split(g['LDSHARED'],' ')[0]) + linkerscript = os.path.join(python_lib, 'config', linkerscript_name) + g['LDSHARED'] = ("%s -L%s/lib -lpython%s" + % (linkerscript,sys.prefix,sys.version[0:3])) def _init_nt(): --------------E3F8885FAEBEE2CB962E4988 Content-Type: text/plain; charset=us-ascii; name="cygwin.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="cygwin.patch" diff -BurN --exclude=*.pyc --minimal distutils.orig/distutils/cygwinccompiler.py distutils.patched/distutils/cygwinccompiler.py --- distutils.orig/distutils/cygwinccompiler.py Mon Aug 14 15:13:04 2000 +++ distutils.patched/distutils/cygwinccompiler.py Wed Aug 30 11:18:07 2000 @@ -18,7 +18,7 @@ # # see also http://starship.python.net/crew/kernr/mingw32/Notes.html # -# * We use put export_symbols in a def-file, and don't use +# * We put export_symbols in a def-file, and don't use # --export-all-symbols because it doesn't worked reliable in some # tested configurations. And because other windows compilers also # need their symbols specified this no serious problem. @@ -32,7 +32,7 @@ # (ld doesn't support -shared, so we use dllwrap) # * cygwin gcc 2.95.2/ld 2.10.90/dllwrap 2.10.90 works now # - its dllwrap doesn't work, there is a bug in binutils 2.10.90 -# see also ..... +# see also http://sources.redhat.com/ml/cygwin/2000-06/msg01274.html # - using gcc -mdll instead dllwrap doesn't work without -static because # it tries to link against dlls instead their import libraries. (If # it finds the dll first.) --------------E3F8885FAEBEE2CB962E4988 Content-Type: text/plain; charset=us-ascii; name="bdist_wininst.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="bdist_wininst.patch" diff -BurN --exclude=*.pyc --minimal distutils.orig/distutils/command/bdist_wininst.py distutils.patched/distutils/command/bdist_wininst.py --- distutils.orig/distutils/command/bdist_wininst.py Wed Aug 30 11:03:53 2000 +++ distutils.patched/distutils/command/bdist_wininst.py Wed Aug 30 11:29:38 2000 @@ -64,6 +64,15 @@ def run (self): + if (sys.platform <> "win32" and + ( self.distribution.has_ext_modules() + or self.distribution.has_c_libraries() + or self.distribution.has_scripts())): + raise DistutilsPlatformError ( +# first line is shorter because it is preceeded by the exception class +"""*** If your module contains compiled +extensions, you have to build the win32 installer on a win32 platform. ***""") + self.run_command ('build') install = self.reinitialize_command('install') @@ -109,7 +118,8 @@ # a file is (at least) useful for debugging bdist_wininst. metadata = self.distribution.metadata - ini_name = "%s.ini" % metadata.get_fullname() + ini_name = os.path.join(self.dist_dir, + "%s.ini" % metadata.get_fullname()) self.announce ("creating %s" % ini_name) inifile = open (ini_name, "w") @@ -149,6 +159,8 @@ def create_exe (self, arcname, fullname): import struct#, zlib + self.mkpath(self.dist_dir) + cfgdata = open (self.create_inifile()).read() installer_name = os.path.join(self.dist_dir, --------------E3F8885FAEBEE2CB962E4988-- From R.Liebscher@gmx.de Wed Aug 30 07:47:01 2000 From: R.Liebscher@gmx.de (Rene Liebscher) Date: Wed Aug 30 06:47:01 2000 Subject: [Distutils] Numeric-16.0 problem References: Message-ID: <39ACE551.86C9D743@gmx.de> Robin Becker wrote: > > I guess this error is caused by Numeric-16.0 taking the distutils version string > list a bit too seriously. The setup.py script wants to do > if vs[0] < 1 and vs[1] < 9: > raise SystemExit, "Please see README: Distutils-0.9 or later required." > > is there a correct way to get this kind of version number? > Distutils has some special classes for dealing with version numbers, see distutils/version.py . Your code should then look similar to this: from distutils.version import StrictVersion if StrictVersion(v) < "0.9": raise SystemExit, "Please see README: Distutils-0.9 or later required." Kind regards Rene Liebscher From thomas.heller@ion-tof.com Wed Aug 30 10:41:02 2000 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Wed Aug 30 09:41:02 2000 Subject: [Distutils] some small bugs References: <399BD06F.13FD9EAA@gmx.de> <20000821215505.A1131@beelzebub> <39ACDE11.B7F8AEE2@gmx.de> Message-ID: <002401c01287$db842790$4500a8c0@thomasnb> > > > If your distribution directory for bdist > > > doesn't exist, distutils doesn't create > > > it. (Even the default 'dist', so distutils > > > fails if you use bdist for the first time.) > > > > Oops! Only a problem in bdist_dumb, because the other bdist commands > > just happen to use sdist, which did call 'mkpath()' properly. Anyways, > > I've fixed the problem by adding a couple of 'mkpath()' calls to > > archive_util.py, which should handle all future tarball-and-zip-file- > > generating commands. > > bdist_wininst has the same problem. > > The patch fixes this. It also changes two other problems. > First it raises an PlatformException if you try to use it with > modules which contain compiled C-extensions. Distutils doesn't > support crosscompiling. > The second changes the directory of the ini-file which is > created. It is now created in the dist directory instead in > the current. Thanks for finding this (and for looking at bdist_wininst at all). I've applied your patches to my version of bdist_wininst, with one exception: The ini-data is no longer written to a separate file at all, this was more or less for debugging. Thomas The patch now is: Index: bdist_wininst.py =================================================================== RCS file: /cvsroot/python/distutils/distutils/command/bdist_wininst.py,v retrieving revision 1.7 diff -c -r1.7 bdist_wininst.py *** bdist_wininst.py 2000/08/27 20:44:13 1.7 --- bdist_wininst.py 2000/08/30 13:39:23 *************** *** 63,68 **** --- 63,77 ---- def run (self): + if (sys.platform <> "win32" and + ( self.distribution.has_ext_modules() + or self.distribution.has_c_libraries() + or self.distribution.has_scripts())): + raise DistutilsPlatformError ( + # first line is shorter because it is + # preceeded by the exception class + """*** If your module contains compiled + extensions, you have to build the win32 installer on a win32 platform.""") self.run_command ('build') *************** *** 103,123 **** # run() ! def create_inifile (self): ! # Create an inifile containing data describing the installation. ! # This could be done without creating a real file, but ! # a file is (at least) useful for debugging bdist_wininst. metadata = self.distribution.metadata - ini_name = "%s.ini" % metadata.get_fullname() - self.announce ("creating %s" % ini_name) - inifile = open (ini_name, "w") - # Write the [metadata] section. Values are written with # repr()[1:-1], so they do not contain unprintable characters, and # are not surrounded by quote chars. ! inifile.write ("[metadata]\n") # 'info' will be displayed in the installer's dialog box, # describing the items to be installed. --- 112,127 ---- # run() ! def get_inidata (self): ! # Return data describing the installation. + lines = [] metadata = self.distribution.metadata # Write the [metadata] section. Values are written with # repr()[1:-1], so they do not contain unprintable characters, and # are not surrounded by quote chars. ! lines.append ("[metadata]") # 'info' will be displayed in the installer's dialog box, # describing the items to be installed. *************** *** 129,155 **** if data: info = info + ("\n %s: %s" % \ (string.capitalize (name), data)) ! inifile.write ("%s=%s\n" % (name, repr (data)[1:-1])) # The [setup] section contains entries controlling # the installer runtime. ! inifile.write ("\n[Setup]\n") ! inifile.write ("info=%s\n" % repr (info)[1:-1]) ! inifile.write ("pthname=%s.%s\n" % (metadata.name, metadata.version)) if self.target_version: ! inifile.write ("target_version=%s\n" % self.target_version) title = self.distribution.get_fullname() ! inifile.write ("title=%s\n" % repr (title)[1:-1]) ! inifile.close() ! return ini_name ! # create_inifile() def create_exe (self, arcname, fullname): ! import struct#, zlib ! cfgdata = open (self.create_inifile()).read() installer_name = os.path.join(self.dist_dir, "%s.win32.exe" % fullname) --- 133,160 ---- if data: info = info + ("\n %s: %s" % \ (string.capitalize (name), data)) ! lines.append ("%s=%s" % (name, repr (data)[1:-1])) # The [setup] section contains entries controlling # the installer runtime. ! lines.append ("\n[Setup]") ! lines.append ("info=%s" % repr (info)[1:-1]) ! lines.append ("pthname=%s.%s" % (metadata.name, metadata.version)) if self.target_version: ! lines.append ("target_version=%s" % self.target_version) title = self.distribution.get_fullname() ! lines.append ("title=%s" % repr (title)[1:-1]) ! return string.join (lines, "\n") ! # get_inidata() def create_exe (self, arcname, fullname): ! import struct ! ! self.mkpath(self.dist_dir) ! cfgdata = self.get_inidata() installer_name = os.path.join(self.dist_dir, "%s.win32.exe" % fullname) From dubois@users.sourceforge.net Wed Aug 30 19:40:03 2000 From: dubois@users.sourceforge.net (Paul F. Dubois) Date: Wed Aug 30 18:40:03 2000 Subject: [Distutils] Numeric-16.0 problem In-Reply-To: <39ACE551.86C9D743@gmx.de> Message-ID: OK, I'll fix it. But first convince me this "<" really works though? 0.10 vs. 0.9, for example? > -----Original Message----- > From: distutils-sig-admin@python.org > [mailto:distutils-sig-admin@python.org]On Behalf Of Rene Liebscher > Sent: Wednesday, August 30, 2000 3:43 AM > To: Robin Becker > Cc: distutils-sig@python.org > Subject: Re: [Distutils] Numeric-16.0 problem > > > Robin Becker wrote: > > > > I guess this error is caused by Numeric-16.0 taking the > distutils version string > > list a bit too seriously. The setup.py script wants to do > > if vs[0] < 1 and vs[1] < 9: > > raise SystemExit, "Please see README: Distutils-0.9 or > later required." > > > > is there a correct way to get this kind of version number? > > > Distutils has some special classes for dealing with version > numbers, see distutils/version.py . > > Your code should then look similar to this: > > > from distutils.version import StrictVersion > > if StrictVersion(v) < "0.9": > raise SystemExit, "Please see README: Distutils-0.9 or later > required." > > > > Kind regards > > Rene Liebscher > > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > http://www.python.org/mailman/listinfo/distutils-sig > From gward@starship.beopen.com Wed Aug 30 21:01:02 2000 From: gward@starship.beopen.com (Greg Ward) Date: Wed Aug 30 20:01:02 2000 Subject: [Distutils] Re: bdist_pkgtool attempt In-Reply-To: <20000829232847.A29705@inet.net>; from hgebel@inet.net on Tue, Aug 29, 2000 at 11:28:47PM -0400 References: <20000829214836.A1143@beelzebub> <20000829232847.A29705@inet.net> Message-ID: <20000830165910.A16140@starship.beopen.com> On 29 August 2000, Harry Henry Gebel said: > The rpms are set up to be relocatable, although I have never actually tried > to relocate one; it should work though as long as your python installation > was relocated to the same place (or at any rate as long as the relocated > site-packages directory is in your path.) Yep: I verified this with the Distutils' own RPM; it relocated just fine, even though Red Hat's Python RPM isn't relocatable: # rpm -ihv --prefix=/tmp/usr python-1.5.2-13.i386.rpm error: package python is not relocateable But: # rpm -ihv --prefix=/tmp/usr Distutils-0.9.2pre-1.noarch.rpm Distutils ################################################## # rpm -ql Distutils /tmp/usr/doc/Distutils-0.9.2pre ... /tmp/usr/lib/python1.5/site-packages/distutils/__init__.py /tmp/usr/lib/python1.5/site-packages/distutils/__init__.pyc /tmp/usr/lib/python1.5/site-packages/distutils/archive_util.py /tmp/usr/lib/python1.5/site-packages/distutils/archive_util.pyc ... Perfect! Greg From gward@starship.beopen.com Wed Aug 30 21:08:01 2000 From: gward@starship.beopen.com (Greg Ward) Date: Wed Aug 30 20:08:01 2000 Subject: [Distutils] Re: Opening up backdoors to 'setup()' In-Reply-To: ; from dubois1@llnl.gov on Tue, Aug 29, 2000 at 10:28:35PM -0700 References: <20000829213301.A1129@beelzebub> Message-ID: <20000830170643.B16140@starship.beopen.com> On 29 August 2000, Paul F. Dubois said: > Just to be clear, I do not have any "script" I want to run. The call to > setup is "it". > I am doing something like apply(setup, [], kw) having set up the dictionary > kw. > I do not have a file and don't want to write one. Right, that's what I understood. You don't have to write a file at all, all you have to do is add a 'script_args' element to your 'kw' dict to override sys.argv[1:]. For good form, you might need to add 'script_name' to override sys.argv[0]. This matters in two places: the "build_py" command excludes 'script_name' when it does *.py to find all modules in a package, to prevent the setup script being installed; and the "sdist" command regenerates the MANIFEST file if it is older than 'script_name', on the theory that you may have added or removed modules if you edited your setup script. The business about a file to run is for Amos, who wants to pull random setup scripts off the net and extract useful information from them. The clean-looking way to do this is to pass the filename (of the setup script) into the Distutils and ask it to do the dirty work for you. > So far, by the way, I have not encountered a single user who was not > completely and utterly mystified by the traceback, which as a nice side > effect generally caused the compile error they needed to see to scroll off > screen. Huh? Which traceback are you talking about here? Any traceback from a setup script is a bug in the Distutils (unless it's custom code in the setup script, can't do much about that). Any "user" errors -- either by the installer or the developer who wrote the setup script -- *are* caught by 'setup()'; failure to catch such errors is a Distutils bug and should be treated as such. Greg From gward@python.net Wed Aug 30 21:23:02 2000 From: gward@python.net (Greg Ward) Date: Wed Aug 30 20:23:02 2000 Subject: [Distutils] Numeric-16.0 problem In-Reply-To: ; from dubois1@llnl.gov on Wed, Aug 30, 2000 at 03:35:04PM -0700 References: <39ACE551.86C9D743@gmx.de> Message-ID: <20000830172040.A16383@python.net> On 30 August 2000, Paul F. Dubois said: > OK, I'll fix it. But first convince me this "<" really works though? > 0.10 vs. 0.9, for example? It works, depending on how you define "works". In the "strict versioning" scheme, version numbers are dot-separated integer tuples, not floating-point numbers. Thus, "0.10" != "0.1", but "0.1.0" == "0.1" (a slight corruption of the integer-tuple view, made as a concession to reality). This is the version numbering scheme advocated by the GNU project, and by ESR's "Software Release Howto". It works for me, and it's the scheme that will always be used by the Distutils. So yes, it's safe to say if StrictVersion(distutils.__version__) < "0.9" ...except that I use "0.9.2pre" for pre-release development code, which makes StrictVersion blow up. Foo! I think it's time StrictVersion was revisited and made a little less strict, since I'm not *quite* such a version number fascist as I was 18 months ago, when I wrote that code. ;-) Greg From gward@python.net Wed Aug 30 21:25:09 2000 From: gward@python.net (Greg Ward) Date: Wed Aug 30 20:25:09 2000 Subject: [Distutils] Re: [Bug #113106] distutils' msvccompiler.py has small C++ defects In-Reply-To: <002601c012c6$3a575380$3ec02dd5@martelli>; from aleaxit@yahoo.com on Wed, Aug 30, 2000 at 11:05:41PM +0200 References: <200008301734.KAA18925@delerium.i.sourceforge.net> <002601c012c6$3a575380$3ec02dd5@martelli> Message-ID: <20000830172314.B16383@python.net> On 30 August 2000, Alex Martelli said: > from a brief experiment, the /GX switch seems to be OK with > C sources too (probably no effect?). For prudence, however, > my approach had been to add it only when compiling C++ > sources -- that's easy too given the way the loop is set up > now (there's already an if/else to set the /Tp or /TP switch > for the sourcecode; I just added another variable, to be > concatenated at the end, set to either [] or ['/GX']). That's > probably more prudence than actually needed here, I guess. I'm checking in the easy-cheezy approach: use /GX when compiling anything. If it doesn't work for C code, we'll find out soon enough. Prudence, shmudence... Greg From fdrake@beopen.com Thu Aug 31 00:52:00 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Wed Aug 30 23:52:00 2000 Subject: [Distutils] Numeric-16.0 problem In-Reply-To: References: <39ACE551.86C9D743@gmx.de> Message-ID: <14765.54804.218695.304756@cj42289-a.reston1.va.home.com> Paul F. Dubois writes: > OK, I'll fix it. But first convince me this "<" really works though? > 0.10 vs. 0.9, for example? Actually, the easiest way to deal with this would be for distutils to provide a version_info structure like that defined in the sys module (starting with Python 1.6something): import distutils if distutils.version_info < (0, 9): bad_distutils_version() else: setup(...) The definition of sys.version_info guarantees that the value monotonically increases with each new release so long as we don't change the numbering scheme, and comparisons against only the interesting prefix (as above) work reasonably. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From dubois@users.sourceforge.net Thu Aug 31 11:48:16 2000 From: dubois@users.sourceforge.net (Paul F. Dubois) Date: Thu Aug 31 10:48:16 2000 Subject: [Distutils] Numeric-16.0 problem In-Reply-To: <14765.54804.218695.304756@cj42289-a.reston1.va.home.com> Message-ID: > > import distutils > if distutils.version_info < (0, 9): > bad_distutils_version() > else: > setup(...) > > The definition of sys.version_info guarantees that the value > monotonically increases with each new release so long as we don't > change the numbering scheme, and comparisons against only the > interesting prefix (as above) work reasonably. > > > -Fred > And THAT works? comparison of tuples is lexographic? Really? This sig is full of odd things. Hidden Secrets of Python -- by Fred L. Drake, Jr. At a newstand near you. Just imagine the wealth and fame. > From fdrake@beopen.com Thu Aug 31 11:58:03 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Thu Aug 31 10:58:03 2000 Subject: [Distutils] Numeric-16.0 problem In-Reply-To: References: <14765.54804.218695.304756@cj42289-a.reston1.va.home.com> Message-ID: <14766.29210.364414.318310@cj42289-a.reston1.va.home.com> Paul F. Dubois writes: > And THAT works? comparison of tuples is lexographic? Really? > This sig is full of odd things. The values in the tuple are integers, not strings: Python 2.0b1 (#248, Aug 31 2000, 00:55:23) [GCC 2.95.3 19991030 (prerelease)] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) >>> sys.version_info (2, 0, 0, 'beta', 1) The values for the fourth entry are specifically chosen so that lexicographic comparison works: "alpha" < "beta" < "candidate" < "final" -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From dubois1@llnl.gov Thu Aug 31 13:40:02 2000 From: dubois1@llnl.gov (Paul F. Dubois) Date: Thu Aug 31 12:40:02 2000 Subject: [Distutils] Numeric-16.0 problem In-Reply-To: <14766.29210.364414.318310@cj42289-a.reston1.va.home.com> References: <14765.54804.218695.304756@cj42289-a.reston1.va.home.com> <14766.29210.364414.318310@cj42289-a.reston1.va.home.com> Message-ID: <00083109384900.20043@almanac> On Thu, 31 Aug 2000, Fred L. Drake, Jr. wrote: > Paul F. Dubois writes: > > And THAT works? comparison of tuples is lexographic? Really? > > This sig is full of odd things. >=20 > The values in the tuple are integers, not strings: >=20 > Python 2.0b1 (#248, Aug 31 2000, 00:55:23) [GCC 2.95.3 19991030 (prere= lease)] on linux2 > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > Copyright 1995-2000 Corporation for National Research Initiatives (CNRI= ) > >>> sys.version_info=20 > (2, 0, 0, 'beta', 1) >=20 > The values for the fourth entry are specifically chosen so that > lexicographic comparison works: >=20 > "alpha" < "beta" < "candidate" < "final" >=20 >=20 > -Fred >=20 > --=20 > Fred L. Drake, Jr. > BeOpen PythonLabs Team Member What I meant was that I hadn't known that comparison of tuples was meanin= gful at all; evidently you are teaching me that the comparisons of tuples are lexographic in the sense that it compares the first entries and only proc= eeds to the next component if the first entries are equal, etc. Python is full= of little surprises, almost always pleasant. From fdrake@beopen.com Thu Aug 31 13:47:24 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Thu Aug 31 12:47:24 2000 Subject: [Distutils] Numeric-16.0 problem In-Reply-To: <00083109384900.20043@almanac> References: <14765.54804.218695.304756@cj42289-a.reston1.va.home.com> <14766.29210.364414.318310@cj42289-a.reston1.va.home.com> <00083109384900.20043@almanac> Message-ID: <14766.35627.558211.80113@cj42289-a.reston1.va.home.com> Paul F. Dubois writes: > What I meant was that I hadn't known that comparison of tuples was > meaningful at all; evidently you are teaching me that the > comparisons of tuples are lexographic in the sense that it compares > the first entries and only proceeds to the next component if the > first entries are equal, etc. Python is full of little surprises, > almost always pleasant. Yes. Just as interestingly, this has been there a long time. Guido must have used his time machine to know we would have this specific requirement for comparing version numbers, and generalized effectively to begin with. ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From tim_one@email.msn.com Thu Aug 31 14:14:01 2000 From: tim_one@email.msn.com (Tim Peters) Date: Thu Aug 31 13:14:01 2000 Subject: [Distutils] Numeric-16.0 problem In-Reply-To: Message-ID: [Paul F. Dubois] > And THAT works? comparison of tuples is lexographic? Really? > This sig is full of odd things. All the builtin sequence types do lexicographic comparison: strings, lists and tuples. I think Guido added that feature in 0.9.1 . From hgebel@inet.net Thu Aug 31 16:54:04 2000 From: hgebel@inet.net (Harry Henry Gebel) Date: Thu Aug 31 15:54:04 2000 Subject: [Distutils] About version discussion Message-ID: <20000831155213.A1233@inet.net> I was wondering if it might be a good idea to put a function in Distutils that could query if the currently installed version has certain abilities. Each ability could be assigned a name, and it could be implemented very simply: (in setup.py) try: if not check_ability('a'): raise Exception # to be caught and reraised as SystemExit except: # for versions of Distutils without check_ability(), or without 'a' raise SystemExit, 'This package requires a more recent version of Distutils' (somewhere in the Distutils) def check_ability(ability): ''' Return true if ability is supported by Distutils ''' return ability in ['a', 'b', 'c'] -- Harry Henry Gebel, Senior Developer, Landon House SBS ICQ# 76308382 West Dover Hundred, Delaware From gward@python.net Thu Aug 31 22:33:02 2000 From: gward@python.net (Greg Ward) Date: Thu Aug 31 21:33:02 2000 Subject: [Distutils] some small bugs In-Reply-To: <39ACDE11.B7F8AEE2@gmx.de>; from R.Liebscher@gmx.de on Wed, Aug 30, 2000 at 12:12:33PM +0200 References: <399BD06F.13FD9EAA@gmx.de> <20000821215505.A1131@beelzebub> <39ACDE11.B7F8AEE2@gmx.de> Message-ID: <20000831183138.A31473@python.net> > The patch fixes this. It also changes two other problems. > First it raises an PlatformException if you try to use it with > modules which contain compiled C-extensions. Distutils doesn't > support crosscompiling. Ooh, but wouldn't it be cool if I could compile Windows extensions on Linux and vice-versa... oh, never mind! > And the patches: > sysconfig.patch: > * add code to _init_posix to fix path to the linker script OK, but: the addition of -l/usr/lib -Lpython2.0 should be done in a BeOS-specific section of build_ext, which is consistent with how we add the Python library for non-MS compilers on Windows. Probably the 'get_libraries()' method should be extended to take care of both library directory and name, and then a BeOS clause can be added. sysconfig is for describing the Python installation; knowledge about how to build extensions belongs in build_ext. > cygwin.patch: > * correct some mistakes in the comments > > bcppcompiler.patch: > * reverse searched library names from bcpp_library to library_bcpp > * move some code to the right places, to put the def-files > in the right drectories again OK, checked both of these in. > bdist_wininst.patch: > * create dist directory > * raise exception if using for modules containing compiled extensions > on a non win32 platform. > * change creation of ini-file, so it is now created in the dist > directory > instead the current one. I'll use Thomas' version of this patch instead. Greg From gward@python.net Thu Aug 31 22:44:01 2000 From: gward@python.net (Greg Ward) Date: Thu Aug 31 21:44:01 2000 Subject: [Distutils] some small bugs In-Reply-To: <002401c01287$db842790$4500a8c0@thomasnb>; from thomas.heller@ion-tof.com on Wed, Aug 30, 2000 at 03:40:27PM +0200 References: <399BD06F.13FD9EAA@gmx.de> <20000821215505.A1131@beelzebub> <39ACDE11.B7F8AEE2@gmx.de> <002401c01287$db842790$4500a8c0@thomasnb> Message-ID: <20000831184152.B31473@python.net> On 30 August 2000, Thomas Heller said: > Thanks for finding this (and for looking at bdist_wininst at all). > I've applied your patches to my version of bdist_wininst, with one > exception: The ini-data is no longer written to a separate file at all, > this was more or less for debugging. One comment on this patch, for either Rene or Thomas (whoever wrote the code in question). > def run (self): > + if (sys.platform <> "win32" and > + ( self.distribution.has_ext_modules() > + or self.distribution.has_c_libraries() > + or self.distribution.has_scripts())): ^^^^^^^^^^^ Why blow up if trying to build a script-ful distribution for Windows under (say) Unix? Yeah, sure, we'll be doing unnecessary work in setting the #! line to point to /usr/bin/python (or whatever), but I don't see any Windows-specific code in build_scripts.py. > + raise DistutilsPlatformError ( > + # first line is shorter because it is > + # preceeded by the exception class > + """*** If your module contains compiled > + extensions, you have to build the win32 installer on a win32 platform.""") Please, no newlines in exception messages: however you handle this is a crock, but the crock used throughout the Distutils is to assume that someday, some clever tool will nicely reformat those run-on exception messages. Also, the "***" doesn't add anything: the fact that the script blows up with an error message should be attention-getting enough. OK, I'll check it in without the ban on script-ful distributions, and with the exception-raising code rewritten. Greg From gward@python.net Thu Aug 31 23:12:03 2000 From: gward@python.net (Greg Ward) Date: Thu Aug 31 22:12:03 2000 Subject: [Distutils] ANNOUNCE: Distutils 0.9.2 Message-ID: <20000831191047.C31473@python.net> ...just in time for the Python 2.0b1 feature freeze, Distutils 0.9.2 has been released. Changes since 0.9.1: * fixed bug that broke extension-building under Windows for older setup scripts (not using the new Extension class) * new version of bdist_wininst command and associated tools: fixes some bugs, produces a smaller exeuctable, and has a nicer GUI (thanks to Thomas Heller) * added some hooks to 'setup()' to allow some slightly sneaky ways into the Distutils, in addition to the standard "run 'setup()' from a setup script" Get your copy today: http://www.python.org/sigs/distutils-sig/download.html Greg