On 05 Jan 2005 07:18:25 -0800, Paul Rubin <http://[EMAIL PROTECTED]> wrote:
>Ville Vainio <[EMAIL PROTECTED]> 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
--
http://mail.python.org/mailman/listinfo/python-list
