On Mon, Feb 18, 2002 at 01:35:25PM -0500, Jim Penny wrote: > Objection 1: Autocompilation can result in progams that compile but > do not work as expected. > Examples: scope rule changes. Inheritance Changes. Arithmetic Changes.
This has nothing to do with the organization of the packages; either way, the resulting programs must be tested (or if they aren't, things sometimes break). > Objection 2: Autocompilation can produce programs which fail to > compile. > > Examples. <op>=, use of mimelib (not available in 2.2), type/class > unification, use of iterators/generators, etc. > > Some of these would be easy to backport to 1.5.2 (although probably > not worth the effort), Certainly all would require a human decision. This doesn't sound like a problem at all. If a module doesn't compile, but runs when not compiled, then a compilation failure is simply not a fatal error. > Objection 3: None of this addresses the case of 'C'-extension modules. > > Looking at my site-python2.1, I am guessing that this affects from 25% to > 50% of all modules. These have to be hand-created with multiple packaging > anyway. I wasn't exactly proposing a complete replacement for the python policy; my message was a short comment about one aspect of python module packaging. It did not address all cases. > Objection 4: > > This is a minor objection: It would not be unusual to have at least two > versions of python installed. (I currently have 3). I keep only current > as a "full featured" package. I DO NOT want to have every package > auto-installed and auto-compiled in every python on my system! This would be a simple matter of configuration. One of the benefits of a centralized scheme is that you can configure preferences like these in one place, rather than offloading a lot more work onto module packagers. > Concluding remarks: > > It is simply not all that hard to create multiple python packages. This > proposal simply offloads a minor amount of work from the packager, and a > certain amount of storage from servers replacing it with greater package > installation time and greater local storage use. What it does is to offload fundamentally fragile code from maintainer scripts into a centralized and easily maintained program. In addition, it has the added benefit of making module packaging easier, and not cluttering the archive with 3 (or 4, or 5) packages per python module. > Worse, it hides problems from the packager. If the package compiles and > works under the current python, I suspect that most developers will do no > actual testing under old or leading edge pythons. And if they have not, > the user contract is being violated. The packager may easily manage to > inadvertantly install a broken package! This is no different from packaging for multiple versions, as above. > Finally, the emacs compilation process is one reason that I make very sure > that no emacs packages are installed on any of the systems I have control > over. I find the compilation process to be at best annoying, and at worst > a near denial of service. I would not welcome it in python. An exaggeration at best. -- - mdz
