Python evolution: Unease

[Bengt Richter]

On 05 Jan 2005 07:18:25 -0800, Paul Rubin <http://phr.cx@NOSPAM.invalid> wrote:

>Ville Vainio <ville at spammers.com> writes:
>>     Paul> I can't parse that.  It says two contradictory things.
>>     Paul> Sentence 2 says that if something essential is not in the
>>     Paul> (Python) distro then the (Python) distro maintainers have
>>     Paul> screwed up.  Sentence 1 says it's the Fedora maintainer's
>>     Paul> job to deal with it.  Huh?
>> 
>> By "distro" I meant the Linux distribution, not the Python
>> distribution. Distro is a customary term for a Linux distribution so I
>> didn't qualify the word at the time.
>
>Oh ok, but it's the Python distribution that's missing components that
>are essential to Python.  Fedora and other Linux distros are
>collections of subsystems like Python.  Linux distro maintainers get
>asked to include a subsystem, they check that the subsystem has a
>reasonable reputation (Python does), they install it in the distro and
>run some basic tests, and they ship it.  They can't be expected to
>immerse themselves in its intricacies and hang out on the user forums
>to identify all the missing components that they should also hunt down
>and ship.  So the Python needs to take care of that stuff.
>
>I realize that in the old days, people used to write big applications
>without makefiles, and later when they started using makefiles, they
>didn't use configure scripts.  So to install a package, you had to do
>a bunch of hand configuration for your particular environment before
>you could compile it, and maybe you even had to say 
>  cc -O -Dthisflag=thatnumber xyz.c pqr.c frob.c -o frob
>on the command line instead of typing "make" to build the program.
>That kind of thing really doesn't fly any more.  The standards for
>what constitutes a properly engineered release of something have
>gotten higher.  You really need automatic configuration and build and
>installation.  Likewise, if you're trying to market something as a
>complete drop-in system ("batteries included", to use the Python
>terminology), it should not be missing any essential pieces that
>the user has to hunt down separately.
What do you think of automated secure importing/installing from a remote server?
You know, you try to import something and it imports a stub that was included
as a battery-place-holder and that has basic help info and will give you reasonable
options in directing the installation of the full thing (or subset you are interested in).

I don't see why every gee whiz thing has to be on your hard disk from the first.
And for those that want a big grabbag, the stubs ought to be designed to to be
runnable from a configured script, so you can turn it loose and see what's up IRL.

Regards,
Bengt Richter