From mwh21@cam.ac.uk Thu Dec 2 11:24:36 1999 From: mwh21@cam.ac.uk (Michael Hudson) Date: Thu, 2 Dec 1999 11:24:36 +0000 (GMT) Subject: [Distutils] Random bits In-Reply-To: <19991129091339.C7807@cnri.reston.va.us> Message-ID: On Mon, 29 Nov 1999, Greg Ward wrote: > On 28 November 1999, Michael Hudson said: > > Yes! I spent a frustrating few minutes trying to work out why files I was > > trying to exclude from the distribution were turning up in the tarball... > > Oops, sorry. That's OK :-) > > Also, excluding files from the dist in general is a pain. > > > > I have bytecodehacks in CVS; I don't want to distribute the CVS folders. I > > found no way to do this except building the MANIFEST file using a shell > > script (which kind of defeats the point of the manifest, I'd have > > thought). > > > > Also excluding a single file doesn't work. > [...more ranting about what doesn't work in the Distutils MANIFEST file...] > > Yeah, I've been bitten by a couple of these things myself; others, I > haven't seen. As I said in my last post, this was a cobbled-together > hack and not-at-all well thought-out. Guess it's time to fix that. It would be good if the distutils could be used to distribute stuff... [snip two phase plan] > Anyways, I'm open to ideas on how best to handle the > MANIFEST.in/MANIFEST thing (and syntax for the former). Tell me what > features you want, whether you even like the idea of going from a > short, simple list of exclude/include patterns to an explicit list of > every file, how you would like to use such a system, etc. Right, here's an idea. I'm not sure it's the best way to go, or even a reasonble one, but I'm just going to braindump for a while. At the base, I think you want to be able to supply a Python function that gets passed a path to a file and returns 1 if it should be included or 0 if not. But better would be a class (more Pythonic) with an "accept" method, e.g. class PermissiveAcceptor(Acceptor): # I'll explain Acceptor later def accept(self,file): return 1 then you need a way of combining Acceptors so that you can combine: class BackupRejector(Acceptor): def accept(self,file): return file[-1] <> '~' class PycRejector(Acceptor): def accept(self,file): if len(file) > 4: return file[-4:] <> ".pyc" Now my idea of how to do this is to define methods in the Acceptor class class Acceptor: def __and__(self,rhs): return AndingAcceptor(self,rhs) def __or__(self,rhs): return OringAcceptor(self,rhs) def __neg__(self): return NotAcceptor(self) class AndingAcceptor(Acceptor): def __init__(self,one,two): self.one = one self.two = two def accept(self,file): return self.one.accept(file) and self.two.accept(file) class OringAcceptor(Acceptor): def __init__(self,one,two): self.one = one self.two = two def accept(self,file): return self.one.accept(file) or self.two.accept(file) then: myacceptor = PycRejector() & BackupRejector() [ Random aside #1: For stateless acceptors like BackupRejector it might be better to do class _BackupRejector(Acceptor): def accept(self,file): return file[-1] <> '~' BackupRejector = _BackupRejector() ] [ Random aside #2: guess who's being doing some functional programming of late? ] Then setup would take another argument like "file_chooser" that would be called with every file in the heirachy. [ Random aside #3: hmm... maybe should have accept_file, accept_dir ] This would not be a particularly efficient solution, but that shouldn't really be a problem, should it? Then one has to provide a set of classes built in to distutils so that in the common cases, one doesn't have to write lots of code. Obvious candiate is MANIFESTAcceptor... A somewhat heavier weight idea of mine is too have files in each directory that are like MANIFESTs, but just for that directory. A bit like .cvsignore ... so you would put in a file called .distutils-manifest lines like: *.py ! hacked_up.py extra_support_file I would personally find that preferable to one top level file. What would be even nicer in some ways would be the ability to have rules that affected deeper level directories sort-of Acquisition style (if that makes sense to anyone - I know what I mean, btu I can't seem to express it properly and I've rabbited on for long enough now...) > (My main concern is that we *not* just have a simple MANIFEST file > that the developer has to create and maintain; that's how Perl's > MakeMaker expects you to work, and it's a PITA. It provides a module > to help you generate the MANIFEST the first time, but after that > you're pretty much on your own.) This is a fate to be avoided. Thank you for your patience. Comments appreciated (I can think of a few problems already...) Michael From gstein@lyra.org Thu Dec 2 11:59:50 1999 From: gstein@lyra.org (Greg Stein) Date: Thu, 2 Dec 1999 03:59:50 -0800 (PST) Subject: [Distutils] Random bits In-Reply-To: Message-ID: On Thu, 2 Dec 1999, Michael Hudson wrote: >... > class Acceptor: > def __and__(self,rhs): > return AndingAcceptor(self,rhs) > def __or__(self,rhs): > return OringAcceptor(self,rhs) > def __neg__(self): > return NotAcceptor(self) Sorry... but this is just silly. This is taking a simple problem of file selection and throwing a mess of procedural code at the thing. How is this *any* better than a simple list of files or file patterns? The distutils package must be *very* simple to gain acceptance. Requiring people to write code, understand how to subclass CCompiler, or provide a bazillion params to a setup() function is just not going to help. The developer ought to be able to say "ship *.py and foomodule.c". distutils would package that into a target directory and see that foomodule.c is compiled to a module on the target system. Done. Grain of salt time: until I step up and provide code to make distutils as simple as I hope it would be, my comments should be viewed as "peanut gallery" comments. Cheers, -g -- Greg Stein, http://www.lyra.org/ From mwh21@cam.ac.uk Thu Dec 2 13:20:42 1999 From: mwh21@cam.ac.uk (Michael Hudson) Date: Thu, 2 Dec 1999 13:20:42 +0000 (GMT) Subject: [Distutils] Random bits In-Reply-To: Message-ID: On Thu, 2 Dec 1999, Greg Stein wrote: > On Thu, 2 Dec 1999, Michael Hudson wrote: > >... > > class Acceptor: > > def __and__(self,rhs): > > return AndingAcceptor(self,rhs) > > def __or__(self,rhs): > > return OringAcceptor(self,rhs) > > def __neg__(self): > > return NotAcceptor(self) > > Sorry... but this is just silly. This is taking a simple problem of file > selection and throwing a mess of procedural code at the thing. How is this > *any* better than a simple list of files or file patterns? > > The distutils package must be *very* simple to gain acceptance. Requiring > people to write code, understand how to subclass CCompiler, or provide a > bazillion params to a setup() function is just not going to help. Perhaps I should have been more clear: I am in absolute agreement that it must be possible to be able to use distutils very simply. However it is my contention that it should also be extremely flexible, becuase if you want to do something a little bit unusual you should be able to do it without abandoning the advantages of distutils. I do not believe these aims are incompatible. What should be supplied is an easy to use system with sensible defaults such that the complexity of specificying which files to ship is commensurate with the complexity of your requirements. "ship *.py and foomodule.c" is a simple specification and there should be a simple way of saying it. If your specification is just a little more complex, then there should be a clear and coherent way of extending your setup.py file to accomodate it; if your specification is so fiendishly complex then you are going to need to write code to express it, then you should be able to that too. This applies to far more than just distribution systems of course, and is my main greivance with just about every bit of software that I have ever used... this is part of what the guile project is about. From http://www.gnu.org/software/guile: When you decide you need a scripting language or a configuration file, the first impulse is, ``I'll just do something clean and simple.'' This is the right impulse: a full programming language with conditionals,loops, local scopes, and procedures is just a distraction from your project. But simple languages never stay simple. For example, early releases of PHP, a language for generating web pages on the fly, touted its minute memory footprint and simplicitly. Well, the latest release of PHP has its own object system. Compare Tcl circa 1988 with the modern beast. Same story with Perl. The point here is not to criticize these (very successful) tools, but rather to show that simplicity in a scripting language doesn't last long. The real challenge is to age well. Whatever you may think of guile, they have a point. Oops, got a bit carried away there. > The developer ought to be able to say "ship *.py and foomodule.c". > distutils would package that into a target directory and see that > foomodule.c is compiled to a module on the target system. Done. Yes. However that should not (in my opinion) be *all* that can be said. A case could be made that there should be a limit on how complex your specification should be, but I don't buy it. Turing complete is enough for me ;-). > Grain of salt time: until I step up and provide code to make distutils as > simple as I hope it would be, my comments should be viewed as "peanut > gallery" comments. Same for me too, of course. But this is Python, so we'll be able to implement our ideas in about fifteen seconds, right ? Michael From gstein@lyra.org Thu Dec 2 13:35:30 1999 From: gstein@lyra.org (Greg Stein) Date: Thu, 2 Dec 1999 05:35:30 -0800 (PST) Subject: [Distutils] Random bits In-Reply-To: Message-ID: On Thu, 2 Dec 1999, Michael Hudson wrote: >... > Perhaps I should have been more clear: I am in absolute agreement that it > must be possible to be able to use distutils very simply. However it is my > contention that it should also be extremely flexible, becuase if you want > to do something a little bit unusual you should be able to do it without > abandoning the advantages of distutils. I do not believe these aims are > incompatible. Here is where I'll state "we'll agree to disagree." I have yet to find something that is "easy to use, yet flexible enough for whatever you may need to do." Nobody ever does this well, and I further believe that Python's rapid development capability obsoletes the notion of trying to do everything in one package (since it is so easy to write/extend with new code). In fact, your Guile quote kind of supports what I'm trying to say: systems that have tried to encompass every need end up big-and-ugly; therefore, I would maintain that you should *not* attempt to be all-encompassing. I'd rather see a bare-ass simple mechanism that solves the 80% case and tell the other 20% to go write their own (I might actually use stronger terms for those 20% people :-). Anybody can figure out bare-ass simple and use it. They can also figure out how to extend it for their particularly whacky situation. But... IMO... and I don't expect others to share that view or to code that view :-) Cheers, -g -- Greg Stein, http://www.lyra.org/ From jim@interet.com Thu Dec 2 14:34:54 1999 From: jim@interet.com (James C. Ahlstrom) Date: Thu, 02 Dec 1999 09:34:54 -0500 Subject: [Distutils] Random bits References: Message-ID: <3846838E.5941BC86@interet.com> Greg Stein wrote: > I'd rather see a bare-ass simple mechanism that solves the 80% case and > tell the other 20% to go write their own (I might actually use stronger > terms for those 20% people :-). Anybody can figure out bare-ass simple and > use it. They can also figure out how to extend it for their particularly > whacky situation. > > But... IMO... and I don't expect others to share that view or to code that > view :-) I agree completely. And in addition it is a Python promotion issue to have the 80% simple solution too. JimA From gward@cnri.reston.va.us Thu Dec 2 16:51:04 1999 From: gward@cnri.reston.va.us (Greg Ward) Date: Thu, 2 Dec 1999 11:51:04 -0500 Subject: [Distutils] Distutils integration In-Reply-To: ; from as544@freenet.toronto.on.ca on Mon, Nov 29, 1999 at 10:39:45PM -0500 References: <6H4P4gHAAcqH092yn@vex.net> <19991129085701.A7807@cnri.reston.va.us> Message-ID: <19991202115103.A12429@cnri.reston.va.us> On 29 November 1999, T-Methy Moddletin said: > >Oh well, that's the mess the Perl world was in five years ago before > >Jarkko Hietaniemi came along and cooked up CPAN. > > Hmmm, i'm not familiar with pre-CPAN Perl. Perhaps you could enlighten > me? What exactly was the nature of the "mess"? Perhaps there are other > ways than CPAN to address some of the problems? Non standard packages? > (You're taking care of that problem, i hope!) But perhaps non-standard > naming as well. Hideously ugly, eyeball splitting web page colours and > designs? (even more eyeball splitting than perl code itself?! ). > Broken links? Back in ... ummm... 1995-6 or so, there were a bunch of big, well-known Perl ftp archives. But none of them had everything, none of them were particularly well-organized, and the damn things kept flitting in and out of existence (or so it seemed to me when I was trying desperately to track down a tarball for Perl 5.001m, rather than the 5.001 tarball and patches a .. m). The story I heard (from Tim Bunce and Jarkko Hietaniemi at the O'Reilly Open Source Conference back in August) is something like this: the perl-packrats mailing list had existed for some time as a forum for archive site maintainers and users to bitch, whine, gripe, collude, etc. It didn't accomplish much until Jarkko arrogantly and unilaterally created the "Comprehensive Perl Archive Network" on a machine in Helsinki. It caught on pretty quick. Now, there are roughly 100 CPAN mirrors around the world, and I can find whatever I want as fast as I like. And if you want a meta-archive, there's search.cpan.org, which IMHO is what the Python world really needs. I don't care what you think about Perl, go visit that site *now*. From the top, you can browse by module category (taken straight from the Perl Module List). Or you can search by author name (or ID -- every CPAN contributor has a user ID), module name, or distribution name. You can search the text of all the documentation for every module uploaded to CPAN. This is an absolutely red-hot, kick-ass web site. Poking around it, I'm trying to remember why I use Python. Oh yeah, it has actual syntactic support for OO programming, that's why. ;-) I think one of the things I like about search.cpan.org is that it's sort-of a meta-archive, and sort of a centralized archive. All the search results you get back include the author's home page and email address, but if you want to download something -- bam, it comes straight from the archive at perl.com. (I guess it has more bandwidth than cpan.org or something.) The biggest problem I have with meta-archives is the one you have already found: broken links. And you already know the two most obvious solutions: scan the database regularly and rigorously, bitching at developers whose links break; and have an optional central archive that downloads stuff from developer's pages and puts it somewhere whose links *won't* break. I haven't used freshmeat much, but I've been impressed -- I don't think I've seen many broken links. Compare that to my unpleasant experience trying to find some free Java classes (because Sun somehow forgot that "the programming language for the Internet" might need to do MIME decoding -- oops). There is a big meta-archive at gamelan.com, but for everything I found -- bam, broken links everywhere. I think this just means that Linux developers have more of a clue about Internet culture than Java developers. I would expect the same degree of cluefulness from Python programmers, so I don't think a Python meta-archive would be as bad as gamelan.com... but it still needs careful link-policing! > Of course if there was a central archive, that takes care of finding > things as well (assuming everyone wants to bother with going to the > trouble of getting archived there). Still I must dissent. In > retrospect, I am not fond of CPAN. I do not miss it. I do not consider > it a model for emulation. It had perhaps some useful attributes----but > I am (and hopefully I don't just say this because it is the nature of > my-project-which-i-must-protect) genuinely in favour of > decentralised resources. I think it's more encouraging to people to > directly and easily control and release their stuff (and for those > who want to upload somewhere there is still ftp.python.org!) While > there are certain weaknesses and logistic complications (and yeah, > perhaps "mess" also!) it seems a much freer environment to me. Less > stuffy, as it were. Less official! Perhaps my biases are showing a > little too strongly. I find the rigidity of CPAN just a little too > intimidating, in fact. Legitimate difference of opinion. I think the B&D of CPAN (and all the other tools and tricks involved, principally MakeMaker and POD) is well worth it considering the payoff. Part of the payoff is search.cpan.org, and part is the ability to install a large and complex module distribution with a single command (at least under Unix): perl -MCPAN -e 'install ("Tk");' ... or something like that. If you have a functioning Perl installation, you might try that out. If things work out right, it does *everything* needed to find, download, configure, build, test, and install that very large module distribution. The only thing it doesn't do is order *Learning Perl/Tk* from amazon.com for you. I will continue to argue for just the right amount of bondage, discipline, structure, and bureaucracy to achieve that level of automation. The trick is using the *bare minimum* of bureaucracy that will achieve the desired result, and that's why I will continue to listen to people like you and Greg Stein arguing for anarchy. ;-) > I have never used as CSV in my live-long life. And it probably shows. > (-: I see all the strange $ codes in people's source and i think: wow, > that looks impressively obscure and archane, someday i'll have to > figure that out! However, i'm open to all these ideas. I have nothing > intrinsically against a central archive, and would certainly welcome > it (and happily index it---for myself, if no one else) --- let me > know when you open one. (-: I think you mean CVS. I strongly recommend the RCS/SCCS book from O'Reilly. (Just ignore the SCCS chapters.) If you're a lone programmer, CVS is overkill and RCS usually does the trick. For group projects, CVS (or something like it) is absolutely critical. Again, it's a question of imposing just enough bureaucracy and structure to get things done efficiently without bogging everyone down. RCS and CVS provide the right level of bureaucracy for me; other projects might prefer something like Aegis (which, roughly, requires that you write test code to validate every change you want to check in -- ouch!). Greg -- Greg Ward - software developer gward@cnri.reston.va.us Corporation for National Research Initiatives 1895 Preston White Drive voice: +1-703-620-8990 Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913 From gward@cnri.reston.va.us Thu Dec 2 16:54:15 1999 From: gward@cnri.reston.va.us (Greg Ward) Date: Thu, 2 Dec 1999 11:54:15 -0500 Subject: [Distutils] Distutils integration In-Reply-To: ; from gstein@lyra.org on Mon, Nov 29, 1999 at 11:46:22PM -0800 References: Message-ID: <19991202115415.B12429@cnri.reston.va.us> On 29 November 1999, Greg Stein said: > Don't let Greg dissuade you. In almost all cases, something is better than > nothing. The current state of a Python archive (or index) is pretty > abysmal. > > Keep doing what you're doing! Don't stop! :-) Umm, yeah, what he said. One True (Meta-)Archive would be best, but Yet Another (Meta-)Archive is better than nothing at all. > I argued the same topic (different approach, tho) on the trove-dev mailing > list (archives at www.python.org/pipermail/trove-dev). Basically, I > believe the current Internet user is looking for a Freshmeat-style index, > rather than a sunsite-style repository. Repositories are passe, indexes > are The Right And Just Way. :-) Again, I *mostly* agree -- meta-archives OK as long as link-checking is rigorously done. And central repositories may be passe and hard to scale, but they sure as heck are convenient once you know you're way around them. > I posted a little version number parser about a year ago, I think. It > handles most forms of version numbers, returning a tuple that can be > properly ordered (among the software's other releases using that version > number pattern). > > If you need to parse version numbers, that's the function to use. That version number parser is lurking in the Distutils distribution (class LooseVersion in module distutils.version). Currently it fails its test suite because we never did work out those differences of opinion on what version numbers mean. ;-) Greg -- Greg Ward - software developer gward@cnri.reston.va.us Corporation for National Research Initiatives 1895 Preston White Drive voice: +1-703-620-8990 Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913 From gward@cnri.reston.va.us Thu Dec 2 17:31:35 1999 From: gward@cnri.reston.va.us (Greg Ward) Date: Thu, 2 Dec 1999 12:31:35 -0500 Subject: [Distutils] Random bits In-Reply-To: ; from gstein@lyra.org on Thu, Dec 02, 1999 at 03:59:50AM -0800 References: Message-ID: <19991202123134.C12429@cnri.reston.va.us> On 02 December 1999, Greg Stein said: > On Thu, 2 Dec 1999, Michael Hudson wrote: > >... > > class Acceptor: > > def __and__(self,rhs): > > return AndingAcceptor(self,rhs) > > def __or__(self,rhs): > > return OringAcceptor(self,rhs) > > def __neg__(self): > > return NotAcceptor(self) > > Sorry... but this is just silly. This is taking a simple problem of file > selection and throwing a mess of procedural code at the thing. How is this > *any* better than a simple list of files or file patterns? Once again, I completely agree with Greg here. Michael's scheme is, ummm, interesting, but there is such a thing as being *too* object-oriented. I have not paid a lot of attention to performance in the Distutils, but I draw the line at severl method invocations to test every file in the source tree. The MANIFEST.in file should provide the level of flexibility needed by that all-important 80% of distributions. I think it's close now, but the syntax is inscrutable and the implementation flaky. (And it doesn't use MANIFEST.in, just MANIFEST.) The point of this thread is to fix those problems, not come up with an entirely different scheme. The distutils have been designed so that if a module developer *does* need some totally custom way to specify what files belong in his source distribution, it's not a problem. In theory, it goes something like this: * write a class that subclasses distutils.command.dist.Dist * override the method that finds the files to distribute * tell 'setup()' to attach your new class to the "dist" command rather than the default, distutils.command.dist.Dist and Bob's your uncle. (Disclaimer: this has never actually been tried in practice. It's a lovely design, though, if I may so so myself.) Another wee nit is that the Dist class as currently implemented has *two* methods for finding all files, which makes overriding slightly awkward. So sue me. > The distutils package must be *very* simple to gain acceptance. Requiring > people to write code, understand how to subclass CCompiler, or provide a > bazillion params to a setup() function is just not going to help. I think it's getting there for module developers. The setup.py for Distutils itself is as simple as I can imagine it being. The three example setup.py's included in the distribution (for PIL, mxDateTime, and Numeric) are a tad more verbose than they really need to be -- there's a bit too much bureaucracy involved in specifying how to build simple extension modules. That's definitely fixable, though, and once it's fixed I'll be very happy with the developer interface. The end-user interface is still a bit clunky because I picked some bad names for installation directory options, and some of the semantics behind certain options are mildly bogus. (Needs a bit more do-what- I-mean-not-what-I-say logic, which must be doled out with care but can go a long way in this sort of thing.) The bogosity was only revealed as I wrote the documentation (and the IPC8 paper on the Distutils), and I haven't touched the code since then. But these problems are on my mental to-do list. > Grain of salt time: until I step up and provide code to make distutils as > simple as I hope it would be, my comments should be viewed as "peanut > gallery" comments. Hey, toss all the peanuts you like. My hide's not quite as thick as an elephant's, but so far nothing on this sig has offended me too deeply. Greg From akuchlin@mems-exchange.org Thu Dec 2 17:39:53 1999 From: akuchlin@mems-exchange.org (Andrew M. Kuchling) Date: Thu, 2 Dec 1999 12:39:53 -0500 (EST) Subject: [Distutils] Compiling libraries In-Reply-To: <19991202123134.C12429@cnri.reston.va.us> References: <19991202123134.C12429@cnri.reston.va.us> Message-ID: <14406.44777.488060.540263@amarok.cnri.reston.va.us> Greg Ward writes: >I think it's getting there for module developers. The setup.py for >Distutils itself is as simple as I can imagine it being. The three This reminds me of something; I've looked at using Distutils for the PyXML package, and ran aground on compiling Expat, a library required for the other stuff. What I'd want to do is jump out of the Distutils framework and run 'cd expat ; make'. How should that be done? Writing my own subclass for the build command? Is there a 'run this set of shell commands' hook? Or should I just list every single .c file in Expat as a dependency for the relevant module? (After all, running shell commands is a Unix-ism.) -- A.M. Kuchling http://starship.python.net/crew/amk/ The past is always knocking at the door, trying to break through into today. -- Dr Occult, in BOOKS OF MAGIC #1 From gward@cnri.reston.va.us Thu Dec 2 17:43:07 1999 From: gward@cnri.reston.va.us (Greg Ward) Date: Thu, 2 Dec 1999 12:43:07 -0500 Subject: [Distutils] Questions about distutils strategy In-Reply-To: <3843EBF5.8FD2169B@amc.com>; from ians@amc.com on Tue, Nov 30, 1999 at 07:23:33AM -0800 References: <19991129222517.2670B1CE42@dinsdale.python.org> <3843EBF5.8FD2169B@amc.com> Message-ID: <19991202124306.D12429@cnri.reston.va.us> On 30 November 1999, Ian Searle said: > We are developing a cross platform debug tool for embedded systems > that uses Python as the central foundation. We distribute our product > on both solaris and windows nt. Thus, distutils looked attractive for > building our python extensions, which are mostly C++. This last > weekend, I was working on an extension, and ended up punting distutils > for two reasons: [Please limit your messages to < 80 columns; I had to reformat it down so it quotes nicely.] First caveat: if building C++ extensions with Distutils actually works, it's a happy accident. I had nothing to do with it. ;-) > 1) the documentation is not adequate for a moron like me. I needed to > add a vendor supplied object file to the link command, and struck out > on every attempt. The doc gave me some clues, but was not specific > enough to really help. I realize that this is version 0.1. I disagree -- the documentation isn't adequate for *anyone*, moron or not. You need to add an 'extra_objects' element to the dictionary that describes how to build your extension. Eg. if you now have: setup (... ext_modules = [('myext', {'sources': ['myext.c', 'support.c'] } )] ) then you will need to change this to setup (... ext_modules = [('myext', {'sources': ['myext.c', 'support.c'], 'extra_objects: ['vendor.o'] } )] ) In the code, see distutils.command.build_ext.BuildExt.build_extensions(). Doesn't look like extra_objects is mentioned in the USAGE file (oops). The usual disclaimer: this has not been used in practice, just tried out in artifical tests. Please let me know if it works or doesn't work. > 2) the main/compelling reason is that I have to debug the python > extensions. The extension implementation is normally tested, and > debugged prior to integration into Python. But the extension layer > often needs some debugging as we are interfacing C++ with STL > containers to Python data types. I can debug just fine using > distutils on Solaris/Linux, but cannot do the same on Windows. As far > as I can tell, you _have_ to have a DevStudio project setup to debug > anything under windows. Since our product will be delivered as a > standalone tool, including python, I do not need the distribution > facilities of distutils, only the development. But, once I have > developed a DevStudio project/workspace for an extension, there is > little motivation to use distutils. Ooh, yuck. And here I thought that invoking the MSVC command-line compiler directly was a feature. David Ascher was the original volunteer to write the MSVC interface, and his plan was (I think) to generate a project file and then somehow invoke the build system on that. When Perry Stoll came along with his MSVCCompiler class, David appeared happy to bow out... but maybe his idea needs to be resuscitated? Yuck. You Windows/MSVC experts got any good ideas? Greg -- Greg Ward - software developer gward@cnri.reston.va.us Corporation for National Research Initiatives 1895 Preston White Drive voice: +1-703-620-8990 Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913 From gward@cnri.reston.va.us Thu Dec 2 17:52:35 1999 From: gward@cnri.reston.va.us (Greg Ward) Date: Thu, 2 Dec 1999 12:52:35 -0500 Subject: [Distutils] Compiling libraries In-Reply-To: <14406.44777.488060.540263@amarok.cnri.reston.va.us>; from akuchlin@mems-exchange.org on Thu, Dec 02, 1999 at 12:39:53PM -0500 References: <19991202123134.C12429@cnri.reston.va.us> <14406.44777.488060.540263@amarok.cnri.reston.va.us> Message-ID: <19991202125234.E12429@cnri.reston.va.us> On 02 December 1999, Andrew M. Kuchling said: > This reminds me of something; I've looked at using Distutils for the > PyXML package, and ran aground on compiling Expat, a library required > for the other stuff. What I'd want to do is jump out of the Distutils > framework and run 'cd expat ; make'. How should that be done? > Writing my own subclass for the build command? Is there a 'run this > set of shell commands' hook? Or should I just list every single .c > file in Expat as a dependency for the relevant module? (After all, > running shell commands is a Unix-ism.) Not handled yet. I had the same problem writing the example setup.py for PIL; it simply doesn't know how to build /F's libimaging.a, so requires the user to do it. Blecchhh. The good news is that the Distutils compiler framework was designed to be able to handle this sort of thing. The bad news is I'm not sure how the hint "please build library X first" should go into the setup file. Perhaps a new command, "build_lib" or "build_clib" that -- like "build_ext" -- uses the compiler framework to build C code, but with a libX.a or X.lib file as the end result, rather than a Python extension module. My main concern is not limiting myself to C libraries; I *assume* C++ libraries are much the same, but I know for a fact that Java is very different (and yes, I still want to support Java extensions for JPython someday). For now, I would put something like this: if not os.path.exists libfile ("expat"): if os.plat == 'posix': system "cd expat ; make" else: raise SystemExit, "you have to build the expat library first" where the function 'libfile' might look like this: def libfile (libname): from distutils.ccompiler import new_compiler compiler = new_compiler () return compiler.library_filename (libname) Paying attention to the directory where libexpat.a (or whatever it's called) should live is left as an exercise for the reader. Hint: the 'library_filename()' method doesn't know about directories (hmmm). Greg From da@ski.org Thu Dec 2 17:54:28 1999 From: da@ski.org (David Ascher) Date: Thu, 2 Dec 1999 09:54:28 -0800 (Pacific Standard Time) Subject: [Distutils] Questions about distutils strategy In-Reply-To: <19991202124306.D12429@cnri.reston.va.us> Message-ID: On Thu, 2 Dec 1999, Greg Ward wrote: > > 2) the main/compelling reason is that I have to debug the python > > extensions. The extension implementation is normally tested, and > > debugged prior to integration into Python. But the extension layer > > often needs some debugging as we are interfacing C++ with STL > > containers to Python data types. I can debug just fine using > > distutils on Solaris/Linux, but cannot do the same on Windows. As far > > as I can tell, you _have_ to have a DevStudio project setup to debug > > anything under windows. Since our product will be delivered as a > > standalone tool, including python, I do not need the distribution > > facilities of distutils, only the development. But, once I have > > developed a DevStudio project/workspace for an extension, there is > > little motivation to use distutils. > > Ooh, yuck. And here I thought that invoking the MSVC command-line > compiler directly was a feature. David Ascher was the original > volunteer to write the MSVC interface, and his plan was (I think) to > generate a project file and then somehow invoke the build system on > that. When Perry Stoll came along with his MSVCCompiler class, David > appeared happy to bow out... but maybe his idea needs to be > resuscitated? Yuck. You Windows/MSVC experts got any good ideas? Someone mentioned my name? Sigh. The project file vs. Makefile debate is as old as the world (well, at least as old as MPW =). I haven't looked carefully enough at the innards of distutils to be sure, but glancing at msvccompiler.py, it looks like Perry did the simple thing (and praise him). That said, I'd be surprised if making a project/workspace file would be that hard given Perry's groundwork (and stealing the templates from compile.py). Alas, I have *no time* in the foreseeable future to do this. If someone is interested in doing it, however, I can help them with whatever knowledge I gathered doing compile.py. The hard thing will probably be to support all of the things which Windows developers expect, such as the ability to have Debug and Release builds (and CE builds, and ...). --david From akuchlin@mems-exchange.org Thu Dec 2 18:01:27 1999 From: akuchlin@mems-exchange.org (Andrew M. Kuchling) Date: Thu, 2 Dec 1999 13:01:27 -0500 (EST) Subject: [Distutils] Questions about distutils strategy In-Reply-To: References: <19991202124306.D12429@cnri.reston.va.us> Message-ID: <14406.46071.666016.239707@amarok.cnri.reston.va.us> David Ascher writes: >The hard thing will probably be to support all of the things which Windows >developers expect, such as the ability to have Debug and Release builds >(and CE builds, and ...). Is it really necessary for people to develop their code using Distutils, as opposed to developing in their preferred environment and then wrapping things up for distribution? If I was debugging a C module, I don't think I'd bother compiling it through the distutils; more likely I'd just write a Makefile.pre.in and Setup.in. -- A.M. Kuchling http://starship.python.net/crew/amk/ run-time. n. (QA testing) the moment when the programmer shouts "Must run!" and disappears. -- Stan Kelly-Bootle, _The Computer Contradictionary_ From da@ski.org Thu Dec 2 18:13:06 1999 From: da@ski.org (David Ascher) Date: Thu, 2 Dec 1999 10:13:06 -0800 (Pacific Standard Time) Subject: [Distutils] Questions about distutils strategy In-Reply-To: <14406.46071.666016.239707@amarok.cnri.reston.va.us> Message-ID: On Thu, 2 Dec 1999, Andrew M. Kuchling wrote: > David Ascher writes: > >The hard thing will probably be to support all of the things which Windows > >developers expect, such as the ability to have Debug and Release builds > >(and CE builds, and ...). > > Is it really necessary for people to develop their code using > Distutils, as opposed to developing in their preferred environment and > then wrapping things up for distribution? If I was debugging a C > module, I don't think I'd bother compiling it through the distutils; > more likely I'd just write a Makefile.pre.in and Setup.in. I doubt it's *necessary* but I agree with the sentiment that if you're going to be setting up the set of relationships between files, it'd be *nice* to be able to do it just once and have it work for both development & distribution. If you want to write code which is being developed on two operating systems at once, it can get tedious to maintain both the Makefile & project files. I do agree that this is fairly minor in the grand scheme of things, and if I were in charge, I'd put it off until 1.1 =). --david From jim@interet.com Thu Dec 2 19:02:25 1999 From: jim@interet.com (James C. Ahlstrom) Date: Thu, 02 Dec 1999 14:02:25 -0500 Subject: [Distutils] Questions about distutils strategy References: <19991202124306.D12429@cnri.reston.va.us> <14406.46071.666016.239707@amarok.cnri.reston.va.us> Message-ID: <3846C241.D192A2B9@interet.com> "Andrew M. Kuchling" wrote: > > David Ascher writes: > >The hard thing will probably be to support all of the things which Windows > >developers expect, such as the ability to have Debug and Release builds > >(and CE builds, and ...). > > Is it really necessary for people to develop their code using > Distutils, as opposed to developing in their preferred environment and > then wrapping things up for distribution? If I was debugging a C > module, I don't think I'd bother compiling it through the distutils; > more likely I'd just write a Makefile.pre.in and Setup.in. I am (among other things) a Windows developer, and I would never consider developing a C or C++ module without a project file in Visual C++. The project enables you to create Release and Debug versions. It has an excellent debugger and I even use it. Normally I do without debuggers. It has built-in Windows documentation which I can not do without. It helps navigate the dreadfully complex Windows compiler options. In my view, the program building part of distutils is only relevant to Unix. Which is fine with me, as I run Unix too. JimA From dubois1@llnl.gov Thu Dec 2 19:18:22 1999 From: dubois1@llnl.gov (Paul F. Dubois) Date: Thu, 2 Dec 1999 11:18:22 -0800 Subject: [Distutils] Questions about distutils strategy References: <14406.46071.666016.239707@amarok.cnri.reston.va.us> Message-ID: <99120211305900.13262@almanac> On Thu, 02 Dec 1999, Andrew M. Kuchling wrote: >=20 > Is it really necessary for people to develop their code using > Distutils, as opposed to developing in their preferred environment and > then wrapping things up for distribution? If I was debugging a C > module, I don't think I'd bother compiling it through the distutils; > more likely I'd just write a Makefile.pre.in and Setup.in. >=20 Absolutely. Using Distutils we have been able to automate the making of o= ur software. I have even just finished a little facility so that Pyfort can = make a Fortran extension (although I am going to need community help getting dat= a for the various Fortran compilers to flesh it out.)=20 The important point here is that people who are not NORMALLY developers c= an BE developers. Despite not having memorized the location of Makefile.pre.in,= and stie-packages, or even knowing that they exist, they can make and instal= l extensions.=20 For example, a user need only create a file like this: pyf('rs.pyf', 'rs', '.') name =3D 'eof_workbench' directory =3D '.' to make a Fortran extension using input file rs.pyf and loadling librs.a = from directory ., picking up .py files to go with it from . and installing it = as package eof_workbench. Assuming they call that file SETUP, they do pyfort -s SETUP python setup.py build_ext install and they can immediately use the package eof_workbench. Distutils doesn't have to be comprehensive. What Distutils does is lower = the bar for learning how to make extensions. From mwh21@cam.ac.uk Thu Dec 2 19:34:21 1999 From: mwh21@cam.ac.uk (Michael Hudson) Date: Thu, 2 Dec 1999 19:34:21 +0000 (GMT) Subject: [Distutils] Random bits In-Reply-To: <19991202123134.C12429@cnri.reston.va.us> Message-ID: On Thu, 2 Dec 1999, Greg Ward wrote: > On 02 December 1999, Greg Stein said: > > On Thu, 2 Dec 1999, Michael Hudson wrote: > > >... > > > class Acceptor: > > > def __and__(self,rhs): > > > return AndingAcceptor(self,rhs) > > > def __or__(self,rhs): > > > return OringAcceptor(self,rhs) > > > def __neg__(self): > > > return NotAcceptor(self) > > > > Sorry... but this is just silly. This is taking a simple problem of file > > selection and throwing a mess of procedural code at the thing. How is this > > *any* better than a simple list of files or file patterns? > > Once again, I completely agree with Greg here. Michael's scheme is, > ummm, interesting, but there is such a thing as being *too* > object-oriented. I have not paid a lot of attention to performance in > the Distutils, but I draw the line at severl method invocations to test > every file in the source tree. OK ... . > The MANIFEST.in file should provide the level of flexibility needed by > that all-important 80% of distributions. I think it's close now, but > the syntax is inscrutable and the implementation flaky. (And it doesn't > use MANIFEST.in, just MANIFEST.) The point of this thread is to fix > those problems, not come up with an entirely different scheme. Fine. What are the problems with the current system? I know exclusion of single files doesn't work, and you can provoke some dodgy looking tracebacks with malformed MANIFESTs. > The distutils have been designed so that if a module developer *does* > need some totally custom way to specify what files belong in his source > distribution, it's not a problem. In theory, it goes something like > this: > > * write a class that subclasses distutils.command.dist.Dist > * override the method that finds the files to distribute > * tell 'setup()' to attach your new class to the "dist" command > rather than the default, distutils.command.dist.Dist > > and Bob's your uncle. (Disclaimer: this has never actually been tried > in practice. It's a lovely design, though, if I may so so myself.) > > Another wee nit is that the Dist class as currently implemented has > *two* methods for finding all files, which makes overriding slightly > awkward. So sue me. My problem with this is that is a discontinous jump from the simple case to the complex one - although as the other Greg pointed out, that's a hard problem noone's got right, so just getting something that works for most cases is a more important goal. > > The distutils package must be *very* simple to gain acceptance. Requiring > > people to write code, understand how to subclass CCompiler, or provide a > > bazillion params to a setup() function is just not going to help. > > I think it's getting there for module developers. I certainly found it pleasant enough, MANIFEST nits aside. > The setup.py for Distutils itself is as simple as I can imagine it > being. The three example setup.py's included in the distribution (for > PIL, mxDateTime, and Numeric) are a tad more verbose than they really > need to be -- there's a bit too much bureaucracy involved in > specifying how to build simple extension modules. That's definitely > fixable, though, and once it's fixed I'll be very happy with the > developer interface. > > The end-user interface is still a bit clunky because I picked some bad > names for installation directory options, and some of the semantics > behind certain options are mildly bogus. (Needs a bit more do-what- > I-mean-not-what-I-say logic, which must be doled out with care but can > go a long way in this sort of thing.) The bogosity was only revealed as > I wrote the documentation (and the IPC8 paper on the Distutils), and I > haven't touched the code since then. But these problems are on my > mental to-do list. I would say it would be essential for python setup.py --help to produce something more helpful than option --help not recognized I found the simple act of installing distutils somewhere other than than the default to involve considerable head scratching and staring at the USAGE file. I'd have thought this would be the commonest option passed to install. Regards, Michael From gward@cnri.reston.va.us Thu Dec 2 22:03:45 1999 From: gward@cnri.reston.va.us (Greg Ward) Date: Thu, 2 Dec 1999 17:03:45 -0500 Subject: [Distutils] Random bits In-Reply-To: ; from mwh21@cam.ac.uk on Thu, Dec 02, 1999 at 07:34:21PM +0000 References: <19991202123134.C12429@cnri.reston.va.us> Message-ID: <19991202170344.A16875@cnri.reston.va.us> [I explain how a programmer could theoretically dodge the MANIFEST mechanism and do-it-himself] [Michael Hudson replies] > My problem with this is that is a discontinous jump from the simple case > to the complex one - although as the other Greg pointed out, that's a hard > problem noone's got right, so just getting something that works for most > cases is a more important goal. The discontinuous jump -- from the simple job of writing MANIFEST.in to the complex job of subclassing distutils.command.dist.Dist -- doesn't bother me. First of all, I don't think the complex case should be all that hard (but then, I seem to have an object-oriented brain). More importantly, you *can* do the complex case -- there's no brick wall barring your way from further progress, just a small hurdle to jump. If you want to do weird things with the Distutils, you have to jump through hoops -- hopefully small hoops, but the key point is that you shouldn't wind up bashing your head against the wall. That's why those last two letters of "setup.py" are so important... no brick walls. ;-) > I certainly found it pleasant enough, MANIFEST nits aside. Thanks! > I would say it would be essential for > > python setup.py --help > > to produce something more helpful than > > option --help not recognized D'oh! Somehow that one slipped through my clue-filter. Consider it noted... > I found the simple act of installing distutils somewhere other than > than the default to involve considerable head scratching and staring at > the USAGE file. I'd have thought this would be the commonest option passed > to install. Yes, there definitely needs to be an easier grade from the "trivial" case to slightly customized to heavily customized cases. This is mostly a documentation problem, I think. (Although I have to actually *try* some of those slightly- and heavily-customized cases before I can be certain...) Greg From mwh21@cam.ac.uk Thu Dec 2 22:47:38 1999 From: mwh21@cam.ac.uk (Michael Hudson) Date: Thu, 2 Dec 1999 22:47:38 +0000 (GMT) Subject: [Distutils] Random bits In-Reply-To: <19991202170344.A16875@cnri.reston.va.us> Message-ID: On Thu, 2 Dec 1999, Greg Ward wrote: > > I found the simple act of installing distutils somewhere other than > > than the default to involve considerable head scratching and staring at > > the USAGE file. I'd have thought this would be the commonest option passed > > to install. > > Yes, there definitely needs to be an easier grade from the "trivial" > case to slightly customized to heavily customized cases. This is mostly > a documentation problem, I think. (Although I have to actually *try* > some of those slightly- and heavily-customized cases before I can be > certain...) Further mucking about shows that python setup.py -v install_py --install-dir=/home/mwh21/src/python/ does what I want ... but python setup.py -nv install --install-dir=/home/mwh21/src/python/ produces the dreaded option --install-dir not recognized While python setup.py -nv install --install-site-lib=/home/mwh21/src/python/ works, and python setup.py -nv install_py --install-site-lib=/home/mwh21/src/python/ doesn't ... I don't think that's helpful. OTOH, I don't see how to make it better. I guess one would need to know what people actually would be wanting this command to do on a regular basis and make that easy. As a data point, I like to chuck everything experimental in ~/src/python; I think currently for a mixed extension/Python package I'd have to type something along the lines of python setup.py install --install-site-platlib=~/src/python \ --install-site-lib=~/src/python which is a bit unwieldy. Maybe I should make an alias for that... Would it be reasonable to have an "interactive" mode, or am I just being silly again? Cheers, Michael From fdrake@acm.org Thu Dec 2 22:52:13 1999 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Thu, 2 Dec 1999 17:52:13 -0500 (EST) Subject: [Distutils] Random bits In-Reply-To: References: <19991202170344.A16875@cnri.reston.va.us> Message-ID: <14406.63517.775597.810232@weyr.cnri.reston.va.us> Michael Hudson writes: > Further mucking about shows that [Lots of examples of busted behavior elided...] I tihnk this really shows that many of these things really need to be global options and that the local options thing makes very little sense. Time to simplify! > Would it be reasonable to have an "interactive" mode, or am I just being > silly again? Yes. ;) -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From gstein@lyra.org Thu Dec 2 23:45:50 1999 From: gstein@lyra.org (Greg Stein) Date: Thu, 2 Dec 1999 15:45:50 -0800 (PST) Subject: [Distutils] Compiling libraries In-Reply-To: <19991202125234.E12429@cnri.reston.va.us> Message-ID: On Thu, 2 Dec 1999, Greg Ward wrote: >... > if not os.path.exists libfile ("expat"): > if os.plat == 'posix': > system "cd expat ; make" > else: > raise SystemExit, "you have to build the expat library first" Just to be annoying, I'll point out that the "system" approach won't work ... Expat's makefile doesn't create a libexpat.a :-) Of course, reasonable people add in that line to the Makefile before bundling Expat in their distro. :-) Cheers, -g -- Greg Stein, http://www.lyra.org/ From tim_one@email.msn.com Tue Dec 7 05:11:21 1999 From: tim_one@email.msn.com (Tim Peters) Date: Tue, 7 Dec 1999 00:11:21 -0500 Subject: [Distutils] Questions about distutils strategy In-Reply-To: <19991202124306.D12429@cnri.reston.va.us> Message-ID: <001501bf4071$81217980$88a0143f@tim> [Ian Searle] > ... > I can debug just fine using distutils on Solaris/Linux, but cannot do > the same on Windows. As far as I can tell, you _have_ to have a > DevStudio project setup to debug anything under windows. [Greg Ward] > Ooh, yuck. And here I thought that invoking the MSVC command-line > compiler directly was a feature. ... It is. The DevStudio debugger doesn't care how an .exe got built (provided you passed the compiler the right switches to get debug info generated). The main Windows project I work on is built by a hand-written makefile run by a homegrown Win32 variant of GNU make; DevStudio plays no role in it unless & until I want to run under the debugger. Goodness, you can even use the DevStudio Build -> Start Debug -> Attach to Process ... menu item to start debugging an arbitrary process already running on the system, source code or not, originally in a DevStudio language or not. If it wasn't compiled with MS-style symbol info, though, you can't do much more than step thru the machine code. Notwithstanding, many hardcore Windows weenies *prefer* doing development under DevStudio. But I'd say that's a topic for the DevUtils SIG . ian-will-figure-out-how-to-use-devstudio-long-before-you'll-figure- out-how-to-automate-it-ly y'rs - tim From as544@freenet.toronto.on.ca Mon Dec 6 13:02:50 1999 From: as544@freenet.toronto.on.ca (T-Muthy Meddleten) Date: Mon, 06 Dec 1999 08:02:50 -0500 Subject: [Distutils] Distutils integration In-Reply-To: <19991202115103.A12429@cnri.reston.va.us> References: <6H4P4gHAAcqH092yn@vex.net> <19991129085701.A7807@cnri.reston.va.us> <19991202115103.A12429@cnri.reston.va.us> Message-ID: <6P7S4gHAAABZ092yn@vex.net> Thu, 2 Dec 1999 11:51:04 -0500, Greg Ward wrote: >out of existence (or so it seemed to me when I was trying desperately to >track down a tarball for Perl 5.001m, rather than the 5.001 tarball and See, you needed a nice meta-archive to stitch all them damned collections together! <-; >Perl, go visit that site *now*. From the top, you can browse by module I have visited. You are right, it is very nice. Very clean, very fast. Looks to be high quality stuff. Very well organised for the most part. (My only quibble being that i find the search results a little difficult to scan---and there seems to be no sorting options---i have sort by date/label ascending/descending... and that's only because i've been too lazy to implement the 'relevancy' system i've had in mind, as of yet---the idea is to basically weight the various fields in different ways, assuming matches in certain fields are more indicitive of what people actually are looking for... also i wanted to put in custom sorting for the category listings---but, i go off on a vapourware tangent). (Also i've got boolean capabilities --- surprisingly search.cpan doesn't. They have a simplfied regex --- actually my postgress search is completely regex based ... but no one knows it (which can lead to problems, like whens someone searched for "c++" yesterday... boom). Heh. But that's mostly by incident than by design... one may argue that these things are generally overkill for this type of searching, of course---i have many ideas for improving the search engine... just haven't got around to fooling around with them all yet). >by author name (or ID -- every CPAN contributor has a user ID), module Every "owner" has an ID in my database too, rest assured. They just don't know it yet. <-; Every "owner" in my database also has a randomly generated password. They don't know that yet either. Heh. No need for them to know, it doesn't do anything; but i put it in because it seemed like it might be useful for something sometime... >name, or distribution name. You can search the text of all the >documentation for every module uploaded to CPAN. Ah, now you've given me more devious ideas... mmmm. When i'm coding the link checker, why not suck back all the pages and index them while i'm at it. (-: Interesting. Heh. Yes i know, not the same as documentation search. Perhaps i should add yet another URL field to each item: URL to documentation. (But then probably no one would fill it out---just like so far no one has filled out the "download" url when making submissions---they have no real insentive to. They might fill out the download url however if they had a 'distutils' compatable package and Parnassus flagged it as such. Likewise if Parnassus implemented "documentation" search people might be more motivated to enter a "documentation" url in order to be a part of the database... on of them chicken and egg things... needs to be implemented before anyone will support it... if they would at all, that is). I shall now say yet another something you will disagree with: i hate POD! However, alas, i shall concede that POD is certainly a hell of a lot better than what python has---virtually nothing. Pythondoc is quite nice, but no real standards for formatting, and has been dormant a long time. Certainly I can't deny that the documentation search there is not very nice. But it's not really possible for python in the current state of things---even if we had a central archive. The central archive would still tend to be a mess. <-; Witness ftp.python.org. This is not really an archive vs. meta-archive issue. >trying to remember why I use Python. Oh yeah, it has actual syntactic >support for OO programming, that's why. ;-) Painful when such a crappy language has such a nice resource eh. I sympathise with your pain. >solutions: scan the database regularly and rigorously, bitching at This is my plan. Though i'm still thinking about the details. For instance, another complication of a meta archive is that one doesn't know the state of all the various servers that resources are on... perhaps one goes down for a day or two, but comes back up. My idea is to have 'degrees' of brokenness. Sort of. First give a broken link maybe a day or two to see if it comes back (maybe). Then squirel away the broken links and re-check them periodically. Then there's also the automated spam---a great way to make new friends! >downloads stuff from developer's pages and puts it somewhere whose links >*won't* break. You know this would be pretty easy to do also really, for the most part. If one had the server space. Mirror the category structure, and just autoamtically go fetch things and drop them in the directory. Something to think about perhaps. >trying to find some free Java classes (because Sun somehow forgot that >"the programming language for the Internet" might need to do MIME ARGH. Finding java stuff is hell! I agree. I haven't done it for a while, but i still recall the trauma of the last time i tried. Seems SUN mysteriously left out all the good stuff! That's one of the things that really attracted me to python: it seemed like it included all the good stuff! Or very large subset of it, at least. >decoding -- oops). There is a big meta-archive at gamelan.com, but >for everything I found -- bam, broken links everywhere. Yes, don't they publish a book or something, so people can try and find stuff in there? <-; >careful link-policing! Ah linking policy. On that note, yes, although in my previous message i advocated the meta-style archive on the basis that in my opinion poeple feel freer to add stuff---it's less official, less constraining. But of course this does have the downside of generally less quality control. I'm sure CPAN has fairly high quality submissions on average (without imposing any external controls). I mean, anyone who takes the trouble to package up their stuff for CPAN is probably not going to do it frivolously. Whereas anyone might submit anything to Parnassus on a whim, in any state, and half the time i have no idea what it is. I had thought of trying to institute some sort of rating system---yes, another field in threw in the database, "just in case"; but probably it wouldn't be used much. But who knows... maybe in the future. (I think freshmeat has something like this? For now the rating system is the number of "clicks". ) >I will continue to argue for just the right amount of bondage, >discipline, structure, and bureaucracy to achieve that level of >automation. Oh, i agree completely. >The trick is using the *bare minimum* of bureaucracy that And i agree there too even more. (-: >listen to people like you and Greg Stein arguing for anarchy. ;-) I wouldn't say i'm arguing for anarchy. After all Vaults of Parnassus is a totalitarian regime as it stands. Though hopefully not fascist. Anyhow, interesting (if not provoking---which is even better) thoughts. Thanks for your brutal criticsm. (-: VoP's only been up for a matter of weeks. And as I was saying to Martijn recently, there were around 700 click throughs for resources (these are clicks going off the site, not views of Parnassus pages) during the week after i reset the stats (over a thousand now --- hasn't quite been two weeks yet)... that's a thousand python resources this month that people might not have seen, bothered to look for, or in some cases (dare i say many?) even known to have existed. Even if the site shut down tomorrow, i think some good as been done at least. -- ..,.,.,,..,...,.,.,.,.,.,.,,,,.,.,.,...,.,.,..,.,,.,..,..,.,..,.,.,.. Tim Middletin =-=-= not all who wander are lost =-=-= x @ veX . net `'~`'~`'~`'~`'~`'~`'~`'~`'~`'~`'~`'~`'~`'~`'~`'~`'~`'~`'~`'~`'~`'~`'~ * Dec 6th * International Day of Rotting Cabbage From as544@freenet.toronto.on.ca Mon Dec 6 13:05:54 1999 From: as544@freenet.toronto.on.ca (T-Mithy Moddletin) Date: Mon, 06 Dec 1999 08:05:54 -0500 Subject: [Distutils] Distutils integration In-Reply-To: <19991202115415.B12429@cnri.reston.va.us> References: <19991202115415.B12429@cnri.reston.va.us> Message-ID: Thu, 2 Dec 1999 11:54:15 -0500, Greg Ward wrote: >On 29 November 1999, Greg Stein said: >> Keep doing what you're doing! Don't stop! :-) Ah, how nice to have a Good Greg to counterbalance the Nasty Greg (with all his scary bondange toys!) <-; Thanks. Somehow this message didn't make it to my mailbox though; i only see it via Greg W's quoted reply... >That version number parser is lurking in the Distutils distribution >(class LooseVersion in module distutils.version). Currently it fails >its test suite because we never did work out those differences of Ah, i'll leave that to you guys to battle over. I don't have a need, that I know of, for version parsing yet. We shall see what the future holds. -- .,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,. Tim Moddletun =-=-=-=- with love and squalor -=-=-=-= x @ veX . net ``'`''`'`'''`'```'`'`'`'`''`'``'`'`'`'`'`''`'`'`''```'`'`'`''`''``'`' From ians@amc.com Tue Dec 7 13:47:29 1999 From: ians@amc.com (Ian Searle) Date: Tue, 07 Dec 1999 05:47:29 -0800 Subject: [Distutils] Questions about distutils strategy References: <001501bf4071$81217980$88a0143f@tim> Message-ID: <384D0FF0.73DC5450@amc.com> I would have to agree with Tim's last statement. Just yesterday I figured out how to run the debugger without having a project/workspace, hooray! Thanks, -Ian Tim Peters wrote: > > [Ian Searle] > > ... > > I can debug just fine using distutils on Solaris/Linux, but cannot do > > the same on Windows. As far as I can tell, you _have_ to have a > > DevStudio project setup to debug anything under windows. > > [Greg Ward] > > Ooh, yuck. And here I thought that invoking the MSVC command-line > > compiler directly was a feature. ... > > It is. The DevStudio debugger doesn't care how an .exe got built (provided > you passed the compiler the right switches to get debug info generated). > The main Windows project I work on is built by a hand-written makefile run > by a homegrown Win32 variant of GNU make; DevStudio plays no role in it > unless & until I want to run under the debugger. Goodness, you can even use > the DevStudio Build -> Start Debug -> Attach to Process ... menu item to > start debugging an arbitrary process already running on the system, source > code or not, originally in a DevStudio language or not. If it wasn't > compiled with MS-style symbol info, though, you can't do much more than step > thru the machine code. > > Notwithstanding, many hardcore Windows weenies *prefer* doing development > under DevStudio. But I'd say that's a topic for the DevUtils SIG . > > ian-will-figure-out-how-to-use-devstudio-long-before-you'll-figure- > out-how-to-automate-it-ly y'rs - tim > > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > http://www.python.org/mailman/listinfo/distutils-sig From jim@interet.com Tue Dec 7 15:00:36 1999 From: jim@interet.com (James C. Ahlstrom) Date: Tue, 07 Dec 1999 10:00:36 -0500 Subject: [Distutils] Questions about distutils strategy References: <001501bf4071$81217980$88a0143f@tim> Message-ID: <384D2114.9485867E@interet.com> Tim Peters wrote: > It is. The DevStudio debugger doesn't care how an .exe got built (provided > you passed the compiler the right switches to get debug info generated). > The main Windows project I work on is built by a hand-written makefile run > by a homegrown Win32 variant of GNU make; DevStudio plays no role in it > unless & until I want to run under the debugger. Goodness, you can even use > the DevStudio Build -> Start Debug -> Attach to Process ... menu item to > start debugging an arbitrary process already running on the system, source > code or not, originally in a DevStudio language or not. Very interesting. I didn't know that. Probably neither does the average Windows developer. > If it wasn't > compiled with MS-style symbol info, though, you can't do much more than step > thru the machine code. Ooops, not at all what people will want. > Notwithstanding, many hardcore Windows weenies *prefer* doing development > under DevStudio. But I'd say that's a topic for the DevUtils SIG . I think we may be kidding ourselves. It is not a matter of "prefer". Distutils is not at all compatible with DevStudio. Suppose you add a file to the project in DevStudio. You will have to make the parallel change by hand in Distutils. People use (or should use) _ASSERT(), so there must be Debug and Release versions no matter if the debugger is used or not. Built in to DevStudio, a file edit (at best) in Distutils. And to top it off, you need on-line documentation for Windows anyway, so you need DevStudio or equivalant even if you do learn Distutils. People in PythonDev[:] may put up with this, but if we go to main-stream Windows developers and say "do this our way" they will say "no thanks". Distutils makes sense on Unix where things are done with makefiles. Why do we even care if Windows developers make Python extensions in DevStudio? Jim Ahlstrom From gward@cnri.reston.va.us Tue Dec 7 16:26:58 1999 From: gward@cnri.reston.va.us (Greg Ward) Date: Tue, 7 Dec 1999 11:26:58 -0500 Subject: [Distutils] Random bits In-Reply-To: <14406.63517.775597.810232@weyr.cnri.reston.va.us>; from fdrake@acm.org on Thu, Dec 02, 1999 at 05:52:13PM -0500 References: <19991202170344.A16875@cnri.reston.va.us> <14406.63517.775597.810232@weyr.cnri.reston.va.us> Message-ID: <19991207112657.A18779@cnri.reston.va.us> On 02 December 1999, Fred L. Drake, Jr. said: > > Michael Hudson writes: > > Further mucking about shows that > [Lots of examples of busted behavior elided...] > > I tihnk this really shows that many of these things really need to > be global options and that the local options thing makes very little > sense. I beg to differ -- I'll have to take a closer look at what's going on with Michael's examples of brokenness, but I like to think they can be fixed without completely tossing the existing design. See "perldoc ExtUtils::MakeMaker" for my rationale behind having most behaviour controlled by command options. 22 pages of documentation describing all of MakeMaker's options (which are all global) is a bit overwhelming; I wanted to be able to categorize things a bit. [Michael again] > Would it be reasonable to have an "interactive" mode, or am I just being > silly again? Interesting notion. Would this just be a shell for the Distutils commands, eg. ./setup.py --interactive > build [...output of 'build' command...] > install [...output of 'install' command...] > quit or did you have something else in mind? Greg -- Greg Ward - software developer gward@cnri.reston.va.us Corporation for National Research Initiatives 1895 Preston White Drive voice: +1-703-620-8990 Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913 From gward@cnri.reston.va.us Tue Dec 7 16:32:15 1999 From: gward@cnri.reston.va.us (Greg Ward) Date: Tue, 7 Dec 1999 11:32:15 -0500 Subject: [Distutils] Questions about distutils strategy In-Reply-To: <384D2114.9485867E@interet.com>; from jim@interet.com on Tue, Dec 07, 1999 at 10:00:36AM -0500 References: <001501bf4071$81217980$88a0143f@tim> <384D2114.9485867E@interet.com> Message-ID: <19991207113214.B18779@cnri.reston.va.us> On 07 December 1999, James C. Ahlstrom said: > Distutils makes sense on Unix where things are done with > makefiles. Why do we even care if Windows developers make > Python extensions in DevStudio? The whole point of Distutils is to allow Joe Unix Geek to develop module distributions that will build and install painlessly on non-Unix systems, *and* Jane Windows Weenie to develop module distributions that will build and install painlessly on non-Windows systems. If Jane is writing Windows-only extensions, then nobody's forcing her to use Distutils and maintain a setup script (although it would be nice). Ditto for Joe writing Unix-only extensions. That means that Unix geeks can't use makefiles to distribute their Python modules, and it means that Windows weenies can't use Microsoft's project files to distribute their Python modules. The bad news is that if you really really want to use the local convention for automated building (both of which have advantages), you have to maintain a separate setup.py script. The good news is that setup.py is portable and written in a real programming language. Greg -- Greg Ward - software developer gward@cnri.reston.va.us Corporation for National Research Initiatives 1895 Preston White Drive voice: +1-703-620-8990 Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913 From fdrake@acm.org Tue Dec 7 16:34:44 1999 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Tue, 7 Dec 1999 11:34:44 -0500 (EST) Subject: [Distutils] Random bits In-Reply-To: <19991207112657.A18779@cnri.reston.va.us> References: <19991202170344.A16875@cnri.reston.va.us> <14406.63517.775597.810232@weyr.cnri.reston.va.us> <19991207112657.A18779@cnri.reston.va.us> Message-ID: <14413.14116.584966.859600@weyr.cnri.reston.va.us> I said: > I tihnk this really shows that many of these things really need to > be global options and that the local options thing makes very little > sense. Greg Ward writes: > I beg to differ -- I'll have to take a closer look at what's going on > with Michael's examples of brokenness, but I like to think they can be > fixed without completely tossing the existing design. I'm not suggesting that these things shouldn't be options, only that they should be global options to the setup.py script, not local to each sub-command. For options that apply to a specific sub-command, go ahead and make them command-local. For options that describe the Python installation that the package is being added to, use global options. These are used to describe the target environment, and there's no good reason not to group them in the global options space. -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From gward@cnri.reston.va.us Tue Dec 7 16:42:54 1999 From: gward@cnri.reston.va.us (Greg Ward) Date: Tue, 7 Dec 1999 11:42:54 -0500 Subject: [Distutils] Random bits In-Reply-To: <14413.14116.584966.859600@weyr.cnri.reston.va.us>; from fdrake@acm.org on Tue, Dec 07, 1999 at 11:34:44AM -0500 References: <19991202170344.A16875@cnri.reston.va.us> <14406.63517.775597.810232@weyr.cnri.reston.va.us> <19991207112657.A18779@cnri.reston.va.us> <14413.14116.584966.859600@weyr.cnri.reston.va.us> Message-ID: <19991207114254.A18814@cnri.reston.va.us> On 07 December 1999, Fred L. Drake, Jr. said: > I'm not suggesting that these things shouldn't be options, only that > they should be global options to the setup.py script, not local to > each sub-command. > For options that apply to a specific sub-command, go ahead and make > them command-local. For options that describe the Python installation > that the package is being added to, use global options. These are > used to describe the target environment, and there's no good reason > not to group them in the global options space. I think that goes hand-in-hand with figuring out what's really needed, what's most commonly needed, and fixing up the installation options to reflect those (perceived) needs. That and rethinking the "dist" command (in particular, the MANIFEST/MANIFEST.in syntax and semantics) are on my list for Distutils 0.2. Greg From guido@CNRI.Reston.VA.US Tue Dec 7 16:42:58 1999 From: guido@CNRI.Reston.VA.US (Guido van Rossum) Date: Tue, 07 Dec 1999 11:42:58 -0500 Subject: [Distutils] Questions about distutils strategy In-Reply-To: Your message of "Tue, 07 Dec 1999 11:32:15 EST." <19991207113214.B18779@cnri.reston.va.us> References: <001501bf4071$81217980$88a0143f@tim> <384D2114.9485867E@interet.com> <19991207113214.B18779@cnri.reston.va.us> Message-ID: <199912071642.LAA22978@eric.cnri.reston.va.us> Greg Ward: > The whole point of Distutils is to allow Joe Unix Geek to develop module > distributions that will build and install painlessly on non-Unix > systems, *and* Jane Windows Weenie to develop module distributions that > will build and install painlessly on non-Windows systems. If Jane is > writing Windows-only extensions, then nobody's forcing her to use > Distutils and maintain a setup script (although it would be nice). > Ditto for Joe writing Unix-only extensions. > > That means that Unix geeks can't use makefiles to distribute their > Python modules, and it means that Windows weenies can't use Microsoft's > project files to distribute their Python modules. The bad news is that > if you really really want to use the local convention for automated > building (both of which have advantages), you have to maintain a > separate setup.py script. The good news is that setup.py is portable > and written in a real programming language. Good summary of the distutil charter. I would add a third objective: *users* on all platforms are tired of having to understand the intricate details of building and installing Python modules, and want module distributions that "just work". This includes platform specific distributions. --Guido van Rossum (home page: http://www.python.org/~guido/) From mwh21@cam.ac.uk Tue Dec 7 17:10:52 1999 From: mwh21@cam.ac.uk (Michael Hudson) Date: Tue, 07 Dec 1999 17:10:52 +0000 Subject: [Distutils] Random bits Message-ID: Greg Ward wrote on Tue, Dec 7, 1999, 4:26 pm [snip] >[Michael again] >> Would it be reasonable to have an "interactive" mode, or am I just being >> silly again? > >Interesting notion. Would this just be a shell for the Distutils >commands, eg. > > ./setup.py --interactive > > build > [...output of 'build' command...] > > install > [...output of 'install' command...] > > quit > >or did you have something else in mind? More or less that; I was thinking of the script you get when you run CPAN for the first time - where you get asked lots of questions about where things are, and most of the time you just hit return a lot. Something more like this in outline: $ python setup.py --interactive > install * Installing some_dist... ** Building somedist ** Where do you want to build? [./build]> ** output of build process * Where do you want to install the pure Python modules? [/usr/lib/python1.5/site-packages]> ~/src/python * Where do you want to install extension modules? [/home/mwh21/src/python]> * output of build process as I said, I'm not particularly convinced this is to be desired; it can certainly be added at a later date. Cheers, Michael From mhammond@skippinet.com.au Wed Dec 8 01:49:17 1999 From: mhammond@skippinet.com.au (Mark Hammond) Date: Wed, 8 Dec 1999 12:49:17 +1100 Subject: [Distutils] Questions about distutils strategy In-Reply-To: <001501bf4071$81217980$88a0143f@tim> Message-ID: <015d01bf411e$70da6b10$0501a8c0@bobcat> > unless & until I want to run under the debugger. Goodness, > you can even use > the DevStudio Build -> Start Debug -> Attach to Process ... > menu item to > start debugging an arbitrary process already running on the > system Or use the NT task manager and select "Debug" when right-clicking on a process. Or, for Python programmers, add a quick "win32api.DebugBreak()" call. > ian-will-figure-out-how-to-use-devstudio-long-before-you'll-figure- > out-how-to-automate-it-ly y'rs - tim Ahh - but we already have - David's compile.py knows how to use COM to automate DevStudio builds :-) In fact, with the COM extensions we could create and build a DevStudio project from scratch I believe. But I dont think we should. Just to echo the rest of the articles in this thread: * If someone uses DevStudio to build their apps, it is likely they are targetting Windows only, so distutils is unlikely to offer great advantages. It will be a long time indeed before you can release source code for Windows apps under the assumption that all systems have a C compiler available to build it. * If per chance they _are_ also targetting Unix, then they must also be maintaining seperate Unix build scripts - still no loss here - move the Unix stuff to distutils and either leave DevStudio alone, or move to make based builds in Windows too. Still the users choice, and nothing to lose from what they currently do - only possibly things to gain if they go that route. * As Guido mentioned, on any platform, they should be able to get an extension building in almost no time (just like compile.py pretty-much does now). Windows users in this category are unlikely to be DevStudio wizards, so it is still a win for them. In a nutshell, I cant see _any_ good reasons to offer DevStudio support to distutils. Mark. From robin@alldunn.com Wed Dec 8 02:12:18 1999 From: robin@alldunn.com (Robin Dunn) Date: Tue, 7 Dec 1999 18:12:18 -0800 Subject: [Distutils] Questions about distutils strategy References: <015d01bf411e$70da6b10$0501a8c0@bobcat> Message-ID: <001501bf4121$a85a7550$0301a8c0@easystreet.com> > > Ahh - but we already have - David's compile.py knows how to use COM to > automate DevStudio builds :-) In fact, with the COM extensions we > could create and build a DevStudio project from scratch I believe. > But I dont think we should. > Don't even need COM. The project files are just text after all. The wxWindows team uses tmake from Troll Tech to generate makefiles for all the various Windows compilers, Makefile.in for GNU configure, and VC++ workspace/project files. Since it's a perl based tool I couldn't stomach using it myself and since distutils wasn't usable yet I created my own script that can make makefiles for VC++ or Unix based systems and can also drive running make. Works pretty good. -- Robin Dunn Software Craftsman robin@AllDunn.com http://AllDunn.com/robin/ http://AllDunn.com/wxPython/ Check it out! From s341625@student.uq.edu.au Wed Dec 8 02:14:02 1999 From: s341625@student.uq.edu.au (Anthony Pfrunder) Date: Wed, 8 Dec 1999 12:14:02 +1000 (GMT+1000) Subject: [Distutils] Questions about distutils strategy In-Reply-To: <015d01bf411e$70da6b10$0501a8c0@bobcat> Message-ID: Hi, But is there a way to allow the win32 extensions to build *without* needing Visual Studio MFC code? I have a python script that converts dsw/dsp files into (semi) standard makefiles. These makefiles can be driven to work with MSDev, cygwin, ming or unix by changing a config option. I was hoping to compile the win32 extensions using ming and it worked - up to a point. It needed source from MS Dev which I no longer have :( Cheers, Anthony Pfrunder From s341625@student.uq.edu.au Wed Dec 8 02:15:20 1999 From: s341625@student.uq.edu.au (Anthony Pfrunder) Date: Wed, 8 Dec 1999 12:15:20 +1000 (GMT+1000) Subject: [Distutils] Questions about distutils strategy In-Reply-To: <001501bf4121$a85a7550$0301a8c0@easystreet.com> Message-ID: Hi, I think all we Windows Zopisters have our own build systems ;) I call this good timing ;) Cheers, Anthony Pfrunder From mhammond@skippinet.com.au Wed Dec 8 02:15:32 1999 From: mhammond@skippinet.com.au (Mark Hammond) Date: Wed, 8 Dec 1999 13:15:32 +1100 Subject: [Distutils] Questions about distutils strategy In-Reply-To: Message-ID: <016201bf4122$1c6c3410$0501a8c0@bobcat> > But is there a way to allow the win32 extensions to build *without* > needing Visual Studio MFC code? Apart from Pythonwin, the win32 extensions should not require MFC at all. > I was hoping to compile the win32 extensions using ming and > it worked - up > to a point. It needed source from MS Dev which I no longer have :( What specifically were the problems? [Not really distutils specific - just mail me with the response] Mark. From tim_one@email.msn.com Wed Dec 8 07:46:02 1999 From: tim_one@email.msn.com (Tim Peters) Date: Wed, 8 Dec 1999 02:46:02 -0500 Subject: [Distutils] Questions about distutils strategy In-Reply-To: <384D2114.9485867E@interet.com> Message-ID: <000201bf4150$46749da0$5aa2143f@tim> [Tim] > ... > Goodness, you can even use the DevStudio Build -> Start Debug -> > Attach to Process ... menu item to start debugging an arbitrary > process already running on the system, source code or not, > originally in a DevStudio language or not. [James C. Ahlstrom] > Very interesting. I didn't know that. Probably neither > does the average Windows developer. They don't need to know it. I was explaining an extreme. In normal usage, the worst that's required is that you open the .exe you want to debug from within DevStudio and click "Go". >> If it wasn't compiled with MS-style symbol info, though, you >> can't do much more than step thru the machine code. > Ooops, not at all what people will want. Again explaining an extreme. If you use MS's compiler to compile your stuff from a cmdline, you get MS-style symbol info, and debugging is the same as if you had compiled it using DevStudio (DevStudio compilation is just a massive GUI around a cmdline compiler & linker!). Of *course* MS's debugger doesn't understand non-MS symbol info, any more than gdb understands MS's style. So don't do that . >> Notwithstanding, many hardcore Windows weenies *prefer* doing >> development under DevStudio. But I'd say that's a topic for >> the DevUtils SIG . > I think we may be kidding ourselves. It is not a matter of "prefer". Sure it is. DevStudio also has a menu entry to generate a makefile (of MS's odd nmake flavor). I often set up personal projects using DevStudio, and then switch to a generated makefile so I can run overnight builds and tests from .bat scripts. > Distutils is not at all compatible with DevStudio. Suppose you > add a file to the project in DevStudio. You will have to make > the parallel change by hand in Distutils. People use (or should > use) _ASSERT(), so there must be Debug and Release versions no > matter if the debugger is used or not. Built in to DevStudio, > a file edit (at best) in Distutils. The difference between Debug and Release is entirely in switches passed to the compiler and linker; makefiles can handle that fine based on target name (or envars, or anything else a makefile can see; have DevStudio generate a makefile to see how MS does it). As I hope will become clearer soon, though, I don't grasp why any of this is a Distutils issue. > And to top it off, you need on-line documentation for Windows > anyway, so you need DevStudio or equivalant even if you do > learn Distutils. Sorry, but I don't understand where this is coming from. As a Windows Python Guy, I have one of five scenarios in mind for "distribution": 1) The audience is purely Windows developers. Then I ship a zip file containing source and an MS project file, and leave Distutils out of it entirely. 2) The audience is purely Windows end users. Then I ship pre-compiled binaries, because they can't possibly deal with compilation themselves (they don't have compilers!). In this case I'm not sure whether Distutils can help (it would have to become an Installshield clone to meet expectations); but, ragardless, compilation is again not an issue for distribution. 3) The audience is Python programmers "in general", or the audience is me, and the product is a C extension module. This is where I expect to use Distutils, and hope that others do too. An MS project file doesn't do my Unix friends any good, any more than their fiddly platform-dependent gmake files help me, and binaries suck for similar reasons. Most interesting extension modules I've seen have been written by Unix weenies -- and *when you're lucky* their home page has a contributed Windows .pyd just two releases out of date . 4) The audience is Python end-users "in general", and the product is pure Python. I think this is the most important one for Distutils to address, and compilation isn't a part of it. So far, though, what Gordon is doing seems more appropriate than what Distutils has been up to. I hope his work gets folded into this. 5) The audience is Python end-users "in general", and the product is some mix of Python and C extension modules. This is hard. You have to ship binaries to meet Windows expectations; you have to ship source to meet Unixish ones; and the more popular Linux gets, the more the Unix dweebs will be left whining without a clue about the changing nature of their customer base <0.7 wink -- but over on Python-Help the sight of a Linux user who doesn't know how to compile is no longer rare>. > People in PythonDev[:] may put up with this, but if we go to > main-stream Windows developers and say "do this our way" they > will say "no thanks". Main-stream Windows developers have no way at all to distribute a x-platform app now, so their choice is between "our way" and "no way". If they're not interested in x-platform distribution, I indeed don't see what Distutils *could* offer them in the way of helpful code (except in case #4 above -- where compilation (& so also DevStudio) isn't an issue). > Distutils makes sense on Unix where things are done with > makefiles. Why do we even care if Windows developers make > Python extensions in DevStudio? I don't care at all, provided they have no interest in sharing their work with non-Windows people. If they do want to share, they need to do more work (their Windows binaries aren't going to run on a SPARC ), and Distutils can help with that. life-will-be-simpler-when-windows-is-the-only-os-ly y'rs - tim From robin@alldunn.com Wed Dec 8 08:11:02 1999 From: robin@alldunn.com (Robin Dunn) Date: Wed, 8 Dec 1999 00:11:02 -0800 Subject: [Distutils] Questions about distutils strategy References: <000201bf4150$46749da0$5aa2143f@tim> Message-ID: <028001bf4153$c6057280$0301a8c0@easystreet.com> > 5) The audience is Python end-users "in general", and the product is some > mix of Python and C extension modules. This is hard. You have to ship > binaries to meet Windows expectations; you have to ship source to meet > Unixish ones; and the more popular Linux gets, the more the Unix dweebs will > be left whining without a clue about the changing nature of their customer > base <0.7 wink -- but over on Python-Help the sight of a Linux user who > doesn't know how to compile is no longer rare>. > Or who don't WANT to compile and would "much rather just use an RPM." I've had several of both types of people using wxPython. -- Robin Dunn Software Craftsman robin@AllDunn.com http://AllDunn.com/robin/ http://AllDunn.com/wxPython/ Check it out! From gward@cnri.reston.va.us Wed Dec 8 14:07:21 1999 From: gward@cnri.reston.va.us (Greg Ward) Date: Wed, 8 Dec 1999 09:07:21 -0500 Subject: [Distutils] Questions about distutils strategy In-Reply-To: <000201bf4150$46749da0$5aa2143f@tim>; from tim_one@email.msn.com on Wed, Dec 08, 1999 at 02:46:02AM -0500 References: <384D2114.9485867E@interet.com> <000201bf4150$46749da0$5aa2143f@tim> Message-ID: <19991208090720.A19528@cnri.reston.va.us> On 08 December 1999, Tim Peters said: > The difference between Debug and Release is entirely in switches passed to > the compiler and linker; makefiles can handle that fine based on target name > (or envars, or anything else a makefile can see; have DevStudio generate a > makefile to see how MS does it). As I hope will become clearer soon, > though, I don't grasp why any of this is a Distutils issue. It could be a minor Distutils issue: I've toyed with the idea of "--debug" or "--optimize" flags (or maybe "--release"?) to the 'build_ext' command that would translate to appropriate compiler switches. I know how to do this for the "generic Unix C compiler" implemented by the UnixCCompiler class, but someone else would have to do it it for MSVCCompiler. > 1) The audience is purely Windows developers. Then I ship a zip file > containing source and an MS project file, and leave Distutils out of it > entirely. Probably appropriate, although in my more megalomaniacal moments I tend to think, "Who needs make? Who needs IDEs? You can do it ALL with Python, a C compiler, and Distutils!" (In an idle moment the other day, I started thinking about a Distutils command to build Perl extensions... I got over it pretty quickly though.) > 2) The audience is purely Windows end users. Then I ship pre-compiled > binaries, because they can't possibly deal with compilation themselves (they > don't have compilers!). In this case I'm not sure whether Distutils can > help (it would have to become an Installshield clone to meet expectations); > but, ragardless, compilation is again not an issue for distribution. Creating binary distributions is in the plans, although they'll be called "built distributions" because an RPM that contains only .py (and maybe .pyc) files isn't really "binary". The plan decided on at that fateful Developer's Day session *over a year ago* (wow!) was that we'd figure out something for Windows with WISE Installer (or whatever it's called). I think the theory was that somehow we could write Python code that would magically generate a Windows installer. I certainly haven't done anything about that, although at some point I expect I'll have to walk downstairs and grill Guido about Windows installers for Python until he gives up and tells me to bug someone else. FWIW, the interface I envision is *something* like this: $ ./setup.py bdist --format=rpm [...create a spec file, run rpm -B...] $ ./setup.py bdist --format=wise error: can't create Windows installer under Unix Oops! Let's try that second one again C:\> ./setup.py bdist --format=wise [...somehow magically create a WISE installer...] Hmmm, this is starting to look like yet another argument for system-wide and user-specific config files to supply default values for things like the bdist format. (And, for that matter, the dist format, which can be one of 'gztar', 'ztar', 'tar', or 'zip'.) > 4) The audience is Python end-users "in general", and the product is pure > Python. I think this is the most important one for Distutils to address, > and compilation isn't a part of it. So far, though, what Gordon is doing > seems more appropriate than what Distutils has been up to. I hope his work > gets folded into this. Here the distinction between "source distributions" and "build distributions" gets fuzzy. I actually think it's important and worthwhile to provide "built" distributions of pure Python distributions -- not for technical reasons, but for social/political/usability reasons. Eg. if I can install a mixed C/Python distribution from an RPM or a WISE installer, then I should be able to do the same for a pure Python distribution. You and I will know that it's a waste of disk space to offer both versions, and a waste of machine time to have dist-bots churning out pure Python built distributions from source distributions, but it's necessary for a consistent user interface on each platform supported by the "bdist" command. I assume that "what Gordon is doing" is the Python archive stuff? My attitude towards that is the same as it is towards all of these funky new things coming down the pike: interesting, keep an eye on it, maybe try it out if I get a few minutes... *but* Distutils support will have to wait until there is One Standard Way of doing things. The whole point of Distutils is to be the One Standard Way; I certainly don't claim that copying .py files into directories and compiling them to .pyc files is the only way to install Python module distributions, but until these issues (archive format, imputils, etc.) are worked out and finalized then Distutils won't (officially) support them. Of course, I think it would be really cool if competing archive formats were presented to the world with implementations in the form of Distutils command classes, but that's probably my megalomaniacal tendencies coming out again. > 5) The audience is Python end-users "in general", and the product is some > mix of Python and C extension modules. This is hard. You have to ship > binaries to meet Windows expectations; you have to ship source to meet > Unixish ones; and the more popular Linux gets, the more the Unix dweebs will > be left whining without a clue about the changing nature of their customer > base <0.7 wink -- but over on Python-Help the sight of a Linux user who > doesn't know how to compile is no longer rare>. As Guido said on python-dev, a Distutils "appdist" command is probably the answer. Or maybe "appbdist", I dunno. I'm not sure if separate commands are really needed, or if the "build", "install", "dist", and "bdist" commands will grow up to recognize Python applications rather than just module distributions. That's a bit of a ways off, though: I said at the beginning that I want to handle module distributions first, and then worry about applications. Maybe by that time, the "Python archive format", imputils, one-file-Python-distributions, etc. will be more stable. Greg -- Greg Ward - software developer gward@cnri.reston.va.us Corporation for National Research Initiatives 1895 Preston White Drive voice: +1-703-620-8990 Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913 From jim@interet.com Wed Dec 8 14:21:59 1999 From: jim@interet.com (James C. Ahlstrom) Date: Wed, 08 Dec 1999 09:21:59 -0500 Subject: [Distutils] Questions about distutils strategy References: <001501bf4071$81217980$88a0143f@tim> <384D2114.9485867E@interet.com> <19991207113214.B18779@cnri.reston.va.us> Message-ID: <384E6987.CB8A0890@interet.com> Greg Ward wrote: > The whole point of Distutils is to allow Joe Unix Geek to develop module > distributions that will build and install painlessly on non-Unix This is a wonderfully succinct explanation, and I think I understand this now. Thanks. From the Windows side, it is now clear that DistUtils is useful for programmers making software which is portable to Windows and Unix. Such software is difficult to write, and if it contains a GUI component, it is very difficult to write. Most commercial developers think portable means it runs on both 95 and NT. I realize everyone understands this, but I have to conclude that DistUtils will not be helpful in trying to "sell" most commercial developers on the idea that they should use Python. JimA From jim@interet.com Wed Dec 8 14:54:49 1999 From: jim@interet.com (James C. Ahlstrom) Date: Wed, 08 Dec 1999 09:54:49 -0500 Subject: [Distutils] Questions about distutils strategy References: <015d01bf411e$70da6b10$0501a8c0@bobcat> Message-ID: <384E7139.61562DB4@interet.com> Mark Hammond wrote: > Just to echo the rest of the articles in this thread: Just to echo your echo... > * If someone uses DevStudio to build their apps, it is likely they are > targetting Windows only, so distutils is unlikely to offer great > advantages. Yes. > * If per chance they _are_ also targetting Unix, then they must also > be maintaining seperate Unix build scripts - still no loss here - move > the Unix stuff to distutils and either leave DevStudio alone, or move > to make based builds in Windows too. Still the users choice, and > nothing to lose from what they currently do - only possibly things to > gain if they go that route. Yes. > In a nutshell, I cant see _any_ good reasons to offer DevStudio > support to distutils. I guess you mean no reason for DevStudio support, but DistUtils still needs Windows compiler (command line) support. Then I agree with this last point. I don't see DistUtils being used except in cases where a Windows and Unix build is required. But that does happen. With wxWindows it happens Big Time. There is still an advantage to coding in DevStudio, makeing the DistUtils files, and pushing the DistUtils button to build multiple versions. JimA From jim@interet.com Wed Dec 8 15:24:16 1999 From: jim@interet.com (James C. Ahlstrom) Date: Wed, 08 Dec 1999 10:24:16 -0500 Subject: [Distutils] Questions about distutils strategy References: <000201bf4150$46749da0$5aa2143f@tim> Message-ID: <384E7820.C2761A41@interet.com> Tim Peters wrote: > [James C. Ahlstrom] > > Very interesting. I didn't know that. Probably neither > > does the average Windows developer. > > They don't need to know it. I was explaining an extreme. > ... > Again explaining an extreme. Yes, understood. Extremes are good for sharpening issues. > > I think we may be kidding ourselves. It is not a matter of "prefer". > > Sure it is. DevStudio also has a menu entry to generate a makefile (of MS's > odd nmake flavor). I often set up personal projects using DevStudio, and > then switch to a generated makefile so I can run overnight builds and tests > from .bat scripts. Yes, we write the makefiles by hand so we can build from Korn shell scripts. Microsoft's eccentric nmake format is a constant annoyance. But mostly Windows people stay in DevStudio. > > And to top it off, you need on-line documentation for Windows > > anyway, so you need DevStudio or equivalant even if you do > > learn Distutils. > > Sorry, but I don't understand where this is coming from. It means that even if I need a Unix build too, I usually develop in DevStudio because of the on-line help. But for small projects, I develop on Linux because of the large setup annoyance of DevStudio. In other words, I have a poor memory and like built-in help. > As a WindowsPython Guy, I have one of five scenarios > in mind for "distribution": This is very useful because you have extended the discussion from just compiling to distributing. > 1) The audience is purely Windows developers... > 2) The audience is purely Windows end users... > 3) The audience is Python programmers "in general"... > 4) The audience is Python end-users "in general"... > 5) The audience is Python end-users "in general"... Others have commented at length. Suffice it to say I agree. > > Distutils makes sense on Unix where things are done with > > makefiles. Why do we even care if Windows developers make > > Python extensions in DevStudio? > > I don't care at all, provided they have no interest in sharing their work > with non-Windows people. If they do want to share, they need to do more > work (their Windows binaries aren't going to run on a SPARC ), and > Distutils can help with that. Yes, this is the most common case where DistUtils can help in program development (as opposed to distribution). If only it were a more common case! JimA From gward@cnri.reston.va.us Sun Dec 12 17:25:19 1999 From: gward@cnri.reston.va.us (Greg Ward) Date: Sun, 12 Dec 1999 12:25:19 -0500 Subject: [Distutils] Distutils 0.1.2 almost ready Message-ID: <19991212122517.A683@cnri.reston.va.us> Hi folks -- I've finally gone on a bug-fixing spree to clean up all the easy problems in Distutils 0.1.1. The harder problems will have to wait for 0.2, but for now I'm going to release these fixes as 0.1.2. Before I do that, I've put out a code snapshot with all the fixes -- please download it and give it a try, especially if you reported problems with 0.1.1 or if you run Windows. You'll find the snapshot at: http://www.python.org/sigs/distutils-sig/implementation.html Thanks -- Greg -- Greg Ward - software developer gward@cnri.reston.va.us Corporation for National Research Initiatives 1895 Preston White Drive voice: +1-703-620-8990 Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913 From gward@cnri.reston.va.us Mon Dec 13 21:43:50 1999 From: gward@cnri.reston.va.us (Greg Ward) Date: Mon, 13 Dec 1999 16:43:50 -0500 Subject: [Distutils] One more small bugfix Message-ID: <19991213164349.E401@cnri.reston.va.us> Hmmm, from the deafening silence, either a) everyone has tried out yesterday's snapshot and found it to be so utterly mundane and boring as to be unworthy of comment, or b) you were all waiting for today's snapshot, which fixes one teeny-weeny little bug. Anyways, get it from http://www.python.org/sigs/distutils-sig/implementation.html Unless someone finds a bug, I'll probably toss 0.1.2 over the wall tomorrow. Windows people, *please* try this snapshot out! (Especially Windows people with a compiler and the NumPy, PIL, or mxDateTime sources handy -- give one or all of the example setup scripts a whirl. They work for me under Linux...) Greg From gward@cnri.reston.va.us Thu Dec 16 01:31:45 1999 From: gward@cnri.reston.va.us (Greg Ward) Date: Wed, 15 Dec 1999 20:31:45 -0500 Subject: [Distutils] ANNOUNCE: Distutils 0.1.2 released Message-ID: <19991215203145.A3622@cnri.reston.va.us> Phew, just in time for Christmas. Get your copy today from http://www.python.org/sigs/distutils-sig/ Many bugs fixed in this one. Works great on Linux and Solaris; I didn't hear back from anyone about whether it works on Windows, so I'm taking a chance. Here's the entry from the CHANGES file: * changes to command-line semantics: - verbose mode is now the default - added help options (and generation of help text), both globally and for each command - better usage message * anywhere that accepts/requires a list of strings now also accepts a tuple of strings (but lists of tuples still have to be lists -- there are limits) * fixes to "build_py" command - explicitly ensure that the setup script (sys.argv[0]) is never included with the modules to be installed - do *not* preserve file mode when copying .py files into the build tree (was preserving 0444 permissions [read-only], which caused subsequent installation of the same module distribution to fail) - several silly bugs that showed up when building simple, non-packagized distributions * fixes to the "dist" command - correct behaviour with filename pattern regexes - don't blow up if MANIFEST missing, just warn and carry on - blow away "distribution" tree after making archive file(s) Enjoy! Thanks to everyone who spotted bugs (especially Guido for a very useful checklist). Greg -- Greg Ward - software developer gward@cnri.reston.va.us Corporation for National Research Initiatives 1895 Preston White Drive voice: +1-703-620-8990 Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913 From gstein@lyra.org Thu Dec 16 03:45:52 1999 From: gstein@lyra.org (Greg Stein) Date: Wed, 15 Dec 1999 19:45:52 -0800 (PST) Subject: [Distutils] ANNOUNCE: Distutils 0.1.2 released In-Reply-To: <19991215203145.A3622@cnri.reston.va.us> Message-ID: On Wed, 15 Dec 1999, Greg Ward wrote: > Phew, just in time for Christmas. Get your copy today from > > http://www.python.org/sigs/distutils-sig/ > > Many bugs fixed in this one. Works great on Linux and Solaris; I didn't > hear back from anyone about whether it works on Windows, so I'm taking a > chance. Who cares whether it is chancy or not? This is a symptom that I've seen from many people. "Oh! I can't release yet... it might break." Or another favorite "Here is a pre-release, please test it and then I'll make a real release." Screw that. Release a version. If that breaks, then release another. This whole tentative thing just slows everything down. Holding back releases doesn't really buy a person anything. I remember somebody on python-list didn't want to release some code because they didn't "clean it up" and/or document it. Six months later, they still hadn't released the code -- meaning nobody got *any* advantage out of that code. Even if you release crap, then somebody may still be able to use it. Maybe they can even help you fix it up. But the notion of "well, I need to do X before sending out a copy" often translates to "I'll never send out a copy." Cheers, -g -- Greg Stein, http://www.lyra.org/ From gward@cnri.reston.va.us Thu Dec 16 15:03:50 1999 From: gward@cnri.reston.va.us (Greg Ward) Date: Thu, 16 Dec 1999 10:03:50 -0500 Subject: [Distutils] ANNOUNCE: Distutils 0.1.2 released In-Reply-To: ; from gstein@lyra.org on Wed, Dec 15, 1999 at 07:45:52PM -0800 References: <19991215203145.A3622@cnri.reston.va.us> Message-ID: <19991216100350.A4304@cnri.reston.va.us> On 15 December 1999, Greg Stein said: > Who cares whether it is chancy or not? > > This is a symptom that I've seen from many people. "Oh! I can't release > yet... it might break." Or another favorite "Here is a pre-release, please > test it and then I'll make a real release." In my own defense, I think I like the code snapshot followed by a real release a few days later. That shows the world that things are happening, and gives me time to take care of the bureaucracy of making a release: make sure everything's checked in and tagged, update the changelog, update the readme, update the web pages, and so forth. Of course my self-imposed bureaucracy *does* slow down making releases -- I would have a hard time putting out new versions every other day because I insist on having a readable, grammatical, up-to-date README file, and I am really keen on having everything under CVS control and appropriately tagged. These are the little things that make trying out new software a lot easier on people; I for one am sick to death of moderately good software that is hobbled by a lousy, out-of-date README or poorly-written documentation. I prefer to take a few hours more and put out quality information as well as quality code. IOW, yes: release early and release often. But how early and how often are matters of personal style, and not everyone can proceed at a Linus-esque breakneck pace of new releases every couple of days. Greg From guido@CNRI.Reston.VA.US Thu Dec 16 15:27:33 1999 From: guido@CNRI.Reston.VA.US (Guido van Rossum) Date: Thu, 16 Dec 1999 10:27:33 -0500 Subject: [Distutils] ANNOUNCE: Distutils 0.1.2 released In-Reply-To: Your message of "Wed, 15 Dec 1999 19:45:52 PST." References: Message-ID: <199912161527.KAA08308@eric.cnri.reston.va.us> > > > Who cares whether it is chancy or not? > > This is a symptom that I've seen from many people. "Oh! I can't release > yet... it might break." Or another favorite "Here is a pre-release, please > test it and then I'll make a real release." > > Screw that. Release a version. If that breaks, then release another. This > whole tentative thing just slows everything down. Holding back releases > doesn't really buy a person anything. > > I remember somebody on python-list didn't want to release some code > because they didn't "clean it up" and/or document it. Six months later, > they still hadn't released the code -- meaning nobody got *any* advantage > out of that code. Even if you release crap, then somebody may still be > able to use it. Maybe they can even help you fix it up. But the notion of > "well, I need to do X before sending out a copy" often translates to "I'll > never send out a copy." > > I realize it's just a rant. In this case (distutils) your advice is correct. (I usually paraphrase it as "release early, release often".) However there are other situations, like core Python itself, where it's really useful to have stable releases -- if only for those users who won't touch anything with "beta" in its name. I still hear from people who haven't upgraded to 1.5.2. I wonder if perhaps for those cases (where there's a demand for stable releases) some other strategy could be used? Such as labeling releases "stable" after the fact? Or what Linus seems to do with the Linux kernel (even = stable, odd = development; or was it the other way around?). --Guido van Rossum (home page: http://www.python.org/~guido/) From fdrake@acm.org Thu Dec 16 16:03:51 1999 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Thu, 16 Dec 1999 11:03:51 -0500 (EST) Subject: [Distutils] ANNOUNCE: Distutils 0.1.2 released In-Reply-To: <199912161527.KAA08308@eric.cnri.reston.va.us> References: <199912161527.KAA08308@eric.cnri.reston.va.us> Message-ID: <14425.3431.984317.225586@weyr.cnri.reston.va.us> Guido van Rossum writes: > who won't touch anything with "beta" in its name. I still hear from > people who haven't upgraded to 1.5.2. You mean not everyone works off the CVS version? Sheesh, I thought the version number was just legacy... How can anyone live without string methods? ;) > I wonder if perhaps for those cases (where there's a demand for stable > releases) some other strategy could be used? Such as labeling > releases "stable" after the fact? Or what Linus seems to do with the > Linux kernel (even = stable, odd = development; or was it the other > way around?). You have the even/odd thing right. The problem with it is that it really requires just as much planning as the release strategy you're already using, it's just that the labels are semantically loaded without being "syntactically" distinct. I don't see that it's an especially good way of doing things in general, however well it's worked for the Linux kernel community. (Note that I'm not saying it's a bad way, just that the benefits are not very clear.) I think there are a few reasonable approaches to the stable/devel dichotomy: - Use labels like "alpha", "beta", "release candidate", etc., possibly shortened to "a", "b", "rc", or whatever, to indicate various levels of stability in development/test releases. Use two- or three-part numeric designations for "stable" releases. This is exactly what you've been doing with Python itself, and is what appears to be most common, at least in the Unix world. - Use either a "build number" approach similar to that used by PythonWin, and then declare things "stable" by re-releasing with a new number and only README/documentation changes and declaring stability as part of the release announcement. Multi-part version numbers may still be useful here, but maybe no more than two parts. I'd expect the first part to grow a little faster, so the distinction between "Python" and "Python 2" would probably have to be made in a different way ("Python++" ;). - Use "build number" or multipart numeric versions, and declare stability after the fact. I'm much less enamored of this, simply because I'd like to see the stability indication as part of the release. This is probably the worst possible case for people who don't follow the language news much at all (a group which will probably grow the most as Python penetration increases). So don't use this one. Essentially, I don't see any compelling reason to change the approach to versioning; anything with a version number of less than one should be considered preliminary (Rainer Menzner always included "beta" as part of pre-1.0 release numbers, just to be completely clear about the status.) But I agree, more frequent releases of the distutils package would be useful. Part of that is a matter of disseminating bug fixes and feature improvements, but part of it is also maintaining interest and visibility for the project. Having an alpha or beta isn't any good if no one is interested in it. -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From sanner@scripps.edu Thu Dec 16 17:02:04 1999 From: sanner@scripps.edu (Michel Sanner) Date: Thu, 16 Dec 1999 09:02:04 -0800 Subject: [Distutils] ANNOUNCE: Distutils 0.1.2 released In-Reply-To: Greg Ward "Re: [Distutils] ANNOUNCE: Distutils 0.1.2 released" (Dec 16, 10:03am) References: <19991215203145.A3622@cnri.reston.va.us> <19991216100350.A4304@cnri.reston.va.us> Message-ID: <991216090204.ZM484329@noah.scripps.edu> Greg, Your doing an excellent job ! don't worry about G Stein's comment ... he is not ALWAYS right ! and IMHO, I do not think that this word of caution in you mail was worth posting a message ! -Michel On Dec 16, 10:03am, Greg Ward wrote: > Subject: Re: [Distutils] ANNOUNCE: Distutils 0.1.2 released > On 15 December 1999, Greg Stein said: > > Who cares whether it is chancy or not? > > > > This is a symptom that I've seen from many people. "Oh! I can't release > > yet... it might break." Or another favorite "Here is a pre-release, please > > test it and then I'll make a real release." > > In my own defense, I think I like the code snapshot followed by a real > release a few days later. That shows the world that things are > happening, and gives me time to take care of the bureaucracy of making a > release: make sure everything's checked in and tagged, update the > changelog, update the readme, update the web pages, and so forth. > > Of course my self-imposed bureaucracy *does* slow down making releases > -- I would have a hard time putting out new versions every other day > because I insist on having a readable, grammatical, up-to-date README > file, and I am really keen on having everything under CVS control and > appropriately tagged. These are the little things that make trying out > new software a lot easier on people; I for one am sick to death of > moderately good software that is hobbled by a lousy, out-of-date README > or poorly-written documentation. I prefer to take a few hours more and > put out quality information as well as quality code. > > IOW, yes: release early and release often. But how early and how often > are matters of personal style, and not everyone can proceed at a > Linus-esque breakneck pace of new releases every couple of days. > > Greg > > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > http://www.python.org/mailman/listinfo/distutils-sig >-- End of excerpt from Greg Ward -- ----------------------------------------------------------------------- >>>>>>>>>> AREA CODE CHANGE <<<<<<<<< we are now 858 !!!!!!! Michel F. Sanner Ph.D. The Scripps Research Institute Assistant Professor Department of Molecular Biology 10550 North Torrey Pines Road Tel. (858) 784-2341 La Jolla, CA 92037 Fax. (858) 784-2860 sanner@scripps.edu http://www.scripps.edu/sanner ----------------------------------------------------------------------- From gstein@lyra.org Thu Dec 16 18:21:54 1999 From: gstein@lyra.org (Greg Stein) Date: Thu, 16 Dec 1999 10:21:54 -0800 (PST) Subject: [Distutils] ANNOUNCE: Distutils 0.1.2 released In-Reply-To: <199912161527.KAA08308@eric.cnri.reston.va.us> Message-ID: On Thu, 16 Dec 1999, Guido van Rossum wrote: >... > I realize it's just a rant. In this case (distutils) your advice is > correct. (I usually paraphrase it as "release early, release often".) True. I prefer that phrase, too, but I used it on JimA earlier in the day or the previous day. I didn't want to sound like a broken record :-). But that is why I moved into mode... it seems like the mindset was spreading :-) I've railed at AMK for it, too :-), when he was talking about 0.5.1pre1 or whatever, rather than just releasing 0.5.1 and doing an 0.5.2 if there was a problem. > However there are other situations, like core Python itself, where > it's really useful to have stable releases -- if only for those users > who won't touch anything with "beta" in its name. I still hear from > people who haven't upgraded to 1.5.2. But this doesn't explain why there isn't a 1.5.3b1, 1.5.3b2, etc. Or 1.6.0a1 or whatever (maybe "d" or "r" for dev release, as opposed to alpha). There are some people would like the releases rather than using CVS. Some people can't even use CVS because of firewall issues. Of course, an alternative is snapshot-tarballs of the CVS repository. But a snapshot could *really* be broken; something like 1.6.0d1 says "well, it's a development release, but I've hit a good point between some changes." > I wonder if perhaps for those cases (where there's a demand for stable > releases) some other strategy could be used? Such as labeling > releases "stable" after the fact? Or what Linus seems to do with the > Linux kernel (even = stable, odd = development; or was it the other > way around?). Yes: even are stable (e.g. 1.0, 1.2, 2.0, 2.2). The odd numbers are for development. Linus is currently working 2.3.x, but declared in the past couple days that things will be wrapping up to move towards 2.4. Once he thinks it is ready, he'll start off with 2.4.0pre1, pre2, pre3... At some point the "pre" suffix will drop and 2.4.0 will be released. You might have a bit of problem using that mechanism since the current stable release is 1.5 :-). Once 1.6 hits the street, then you could start doing 1.9 releases (dev) and shift to 2.0 once it is "stable". Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein@lyra.org Thu Dec 16 18:32:06 1999 From: gstein@lyra.org (Greg Stein) Date: Thu, 16 Dec 1999 10:32:06 -0800 (PST) Subject: [Distutils] ANNOUNCE: Distutils 0.1.2 released In-Reply-To: <19991216100350.A4304@cnri.reston.va.us> Message-ID: On Thu, 16 Dec 1999, Greg Ward wrote: > On 15 December 1999, Greg Stein said: > > Who cares whether it is chancy or not? > > > > This is a symptom that I've seen from many people. "Oh! I can't release > > yet... it might break." Or another favorite "Here is a pre-release, please > > test it and then I'll make a real release." > > In my own defense, I think I like the code snapshot followed by a real :-) ... it wasn't truly aimed at you, which is why I munged the To: to be the SIG rather than you :-) But hey... we can talk about you if you'd like... hehe. > release a few days later. That shows the world that things are > happening, and gives me time to take care of the bureaucracy of making a > release: make sure everything's checked in and tagged, update the > changelog, update the readme, update the web pages, and so forth. "happening" is also shown thru multiple releases. And yes, I agree: there is a "release tax" that needs to be paid. I think you get used it to it, though, if you release often. I know that mod_dav releases are pretty cheap for me nowadays... there is a "rhythm" you might say. > Of course my self-imposed bureaucracy *does* slow down making releases > -- I would have a hard time putting out new versions every other day > because I insist on having a readable, grammatical, up-to-date README > file, and I am really keen on having everything under CVS control and > appropriately tagged. These are the little things that make trying out > new software a lot easier on people; I for one am sick to death of > moderately good software that is hobbled by a lousy, out-of-date README > or poorly-written documentation. I prefer to take a few hours more and > put out quality information as well as quality code. I understand. I would counter that some people would still find it useful, even if the README is out of date, or there are some tweaky problems in it. Note that other people might submit README fixes if it bugs them too much. > IOW, yes: release early and release often. But how early and how often > are matters of personal style, and not everyone can proceed at a > Linus-esque breakneck pace of new releases every couple of days. Sure. But I'll reserve the right to prod people here and there when they start to look all bottled up :-) Cheers, -g -- Greg Stein, http://www.lyra.org/ From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Thu Dec 16 18:50:49 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Thu, 16 Dec 1999 13:50:49 -0500 (EST) Subject: [Python-Dev] Re: [Distutils] ANNOUNCE: Distutils 0.1.2 released References: <199912161527.KAA08308@eric.cnri.reston.va.us> Message-ID: <14425.13449.954026.960703@anthem.cnri.reston.va.us> >> I wonder if perhaps for those cases (where there's a demand for >> stable releases) some other strategy could be used? Such as >> labeling releases "stable" after the fact? Or what Linus seems >> to do with the Linux kernel (even = stable, odd = development; >> or was it the other way around?). I really dislike the odd/even distinction for exactly this reason. -Barry From skip@mojam.com (Skip Montanaro) Thu Dec 16 19:05:05 1999 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Thu, 16 Dec 1999 13:05:05 -0600 (CST) Subject: [Python-Dev] Re: [Distutils] ANNOUNCE: Distutils 0.1.2 released In-Reply-To: <14425.13449.954026.960703@anthem.cnri.reston.va.us> References: <199912161527.KAA08308@eric.cnri.reston.va.us> <14425.13449.954026.960703@anthem.cnri.reston.va.us> Message-ID: <14425.14305.907618.978628@dolphin.mojam.com> >>> Or what Linus seems to do with the Linux kernel (even = stable, odd >>> = development; or was it the other way around?). BAW> I really dislike the odd/even distinction for exactly this reason. It's one saving grace is that it is a uniform format. There are no "optional" tokens like "pre", "alpha", "beta", etc for the most part. To remember which way it is, I find it useful to execute "uname -r", check the second digit, then look down at my shirt for a pocket protector. The two pieces of information together work for me. I currently get "2.2.13-4mdk" from uname. I don't even have a pocket, let alone a pocket protector, so even numbers must be stable releases... ;-) Skip Montanaro | http://www.mojam.com/ skip@mojam.com | http://www.musi-cal.com/ 847-971-7098 | Python: Programming the way Guido indented... From bwarsaw@python.org Thu Dec 16 23:10:11 1999 From: bwarsaw@python.org (Barry A. Warsaw) Date: Thu, 16 Dec 1999 18:10:11 -0500 (EST) Subject: [Python-Dev] Re: [Distutils] ANNOUNCE: Distutils 0.1.2 released References: <199912161527.KAA08308@eric.cnri.reston.va.us> <14425.13449.954026.960703@anthem.cnri.reston.va.us> <14425.14305.907618.978628@dolphin.mojam.com> Message-ID: <14425.29011.429867.485070@anthem.cnri.reston.va.us> >>>>> "SM" == Skip Montanaro writes: SM> To remember which way it is, I find it useful to execute SM> "uname -r", check the second digit, then look down at my shirt SM> for a pocket protector. The two pieces of information SM> together work for me. I currently get "2.2.13-4mdk" from SM> uname. I don't even have a pocket, let alone a pocket SM> protector, so even numbers must be stable releases... What do you do if it's the second Thursday after the full moon, and the local hockey team has just skated to a 3-3 tie? -Barry From akuchlin@mems-exchange.org Sun Dec 19 02:43:19 1999 From: akuchlin@mems-exchange.org (A.M. Kuchling) Date: Sat, 18 Dec 1999 21:43:19 -0500 Subject: [Distutils] Disposition of C extensions and packages Message-ID: <199912190243.VAA03844@207-172-57-180.s180.tnt2.ann.va.dialup.rcn.com> [Crossposted to xml-sig, distutils-sig] I'm working on getting the XML-SIG's CVS tree to install using the current version of the Distutils. Right now there are two C extensions, sgmlop.so and pyexpat.so, and they're installed under xml/parsers/ . It's hard to handle this case using the distutils code as it stands, because it expects to put extensions into a build/platlib/ directory, from which they'll be installed into site-packages. I can coerce setup.py into installing them into xml/parsers/, by subclassing the BuildExt command and setting build_dir myself: from distutils.command.build_ext import BuildExt class XMLBuildExt(BuildExt): def set_default_options (self): BuildExt.set_default_options( self ) self.build_dir = 'lib/build/xml/parser' setup (name = "PyXML", cmdclass = {'build_ext':XMLBuildExt}, ...) You also have to subclass the Install command and set build_dir there; I've trimmed that code. It's really clunky.\ Note that this scheme will break once there are C modules that need to be installed anywhere other than xml/parsers/, because build_dir is being hardwired without knowledge of what module is being compiled. Questions: 1) A general Python question about packaging style: Is mixing C extensions and Python modules in one package tree a bad idea? It makes the whole tree platform-dependent, which is probably annoying for sites maintaining Python installation for different architectures. 2) Another general question, this time o: how should this be handled? Should C extensions always be effectively top-level, and therefore go into site-packages? Should there be an xml package holding .py files, and an X package holding all the C extensions? (X = 'plat_xml', 'xml_binary', or something like that) 3) XML-SIG question: should I go ahead and change it (since I first changed it to use xml.parsers.sgmlop)? 4) Distutils question: is this a problem with the Distutils code that needs fixing? I suspect not; if the tools make it difficult to do stupid things like mix .py and .so files, that's a good thing. -- A.M. Kuchling http://starship.python.net/crew/amk/ The Kappamaki, a whaling research ship, was currently researching the question: How many whales can you catch in one week? -- Terry Pratchett & Neil Gaiman, _Good Omens_ From mal@lemburg.com Sun Dec 19 23:06:58 1999 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 20 Dec 1999 00:06:58 +0100 Subject: [Distutils] Disposition of C extensions and packages References: <199912190243.VAA03844@207-172-57-180.s180.tnt2.ann.va.dialup.rcn.com> Message-ID: <385D6512.23665CAC@lemburg.com> "A.M. Kuchling" wrote: > > Questions: > > 1) A general Python question about packaging style: Is mixing > C extensions and Python modules in one package tree a bad > idea? It makes the whole tree platform-dependent, which is > probably annoying for sites maintaining Python installation > for different architectures. I have been using that setup for two years now with all of my mx extensions and so far it has been working great. If you maintain packages with C extensions for several platforms, you can simply install the packages under the platform subdirs in /usr/local/lib/python1.5 -- one copy for every platform. Disk space is no argument anymore nowadays. > 2) Another general question, this time o: how should this be > handled? Should C extensions always be effectively > top-level, and therefore go into site-packages? Should > there be an xml package holding .py files, and an X package > holding all the C extensions? (X = 'plat_xml', > 'xml_binary', or something like that) Just leave them in the package. I use a separate subpackage for the C extension which the packages modules then import. This makes mixed Python + C extensions and prototyping of C APIs in Python very simple and straight forward. > 4) Distutils question: is this a problem with the Distutils > code that needs fixing? I suspect not; if the tools make > it difficult to do stupid things like mix .py and .so > files, that's a good thing. I wouldn't like this; for a very simple reason: if someone wants to provide a Python rewrite of a C module which works as dropin replacement, the only way to handle this is by having a .so file and a .py file with the same name in the same directory. mxDateTime uses such a setup, for example. Note that .so files are found before .py files, thus if someone does have the .so file, Python will use the C module and not the Python one. -- Marc-Andre Lemburg ______________________________________________________________________ Y2000: 13 days left Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From akuchlin@mems-exchange.org Sun Dec 19 23:51:15 1999 From: akuchlin@mems-exchange.org (Andrew M. Kuchling) Date: Sun, 19 Dec 1999 18:51:15 -0500 (EST) Subject: [XML-SIG] Re: [Distutils] Disposition of C extensions and packages In-Reply-To: <385D6512.23665CAC@lemburg.com> References: <199912190243.VAA03844@207-172-57-180.s180.tnt2.ann.va.dialup.rcn.com> <385D6512.23665CAC@lemburg.com> Message-ID: <14429.28531.133654.92967@amarok.cnri.reston.va.us> M.-A. Lemburg writes: >If you maintain packages with C extensions for several >platforms, you can simply install the packages under >the platform subdirs in /usr/local/lib/python1.5 -- one >copy for every platform. Disk space is no argument anymore >nowadays. Hmmm... disk space is no longer a problem, but maintaining those parallel trees might be a problem; if a bugfix is released as a patch to Python code, you'd have to apply it to several trees. On the other hand, this isn't a very common way of fixing bugs in the Python community; a .1 release is more common. So your point is a good one; this would argue that the Distutils should make it easier to build things in one tree, and then install things under the right plat- directory. -- A.M. Kuchling http://starship.python.net/crew/amk/ He felt that his whole life was some kind of dream and he sometimes wondered whose it was and whether they were enjoying it. -- Douglas Adams, _The Hitch-Hiker's Guide to the Galaxy_ > >> 2) Another general question, this time o: how should this be >> > handled? Should C extensions always be effectively >> top-level, > and therefore go into site-packages? Should >> there be an xml > package holding .py files, and an X package >> holding all the C > extensions? (X = 'plat_xml', >> 'xml_binary', or something like > that) > >Just leave them in the package. I use a separate subpackage > >for the C extension which the packages modules then import. >This > makes mixed Python + C extensions and prototyping of >C APIs in > Python very simple and straight forward. >> 4) Distutils question: > is this a problem with the Distutils >> code that needs fixing? I > suspect not; if the tools make >> it difficult to do stupid things > like mix .py and .so >> files, that's a good thing. > >I wouldn't > like this; for a very simple reason: if someone >wants to provide a > Python rewrite of a C module which works >as dropin replacement, the > only way to handle this is by >having a .so file and a .py file with > the same name in the >same directory. mxDateTime uses such a setup, > for example. > >Note that .so files are found before .py files, > thus if >someone does have the .so file, Python will use the >C > module and not the Python one. > >-- >Marc-Andre Lemburg > >______________________________________________________________________ > >Y2000: 13 days left >Business: http://www.lemburg.com/ >Python > Pages: http://www.lemburg.com/python/ > > > >_______________________________________________ >XML-SIG maillist - > XML-SIG@python.org >http://www.python.org/mailman/listinfo/xml-sig > From sanner@scripps.edu Mon Dec 20 18:16:57 1999 From: sanner@scripps.edu (Michel Sanner) Date: Mon, 20 Dec 1999 10:16:57 -0800 Subject: [Distutils] Disposition of C extensions and packages In-Reply-To: "M.-A. Lemburg" "Re: [Distutils] Disposition of C extensions and packages" (Dec 20, 12:06am) References: <199912190243.VAA03844@207-172-57-180.s180.tnt2.ann.va.dialup.rcn.com> <385D6512.23665CAC@lemburg.com> Message-ID: <991220101657.ZM496939@noah.scripps.edu> On Dec 20, 12:06am, M.-A. Lemburg wrote: > Subject: Re: [Distutils] Disposition of C extensions and packages > "A.M. Kuchling" wrote: > > > > Questions: > > > > 1) A general Python question about packaging style: Is mixing > > C extensions and Python modules in one package tree a bad > > idea? It makes the whole tree platform-dependent, which is > > probably annoying for sites maintaining Python installation > > for different architectures. > > I have been using that setup for two years now with all of > my mx extensions and so far it has been working great. > > If you maintain packages with C extensions for several > platforms, you can simply install the packages under > the platform subdirs in /usr/local/lib/python1.5 -- one > copy for every platform. Disk space is no argument anymore > nowadays. > Agreed, disk space is not an issue, but file duplication is not very nice. I think this is a real weakness in Python: on one hand we have platform independent extensions which are great on the other hand we have native extensions when performance is required. This is, at least for me (in scientific computing) what makes Python such a great tool, BUT Python does not provide a mechanism to split a single package into platform dependent and platform independent part. We maintain Python and a number of packages for IRIX, SunOS, Dec Alpha OSF, Win32 and linux ... and having to update 5 .py files at every bug fix is a real pain. -Michel -- ----------------------------------------------------------------------- >>>>>>>>>> AREA CODE CHANGE <<<<<<<<< we are now 858 !!!!!!! Michel F. Sanner Ph.D. The Scripps Research Institute Assistant Professor Department of Molecular Biology 10550 North Torrey Pines Road Tel. (858) 784-2341 La Jolla, CA 92037 Fax. (858) 784-2860 sanner@scripps.edu http://www.scripps.edu/sanner ----------------------------------------------------------------------- From mal@lemburg.com Mon Dec 20 18:55:36 1999 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 20 Dec 1999 19:55:36 +0100 Subject: [Distutils] Disposition of C extensions and packages References: <199912190243.VAA03844@207-172-57-180.s180.tnt2.ann.va.dialup.rcn.com> <385D6512.23665CAC@lemburg.com> <991220101657.ZM496939@noah.scripps.edu> Message-ID: <385E7BA8.9BDC7A6@lemburg.com> Michel Sanner wrote: > > On Dec 20, 12:06am, M.-A. Lemburg wrote: > > Subject: Re: [Distutils] Disposition of C extensions and packages > > "A.M. Kuchling" wrote: > > > > > > Questions: > > > > > > 1) A general Python question about packaging style: Is mixing > > > C extensions and Python modules in one package tree a bad > > > idea? It makes the whole tree platform-dependent, which is > > > probably annoying for sites maintaining Python installation > > > for different architectures. > > > > I have been using that setup for two years now with all of > > my mx extensions and so far it has been working great. > > > > If you maintain packages with C extensions for several > > platforms, you can simply install the packages under > > the platform subdirs in /usr/local/lib/python1.5 -- one > > copy for every platform. Disk space is no argument anymore > > nowadays. > > > > Agreed, disk space is not an issue, but file duplication is not very nice. I > think this is a real weakness in Python: on one hand we have platform > independent extensions which are great on the other hand we have native > extensions when performance is required. This is, at least for me (in > scientific computing) what makes Python such a great tool, BUT Python does not > provide a mechanism to split a single package into platform dependent and > platform independent part. We maintain Python and a number of packages for > IRIX, SunOS, Dec Alpha OSF, Win32 and linux ... and having to update 5 .py > files at every bug fix is a real pain. One way to solve this is by editing the __init__.py module of the package containing the C extension and tweaking the __path__ global so that the correct shared modules for the importing platform is found. I've never tried this, but it should work... Note that at least Linux .so files and Windows .pyd files can live happily side-by-side in one directory. With distutils in place this issue should basically disappear altoghether, since then the whole building process would be automated -- not sure whether distutils allows having different setups for different architectures, but given that it is written in Python, it should be possible to automate all aspects of multi-platform installations. -- Marc-Andre Lemburg ______________________________________________________________________ Y2000: 11 days left Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From guido@CNRI.Reston.VA.US Mon Dec 20 21:32:40 1999 From: guido@CNRI.Reston.VA.US (Guido van Rossum) Date: Mon, 20 Dec 1999 16:32:40 -0500 Subject: [Distutils] Disposition of C extensions and packages In-Reply-To: Your message of "Mon, 20 Dec 1999 19:55:36 +0100." <385E7BA8.9BDC7A6@lemburg.com> References: <199912190243.VAA03844@207-172-57-180.s180.tnt2.ann.va.dialup.rcn.com> <385D6512.23665CAC@lemburg.com> <991220101657.ZM496939@noah.scripps.edu> <385E7BA8.9BDC7A6@lemburg.com> Message-ID: <199912202132.QAA11190@eric.cnri.reston.va.us> [MAL] > One way to solve this is by editing the __init__.py module > of the package containing the C extension and tweaking the > __path__ global so that the correct shared modules for the > importing platform is found. I've never tried this, but it > should work... Note that the idea of packages tweaking their __path__ is not very future-proof; one of the things under consideration elsewhere as a distribution mechanism is to place a group of modules in a zip archive (either the standard Python library, a package, or perhaps the library plus a set of packages needed by an application). I think it's worth looking again into the issue of where package-specific shared libs should come from when the package itself is loaded from an archive. --Guido van Rossum (home page: http://www.python.org/~guido/) From fdrake@acm.org Mon Dec 20 21:38:34 1999 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Mon, 20 Dec 1999 16:38:34 -0500 (EST) Subject: [Distutils] Disposition of C extensions and packages In-Reply-To: <199912202132.QAA11190@eric.cnri.reston.va.us> References: <199912190243.VAA03844@207-172-57-180.s180.tnt2.ann.va.dialup.rcn.com> <385D6512.23665CAC@lemburg.com> <991220101657.ZM496939@noah.scripps.edu> <385E7BA8.9BDC7A6@lemburg.com> <199912202132.QAA11190@eric.cnri.reston.va.us> Message-ID: <14430.41434.701589.4489@weyr.cnri.reston.va.us> Guido van Rossum writes: > I think it's worth looking again into the issue of where > package-specific shared libs should come from when the package itself > is loaded from an archive. As well as in the existing case of packages with both Python and C components. It simply doesn't make sense for a package containing primarily cross-platform files to be installed in platform-specific locations simply because the infrastructure doesn't understand the split. This is *not* an issue of disk space; I expect packages will appear which include data as well as code; these packages should be able to locate their associate data files using __path__ (or something similar). This makes a lot of sense for packages that perform character-set recoding and the like, where a large number of translation files may be carried along as part of the package. -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From guido@CNRI.Reston.VA.US Mon Dec 20 21:49:57 1999 From: guido@CNRI.Reston.VA.US (Guido van Rossum) Date: Mon, 20 Dec 1999 16:49:57 -0500 Subject: [Distutils] Disposition of C extensions and packages In-Reply-To: Your message of "Mon, 20 Dec 1999 16:38:34 EST." <14430.41434.701589.4489@weyr.cnri.reston.va.us> References: <199912190243.VAA03844@207-172-57-180.s180.tnt2.ann.va.dialup.rcn.com> <385D6512.23665CAC@lemburg.com> <991220101657.ZM496939@noah.scripps.edu> <385E7BA8.9BDC7A6@lemburg.com> <199912202132.QAA11190@eric.cnri.reston.va.us> <14430.41434.701589.4489@weyr.cnri.reston.va.us> Message-ID: <199912202149.QAA11239@eric.cnri.reston.va.us> > Guido van Rossum writes: > > I think it's worth looking again into the issue of where > > package-specific shared libs should come from when the package itself > > is loaded from an archive. [Fred Drake] > As well as in the existing case of packages with both Python and C > components. It simply doesn't make sense for a package containing > primarily cross-platform files to be installed in platform-specific > locations simply because the infrastructure doesn't understand the > split. > This is *not* an issue of disk space; I expect packages will appear > which include data as well as code; these packages should be able to > locate their associate data files using __path__ (or something > similar). This makes a lot of sense for packages that perform > character-set recoding and the like, where a large number of > translation files may be carried along as part of the package. I claim that it *is* an issue of disk space. Having the installation of a particular package spread out over two places is inconvenient from a management point of view, and sharing one of those places between different installations (for different platforms) of the same package just makes it a lot worse. Note that your example hinges on "a large number of translation files". That reeks of a disk space argument! (If you were thinking of network bandwidth or download time, there are other solutions that don't affect the install locations.) --Guido van Rossum (home page: http://www.python.org/~guido/) From fdrake@acm.org Mon Dec 20 22:02:52 1999 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Mon, 20 Dec 1999 17:02:52 -0500 (EST) Subject: [Distutils] Disposition of C extensions and packages In-Reply-To: <199912202149.QAA11239@eric.cnri.reston.va.us> References: <199912190243.VAA03844@207-172-57-180.s180.tnt2.ann.va.dialup.rcn.com> <385D6512.23665CAC@lemburg.com> <991220101657.ZM496939@noah.scripps.edu> <385E7BA8.9BDC7A6@lemburg.com> <199912202132.QAA11190@eric.cnri.reston.va.us> <14430.41434.701589.4489@weyr.cnri.reston.va.us> <199912202149.QAA11239@eric.cnri.reston.va.us> Message-ID: <14430.42892.379609.695074@weyr.cnri.reston.va.us> Guido van Rossum writes: > Note that your example hinges on "a large number of translation > files". That reeks of a disk space argument! (If you were thinking I conceed the point. My example was bad. If I make it "stuff that might be changed at the site", I see that the right solution is to have a file outside the package rather than inside it. I still don't like having to have two copies of the Python files to support multiple platforms for a couple of package modules, but that's very different and not clearly anything other than personal preference. I'm sure someone else can come up with a really good argument against it, though. -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From sanner@scripps.edu Mon Dec 20 22:19:50 1999 From: sanner@scripps.edu (Michel Sanner) Date: Mon, 20 Dec 1999 14:19:50 -0800 Subject: [Distutils] Disposition of C extensions and packages In-Reply-To: Guido van Rossum "Re: [Distutils] Disposition of C extensions and packages" (Dec 20, 4:49pm) References: <199912190243.VAA03844@207-172-57-180.s180.tnt2.ann.va.dialup.rcn.com> <385D6512.23665CAC@lemburg.com> <991220101657.ZM496939@noah.scripps.edu> <385E7BA8.9BDC7A6@lemburg.com> <199912202132.QAA11190@eric.cnri.reston.va.us> <14430.41434.701589.4489@weyr.cnri.reston.va.us> <199912202149.QAA11239@eric.cnri.reston.va.us> Message-ID: <991220141950.ZM501456@noah.scripps.edu> On Dec 20, 4:49pm, Guido van Rossum wrote: > > I claim that it *is* an issue of disk space. Having the installation > of a particular package spread out over two places is inconvenient > from a management point of view, and sharing one of those places > between different installations (for different platforms) of the same > package just makes it a lot worse. > What management are you talking about here ?? It seems to me that duplicate copies of identical files (one copy per platform) is inconvenient (at least for my perspective). Moreover, why provide an prefix and an exec_prefix if we are going to put everything into the same tree anyway ?? -Michel -- ----------------------------------------------------------------------- >>>>>>>>>> AREA CODE CHANGE <<<<<<<<< we are now 858 !!!!!!! Michel F. Sanner Ph.D. The Scripps Research Institute Assistant Professor Department of Molecular Biology 10550 North Torrey Pines Road Tel. (858) 784-2341 La Jolla, CA 92037 Fax. (858) 784-2860 sanner@scripps.edu http://www.scripps.edu/sanner ----------------------------------------------------------------------- From guido@CNRI.Reston.VA.US Mon Dec 20 22:29:19 1999 From: guido@CNRI.Reston.VA.US (Guido van Rossum) Date: Mon, 20 Dec 1999 17:29:19 -0500 Subject: [Distutils] Disposition of C extensions and packages In-Reply-To: Your message of "Mon, 20 Dec 1999 14:19:50 PST." <991220141950.ZM501456@noah.scripps.edu> References: <199912190243.VAA03844@207-172-57-180.s180.tnt2.ann.va.dialup.rcn.com> <385D6512.23665CAC@lemburg.com> <991220101657.ZM496939@noah.scripps.edu> <385E7BA8.9BDC7A6@lemburg.com> <199912202132.QAA11190@eric.cnri.reston.va.us> <14430.41434.701589.4489@weyr.cnri.reston.va.us> <199912202149.QAA11239@eric.cnri.reston.va.us> <991220141950.ZM501456@noah.scripps.edu> Message-ID: <199912202229.RAA11536@eric.cnri.reston.va.us> [Michael Sanner] > What management are you talking about here ?? It seems to me that > duplicate copies of identical files (one copy per platform) is > inconvenient (at least for my perspective). Suppose a new version of a package is released for platform X but not yet for platform Y (maybe platform Y is less popular and the only maintainer is on vacation). Further suppose the platform-independent files are changed in the new version. Now if you install it in the shared area for platform X, you screw platform Y's installation. Without a shared area, each platform can update without affecting the others. > Moreover, why provide an prefix and an exec_prefix if we are going to put > everything into the same tree anyway ?? They are old features; 5 years ago this was worth it to save 0.5 Mb of disk space. --Guido van Rossum (home page: http://www.python.org/~guido/) From sanner@scripps.edu Mon Dec 20 22:40:57 1999 From: sanner@scripps.edu (Michel Sanner) Date: Mon, 20 Dec 1999 14:40:57 -0800 Subject: [Distutils] Disposition of C extensions and packages In-Reply-To: Guido van Rossum "Re: [Distutils] Disposition of C extensions and packages" (Dec 20, 5:29pm) References: <199912190243.VAA03844@207-172-57-180.s180.tnt2.ann.va.dialup.rcn.com> <385D6512.23665CAC@lemburg.com> <991220101657.ZM496939@noah.scripps.edu> <385E7BA8.9BDC7A6@lemburg.com> <199912202132.QAA11190@eric.cnri.reston.va.us> <14430.41434.701589.4489@weyr.cnri.reston.va.us> <199912202149.QAA11239@eric.cnri.reston.va.us> <991220141950.ZM501456@noah.scripps.edu> <199912202229.RAA11536@eric.cnri.reston.va.us> Message-ID: <991220144058.ZM491374@noah.scripps.edu> On Dec 20, 5:29pm, Guido van Rossum wrote: > Subject: Re: [Distutils] Disposition of C extensions and packages > [Michael Sanner] > > What management are you talking about here ?? It seems to me that > > duplicate copies of identical files (one copy per platform) is > > inconvenient (at least for my perspective). > > Suppose a new version of a package is released for platform X but not > yet for platform Y (maybe platform Y is less popular and the only > maintainer is on vacation). Further suppose the platform-independent > files are changed in the new version. Now if you install it in the > shared area for platform X, you screw platform Y's installation. > Without a shared area, each platform can update without affecting the > others. > OK, you have a point there ! although this raises the issue of packages version support ! > > Moreover, why provide an prefix and an exec_prefix if we are going to put > > everything into the same tree anyway ?? > > They are old features; 5 years ago this was worth it to save 0.5 Mb of > disk space. > Does that mean that this will disapear ? it is it old stuff, it should ! Or do you think that the /sys.prefix/lib should remain shared ? While we're at it, maybe the extensions that are distributed along with the Python intertpreter should be re-evaluated. I have a hard time explaining why some extensions like the rotor module are part of the Python standard distribution while Numeric is not ! These might be details, but I am in the process of trying to convince people at SDSC (San Diego Suppercomputer Center) to support Python for their users and questions like these are raised ! -Michel -- ----------------------------------------------------------------------- >>>>>>>>>> AREA CODE CHANGE <<<<<<<<< we are now 858 !!!!!!! Michel F. Sanner Ph.D. The Scripps Research Institute Assistant Professor Department of Molecular Biology 10550 North Torrey Pines Road Tel. (858) 784-2341 La Jolla, CA 92037 Fax. (858) 784-2860 sanner@scripps.edu http://www.scripps.edu/sanner ----------------------------------------------------------------------- From akuchlin@mems-exchange.org Mon Dec 20 22:46:35 1999 From: akuchlin@mems-exchange.org (Andrew M. Kuchling) Date: Mon, 20 Dec 1999 17:46:35 -0500 (EST) Subject: [Distutils] Disposition of C extensions and packages In-Reply-To: <199912202229.RAA11536@eric.cnri.reston.va.us> References: <199912190243.VAA03844@207-172-57-180.s180.tnt2.ann.va.dialup.rcn.com> <385D6512.23665CAC@lemburg.com> <991220101657.ZM496939@noah.scripps.edu> <385E7BA8.9BDC7A6@lemburg.com> <199912202132.QAA11190@eric.cnri.reston.va.us> <14430.41434.701589.4489@weyr.cnri.reston.va.us> <199912202149.QAA11239@eric.cnri.reston.va.us> <991220141950.ZM501456@noah.scripps.edu> <199912202229.RAA11536@eric.cnri.reston.va.us> Message-ID: <14430.45515.503618.220288@amarok.cnri.reston.va.us> Guido van Rossum writes: >[Michael Sanner] >Suppose a new version of a package is released for platform X but not >yet for platform Y (maybe platform Y is less popular and the only >maintainer is on vacation). ... >Without a shared area, each platform can update without affecting the >others. Good argument, and I think I'm convinced by this point; even though duplicating the .py files goes against my grain, that's probably just a sign of my age. But what platform-specific directory should packages be installed into? Is /plat- the right place? Or do we need site-packages/plat-? (Yet Another default directory added to sys.path -- yuck!) -- A.M. Kuchling http://starship.python.net/crew/amk/ Tabs are good, spaces are bad and mixing the two just means that your motives are confused and that you don't use enough functions. -- John J. Lehmann, 19 Mar 1998 From guido@CNRI.Reston.VA.US Mon Dec 20 22:51:44 1999 From: guido@CNRI.Reston.VA.US (Guido van Rossum) Date: Mon, 20 Dec 1999 17:51:44 -0500 Subject: [Distutils] Disposition of C extensions and packages In-Reply-To: Your message of "Mon, 20 Dec 1999 17:46:35 EST." <14430.45515.503618.220288@amarok.cnri.reston.va.us> References: <199912190243.VAA03844@207-172-57-180.s180.tnt2.ann.va.dialup.rcn.com> <385D6512.23665CAC@lemburg.com> <991220101657.ZM496939@noah.scripps.edu> <385E7BA8.9BDC7A6@lemburg.com> <199912202132.QAA11190@eric.cnri.reston.va.us> <14430.41434.701589.4489@weyr.cnri.reston.va.us> <199912202149.QAA11239@eric.cnri.reston.va.us> <991220141950.ZM501456@noah.scripps.edu> <199912202229.RAA11536@eric.cnri.reston.va.us> <14430.45515.503618.220288@amarok.cnri.reston.va.us> Message-ID: <199912202251.RAA11626@eric.cnri.reston.va.us> > Good argument, and I think I'm convinced by this point; even though > duplicating the .py files goes against my grain, that's probably just > a sign of my age. Oh, you gen-X'ers thinking you're old... Have you had your prostate checked lately? :-) > But what platform-specific directory should > packages be installed into? Is /plat- the right > place? Or do we need site-packages/plat-? (Yet Another > default directory added to sys.path -- yuck!) lib/python/site-packages This is supported by site.py: """ This will append site-specific paths to to the module search path. On Unix, it starts with sys.prefix and sys.exec_prefix (if different) and appends lib/python/site-packages as well as lib/site-python. On other platforms (mainly Mac and Windows), it uses just sys.prefix (and sys.exec_prefix, if different, but this is unlikely). The resulting directories, if they exist, are appended to sys.path, and also inspected for path configuration files. """ (Note that lib/site-python is obsolete!) --Guido van Rossum (home page: http://www.python.org/~guido/) From akuchlin@mems-exchange.org Mon Dec 20 23:06:52 1999 From: akuchlin@mems-exchange.org (Andrew M. Kuchling) Date: Mon, 20 Dec 1999 18:06:52 -0500 (EST) Subject: [Distutils] Disposition of C extensions and packages In-Reply-To: <199912202251.RAA11626@eric.cnri.reston.va.us> References: <199912190243.VAA03844@207-172-57-180.s180.tnt2.ann.va.dialup.rcn.com> <385D6512.23665CAC@lemburg.com> <991220101657.ZM496939@noah.scripps.edu> <385E7BA8.9BDC7A6@lemburg.com> <199912202132.QAA11190@eric.cnri.reston.va.us> <14430.41434.701589.4489@weyr.cnri.reston.va.us> <199912202149.QAA11239@eric.cnri.reston.va.us> <991220141950.ZM501456@noah.scripps.edu> <199912202229.RAA11536@eric.cnri.reston.va.us> <14430.45515.503618.220288@amarok.cnri.reston.va.us> <199912202251.RAA11626@eric.cnri.reston.va.us> Message-ID: <14430.46732.883906.842956@amarok.cnri.reston.va.us> Guido van Rossum writes: >> But what platform-specific directory should >> packages be installed into? > lib/python/site-packages Ah, so then you should never attempt to share site-packages between different Python installations. If you want a directory of common Python code that's used by several different Python binaries, I guess you should hack sitecustomize.py to modify sys.path accordingly. One for GPW's notes on administering a Python installation... I think this argues for changes in the Distutils -- right now an installation like this is really hard. -- A.M. Kuchling http://starship.python.net/crew/amk/ Difficulties are meant to rouse, not discourage. -- William Ellery Channing From guido@CNRI.Reston.VA.US Mon Dec 20 23:10:07 1999 From: guido@CNRI.Reston.VA.US (Guido van Rossum) Date: Mon, 20 Dec 1999 18:10:07 -0500 Subject: [Distutils] Disposition of C extensions and packages In-Reply-To: Your message of "Mon, 20 Dec 1999 18:06:52 EST." <14430.46732.883906.842956@amarok.cnri.reston.va.us> References: <199912190243.VAA03844@207-172-57-180.s180.tnt2.ann.va.dialup.rcn.com> <385D6512.23665CAC@lemburg.com> <991220101657.ZM496939@noah.scripps.edu> <385E7BA8.9BDC7A6@lemburg.com> <199912202132.QAA11190@eric.cnri.reston.va.us> <14430.41434.701589.4489@weyr.cnri.reston.va.us> <199912202149.QAA11239@eric.cnri.reston.va.us> <991220141950.ZM501456@noah.scripps.edu> <199912202229.RAA11536@eric.cnri.reston.va.us> <14430.45515.503618.220288@amarok.cnri.reston.va.us> <199912202251.RAA11626@eric.cnri.reston.va.us> <14430.46732.883906.842956@amarok.cnri.reston.va.us> Message-ID: <199912202310.SAA11826@eric.cnri.reston.va.us> > Guido van Rossum writes: > >> But what platform-specific directory should > >> packages be installed into? > > lib/python/site-packages [AMK] > Ah, so then you should never attempt to share site-packages between > different Python installations. Not sure. There are TWO site-packages directories. One under prefix, one under exec_prefix. (Of course, if you're not concerned with exec_prefix, they will be the same one.) The one under prefix can be shared -- and should not contain shared libraries if it is shared. The one under exec_prefix is not shared. > If you want a directory of common > Python code that's used by several different Python binaries, I guess > you should hack sitecustomize.py to modify sys.path accordingly. One > for GPW's notes on administering a Python installation... Yes, they will (presumably) have different prefix values, and then by default they won't share anything. > I think this argues for changes in the Distutils -- right now > an installation like this is really hard. Not sure what you mean by "like this." --Guido van Rossum (home page: http://www.python.org/~guido/) From bckfnn@pipmail.dknet.dk Tue Dec 21 22:01:31 1999 From: bckfnn@pipmail.dknet.dk (Finn Bock) Date: Tue, 21 Dec 1999 22:01:31 GMT Subject: [Distutils] distutils-0.1.2 with JPython Message-ID: <385fb910.545965@pipmail.dknet.dk> Hi, Being new to Distutils-SIG, I apologized if these topics are old already. I have tried to run distutils 0.1.2 under JPython and windows NT, this is what I came up with. a) distutils attempt to install itself in sys.prefix. Unfortunately JPython does not, as distributed, import site.py. So by default installed modules can not be located. I guess this is a problem in JPython and have reported it as: http://www.python.org/jpython-bugs/incoming?id=229 b) sysconfig does not known about os.name == 'java'. Hacked below. c) Wildcard import in the local name space does not work with JPython. This is used in util.py. Even though this is a JPython bug http://www.python.org/jpython-bugs/incoming?id=229 I think distutils could avoid the situation until JPython is fixed. Hacked below. d) JPython's 'os' modules does not contain utime or chmod. Hacked below. e) When building a "dist", the distutils.errors was missing in dist.py. Hacked below. f) The fields of IOError are different between JPython and CPython. The field strerror exists, but it is None. This is a known difference. Hacked below. g) os.link is not defined. Neither is os.link when using CPython for Windows NT. I exchanged os.link with util.copy_file, but that is bogus. Unfortunately it is also included in the hack below. h) spawn.py did not support os.name == 'java'. Hacked below. i) The windows version of gzip that happened to be executed when outputting gztar on my PC complains if the .tar.gz already exists. Perhaps dist.py should remove any existing .tar.gz before trying to make a new one. Not fixed. Some general questions: 1) I am unsure, how os.name dependencies are best introduced. F.ex. in the dist.make_zipfile(), I just added an if. It does not feel right. 2) Can (and should) distutil deal with the cr/lf issues of text files? When building a distribution targeted to a specific platform, I think distutils could help out with converting the obvious text-files. In order to gain some momentum with my tests, I just hacked simple solutions to my problems. The changes that I have made may break more than they fixes, so beware. The result can be seen here: http://pip.dknet.dk/~bckfnn/Distutils-0.1.2-fbo.tar.gz With this version, I could run the "dist" command and the "install" command with normal module/*.py files. regards, finn From fdrake@acm.org Tue Dec 21 22:25:54 1999 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Tue, 21 Dec 1999 17:25:54 -0500 (EST) Subject: [Distutils] distutils-0.1.2 with JPython In-Reply-To: <385fb910.545965@pipmail.dknet.dk> References: <385fb910.545965@pipmail.dknet.dk> Message-ID: <14431.65138.109532.651465@weyr.cnri.reston.va.us> Finn Bock writes: > Being new to Distutils-SIG, I apologized if these topics are old > already. I have tried to run distutils 0.1.2 under JPython and windows > NT, this is what I came up with. Thanks! > b) sysconfig does not known about os.name == 'java'. Hacked below. The things that were appearantly supposed to be attached aren't there; could you send them along? -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From bckfnn@pipmail.dknet.dk Sat Dec 25 07:46:51 1999 From: bckfnn@pipmail.dknet.dk (Finn Bock) Date: Sat, 25 Dec 1999 07:46:51 GMT Subject: [Distutils] distutils and JPython Message-ID: <38647663.4686478@pipmail.dknet.dk> Hi, Generally I'm looking at distutils to see if it can help me simplify the installation of some of the JPython modules I have created. A JPython modules could typically consists of: - .py files - .jar file or .class files - .dll files Lets first assume that all these files have been compiled and built in some traditional way. In order to get started with distutils, I will avoid any attempt to compile any of the C/C++ source at the target machine. So this is windows only, at least to begin with. My primary target user is a java/jpython developer. Copying the .py files works like a dream. For .jar files, the situation get more complicated. A jar file could: a) be copied to an well-known directory f.ex. a subdir to sys.prefix. The JPython startup script would then have to be changed. I.e. inserting the new .jar in the -classpath or /cp option to the java command. b) If using Sun-JDK, the jar could be copied to the "$java.ext.dir" directory in the JDK/JRE installation. c) If using MS-jview, the jar could be extracted into "$java.home\Lib" or "$java.home\TrustLib" directory. java.home is narmmaly something like "c:\windows\Java" d) Some other directory, leaving it entirely up to the user to fiddle with startup scripts and CLASSPATH environment variables. Other JVMs could possible have different default places where class files are located. Even if distutils will support all methods, I think the user must be queried which strategy she want to use. For .dll files, the situation get similar. A dll file could: a) be copied to one of the directories on the current PATH (only easily available in Sun-JDK as $java.library.path) b) be copied to JVM specific exe directory. $java.home/bin in the JDK/JRE for Sun-JDK, $com.ms.sysdir in c:\windows\system32 for MS-jview. c) Some other directory, leaving it up the user to change the $PATH / $LD_LIBRARY_PATH(?) environment variables. Again, I think the user must be queried before .dll files can be copied. These are normal installation issues. I am a bit unsure on how much I can reasonably expect distutils to deal with this. From my very limited experience with distutils, I think distutils is exactly the right place to put some of the logic that deals with JVM and OS dependencies as described above. Any thoughs? Buglets and suggestions: a) Documentation buglet. In the USAGE file for "dist", -f is described as an alias for --formats. -f does not work. b) How about allowing for some alias names for the README file. Some of us lazy double-clicking windows types prefer names like README.txt. c) Why are "packages" and "py_module" mutually exclusive. One of my products happens to have a toplevel module which contains "from pck.Main import *". I think that I find the current behavior limiting. regards, finn From proteus@cloud9.net Wed Dec 29 01:42:08 1999 From: proteus@cloud9.net (Michael Muller) Date: Tue, 28 Dec 1999 20:42:08 -0500 Subject: [Distutils] Package Meta-information Patch Message-ID: <386966F0.AA74F1DF@cloud9.net> This is a multi-part message in MIME format. --------------C83FADC18C693FEFCE98DEEB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi All, I finally got to delve into Distutils 0.1.2 over the long weekend, and I think it is a very nice package. The architecture is very clean and extensible, and the code is consistent, well commented, and well organized. Thanks, Greg! I've enclosed a patch which addresses a particular concern of mine: package meta-information. At the end of the install command, it creates a package information file in /_pkginfo named after the package (it also creates the "_pkginfo" directory, if necessary). The file contains python variable definitions for the package name, version number, list of files installed, dependencies, and compatible versions (although the latter two are always empty at this time). The module that is used to record and obtain package information can be overriden on the command line (install_info --pkg-module ). Also, if a global "pkginfo" module exists, it will be used instead of the default distutils.pkginfo module (whose behavior is described above). I envision the installer using whatever package information system is most appropriate for the system (RPM's for Linux, Registry files for Windows[?]). Meta-information facilitates uninstall, dependency checking, automatic downloading of dependencies, and system cataloging. I'd be interested in contributing some of these features to distutils, and welcome any discussion on the subject, particularly since it is relevant to my day job. ============================================================================= michaelMuller = mmuller@enduden.com | http://www.cloud9.net/~proteus ----------------------------------------------------------------------------- There is no concept that is more demeaning to the human spirit than the notion that our freedom must be limited in the interests of our own protection. ============================================================================= --------------C83FADC18C693FEFCE98DEEB Content-Type: application/x-gzip; name="Distutils-0.1.2-pkginfo-patch.gz" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="Distutils-0.1.2-pkginfo-patch.gz" H4sICPNgaTgAA0Rpc3R1dGlscy0wLjEuMi1wa2dpbmZvLXBhdGNoAN1a62/jNhL/XP8VbIJA di27cd5R4esW3RZYoNsu+kALZAODlmhHZ1lSRSmJr+j/fjPDh6iHN4/rpzPajS0Oh8PhPH4z VBSvVmxS/Fixt7EsqzJO5OR4OpuefBmZ31+G2XbL0+jLOJUlT5JpvmsTT3JehnefnDKYTCYv WuOz30XEfhE5O7lmx1fB6VUwu2Sz6+vrwXg8foUAn31fxOytCNnJGZvNgvOz4PhK8Xvzhk1O ri79CzbGP9fszZsBcz9SJKtpUaWLXIiCDT3NdJHvvFFNGa8UIQpRxEuQI0un4rFcbLOoSoQM nscUZgDXsSGrvx2yQoRZEbHyTjBNzXER+LHKaroG45ovEqG4XYFBd3eLVZyIPgnDQvBSLCwN G44G0cuNBrf1CsPR015mPHrSP2pAhud7UDcZEbA6C06ugvPL2ohOz/wzNoZ/Z00bOmTLKk6i af0kq0pUpmRzreUs3y3KQoB66TfRL6K48NW4kQKe4BE6NrEWJRlEApKzbMUU2zilh8TGB7tZ 8yKC5xIpHu4EjBUsK1ialS6vB8F4WFaw0I6BRLEgW9vWJFoMeK7lxlV75d5rwXnCQ0HCyawq 4CsQi7DMih2Tpdiyh7i8o+GSF7i35nC/KFues2HCt8uIs0ef8W05T0Talsh3JNn3iaN5W9/B E9PiiI3Z4w0sGtx+cgkrMeim7wRdR2Xa/Bj9HzV8HrasDrnMWFy6GoF5+lxWcRq1A4sOAA36 KfBe1HyHroz1+Q1AyjDhYD7v1Ph3j+WrggAt+YoooOe9MAzoWRQH0GdPZ+CqwfEx/AdfLl4X BwzTXyuhAsEVOzkOZicB+LwNBMf+MRvP/IsZhoHxwcGB5TfV/KYuP7SHb/WB46GqITrznIcb vhZ0WMWWwv0U+OGMVZFtmcu4ALJtnhUl08wGY/07kxBHdhJnHbISfAlXUUOcrZNsyRN2kG/W uMoBU/nKx/yQZil8MRYaiRWvEmCXisEY2ATKSDQnPX8wFo+hyEv2jh5/VxRZoQmbEnfmDcYN I3sHD4d6J6PA+EyWow4wcN4MPZg6UdLOPZ95Of7zI98KDHNGc2UBX+J0rbeFW6+k8Ea3xE8x hY2xBRxFXC4WFDZ8EnMU1F6gBZn2kbVyrxuabm6ZXaVeq+F1mhP5tLtih1frwViHAeWilrcU 5UIf1EIri1bosAblaWgCvH+kM21KiZwgkPBkL58cjqs9C5BHhw4s9vciLjFmtWya9sDAtt0R Y+F1jARTxHE4uILJXITxCpMTN2ca8ZIvuQRTBQoIilMnyq3auw2aMbq2Y/cDx0zWuVjozFbP H3Wp87jWJPjZVCO+m9bM2+bMvX7ifgoew5ZslHpPjIjYZx/3ZZuDOL3nCWSmhqq1iN6R9A7Y UVstNS+RyLaS3A1afzWDfcksryAa5bvyjuCpg1VtPg+ALoYgIN3Q4rJKslBNcZzZmozsIAHM 1cZJQArKftpwG4gdQoQzw02IxmvswnMInISOp//O4nToTAMmC62HfrCOccFI4xYETbNW4Brs +IPaH4Y8tZ80pEi1rFLAbQyzQbZqOE/DO+rk0IED9uSm7hrDFKPknMSc4nf/aWykPveikEo3 NFf/fPb0BuptIiInrFiZVcWz0JtW0GjYPief9voceKc/tDhIvswwZLxsWlTsFhDiXlcE5bvX oB+a9ULsQ3M++6VK2U9hydgpm10Gx6fBycXrKyDFslkAAZ5yC6BzrKHP/UuqfnR6h3gI4AMc IF0P2DMwS5sG/zU0tkxykA1WtA3c8GHHHNjASLCzC38GkOzs0j85J+FUKabzFTMJqzeUxdYp wVSLJ/B2F267ZeDbapszkZYQA2EvaQlfpXFsKlSccge8v13ou6xqwmF5x0tPhdGl4FW5Q5Z3 /B5BD2/z/Xz0D1Whkx4P+XRO0FULSAuVZuHWM8PXVKhRjAgAZR51kkFPhfryAtXSsrwQq/ix rk3dlKPG/l8K065OumVif5Vo2R2y4U+UdvGURljJ5ojxMPKBTcOf0KX9448/2J3YfY5HG/LU K8kxiiyxVgADmMa38X+EtoivmDb5KndZWY+5d5ADPgmrogBXYx8MHilFAcdWYnkMxpgILksK ExfXFCauzv3T404XcN/nYLkrxURtE13uSCK6Wvkvn22FPpJMbuI8FxGxGvWz6j/StnLjdYpR lqzH6nFFinwAv44RaYCKowx1D3gEXWsDY4CcXVYPwqOgZXZJrIhYnYlPrYowq5IIGeVxuIET BO3CqUSZy0ncixRhOS4KNoprTRn7ajJshl+UnRBiziHOw1/wIxFogQkJFeI+zipJvRKKpLJa r4UsyTpaUUNtT+8LH0B8RIAaovj5ToNK/LHMyjsfKdZoTkVWre9cXrgyxM28cltTuHUJYfNB xTbvHmc7IqC6V9iUs57Twtcg0+pmchrcsvmceeAjXk8p0OOJdKqLBeLde17EXJVpq5tgcvpp n3/qM0QhMgTL6LDeaGQz2aHKmCO35uxIoEpaVZLJarWKw2ZtCwXez6KsCijkuW1dIsoVj/AD 7UudB0VcToxYqgt7D395jb2pThlMhowqVUeceWZdD5wcTufPSqDlAANLJkeq0nQ41T/UIVOj 4bZ5ksT4EdcwS7RLSsjycyX0WFN3jttUFrRhCUl8m496zlxLMeUQDGCTRFZTFaRDQ4So5rCN hZ6JUwvxPGRKdE9iUaKyfbfZObXIroPj85egT8XExZunwflJcHZR482rizNEnPhnNntOwHaR P/vXHEL/vUiejtRN5O80O1r9b5/hmWJXqJDzY+y5bSFYbuR81jL+H2KpMJGLArmL/oAnRMV3 YO7IzMMAKAVEWVyxYSayWpppsZDUtfPMus1pKM4yS+KQ0WDT9jtGhcfg9vfrndX7GrlAepvd C31FpHQhixAmSFwd1UxKYI4S3sME2DRNKQS2dcjzzfGgU4POJxhuVglfK4GfY866Mn+ORdek Txh1Tfi/9ZMdPk4LGeuo4+DkqtNCns16eshOx/Stbsn2NHrAfH7F/KmbUZjbI0lafVC9uLqV 4DQQGJf1HRJ32zUuEYZBXi9qL5yQYjAmW6ZjtYhZYvCmCM6bTUB0AB6nePC6XURpZJmgXGBW 2G2lhq/pEfJSNVOEbLVEpqiP93qzSJ0RfOzpoAMuT+FRAb5xh4CFuoaqG4XQcMVV82UwfsiK jdpDrXzdm9T1Jz5zi1HVlc9zKHdLU7V+AI8qdx8KYl63uamJN/yOmoAglIkQmBqx5xcpJac7 uwPSqA4YTOBsK43i6HR4ArctC0TfEgFsSpaIBvuuFdi3CiYDpJNVjpKDDHm1xIBho4M5HDCk wmkS2i94xO3eoV4Lh2o+qm+0h9Q0mdJqu3RKbrLL1hR771kBFp38CaWh6g1juMIVpUEW2lic IhR20F6+KFtGZQkikbeXNtLCUATJGeAFBGDjdbEk7wmpECqoJG/Yo2xBBi0QeOmfFfhcZO29 0T0l4WLrurSYYBuxa7HT7uisry19KRreRxry6dE9TyphPKLJDSdVOerN8VacY4VtHpjCY7aB 22SmWkFUeNFWoIwAkMjZbz//MKr79lho8LKtcfU0xuCgV0R9f2ON4AFK6pAXkV5EwtHIEKIF 9p4ajNRRGB5ttarToCdmY7F0Fm/ywvhQ51L1LwYphI5/eahhL2Ce126Repo1Dn799dfdcbJU GL257QyhMcLIX393RrTeaNrf7auZ1t3VF19sHlxc0iiZeLIx5Q8dNdjYA758wot1RdVWExNv fHaPVrd5mEJu2cphG8w2fx1CCN5AVsBbAlJ2XCqPScSaJ3WM78BmqDQVGiMNT++4XIBkw00f dlZXJ98YXirebkafkguwEjLWCsJN7ekTSXw1Qede7TkUrpPETVBK2tK4o6PDPepzttavRq0C 2LcrZ9/ue7dS2wJhgJ9SPQwVRAuhqqQ1oUTWvbZzwEJdv5nc0JDFTeGZUsM6xg6ALqLBUwXf 7sOiORZSjfw5HLU011IbxsKO1u6By7qpj5YZgOxA4x2h03rsiG1a8aIqp6SxIRB2piZ4z5JP c6WX4f2oc2bY9cOZUA+qr8mI/YtdnvdXfHop7+PHj6k32i9JsnfMw4nukKtc6np3L1b23qto QD6f+UzXQPNjF60QK7n/VYV6/Y7bozmYizSn+lFFsZpDdch2g/m87+rHCGevc4yItlxz1sdl VInSvNrbd6dEV2NNDiuzonsNTmjvAFUPmebAr9dpTUXX1XIFbjTJoLjvvxpv9mGt7Eg/tE98 5j207cRlbzF/532hqQkDlhcFCSptM/6kfZB6XEswLZ3e+8zWLb9BWiocIKs6/XeuYpvwJWk1 eC0Sqwvhtumpt1woJ+u8KB5FiDseNi5592zSNwxGjcPUD20eUuneDT8qCanc4/1swV0sYDcH SH1AjMAGXZg/9UZNvynElqplyC/0/gPEHIVuqd4gNeoN1phPzbVB0sjaiZCwl81NcKJ6j4tF u/UYicTMvdncumLpTgHP82Q3dI7cZ8OOwmjWc4p38vdnVO6a7omyXVM1bkIvsNY+mz2/F2WY NHtRJ2fB7Mx9+fMKe1H45/RU3zEeMudKjRpH7aYRtUj2dote0CmK250iq/aEGoyqHLDuQdV9 FFFi1hcncWHX0J0n20ayvNx2ktzbT1L/dhuo6t/mCzfKiikcI1O8UUOtjIyP0isyMCjUKy9D +JuCgcEfQA5dR7NH+X28/zWZA2JGm6hbzaCQIxno2xt1MHoRA5vo0gTpSGb3daoiXOgXKppZ hbiko4arGaVSVDbkscRnNGHhBlXzabeBLV1NJhKnqxxLo8hedkCJtvKMfnPPQs2zNd/GLbOm Wd1+oSNu5yWjJ9ZuxBzT8tYjh/Xq5Gf6/ugdQA3qK9p3jX5L48eJfoMsZBA6UoHNgqwgS7gT Sf75oNPNNH3MwX8BbmF49C4xAAA= --------------C83FADC18C693FEFCE98DEEB--