Python evolution: Unease

[Bengt Richter]

On 05 Jan 2005 23:19:39 -0800, Paul Rubin <http://phr.cx@NOSPAM.invalid> wrote:

>bokr at oz.net (Bengt Richter) writes:
>> 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).
>
>You mean for Python modules, in ordinary operation?  I'd hate that.
>For things like apt-get, used for installing nonstandard programs or
>getting security updates, I guess it's about as good as one can hope
>for.  The user has to activate it explicitly though.  I definitely
>don't want my computer opening internet connections unless I
>specifically ask it to.  Doing otherwise is almost spyware.
I agree 1000% !! Importing a stub should get you an imported stub that
prints info as it imports, so you know its not functional. And just
gives you the options to type help(themodule) or if you know you want
to go ahead, themodule.install() -- and nothing would touch the internet
until you gave a final "yes" to an "Are you sure" at the end of a
what-will-happen-if-you-say-yes summary. I didn't mean any activity
that you don't control. Just activity that you can control easily.

>
>This may sound a little extreme but my distribution philosophy is I'd
>like to get closer to an environment where users normally never
>install any software of any type, ever.  Microsoft cornered the OS
>market cornered by acheiving something pretty close to this: they
>deliver Windows with no installation needed.  When people buy new
>computers, Windows is already on the hard drive, so the user just
>turns the computer on and Windows is there.
It makes a lot of sense for a "core" plus a delivered specific application
base, but IMO if you try to cover the world with a monolith you will
inevitably still have the problem of getting the latest version of
particular packages for bug fixes or enhancements. The more you have
in your giant collection the more that will be true.

>
>Fedora Core (what I'm running now) isn't shipped that way by any
>computer makers that I know of, but it makes up for it by having lots
>of applications included.  So I buy a new computer, put in the
>bootable Fedora DVD-ROM, and sit back for half an hour while a
>one-time installation runs.  That's about as close as I can get to
>just turning on the new computer and having Fedora already there.
>
>> 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.
>
>If I have a 400 gig hard drive, I don't see why I need 99.99% of it
>empty instead of 99.0% after I do my OS install.  I don't want to
>hassle over downloading stuff for hours or days at a time, or about
>what components depend on other components, if the distro can just
>include it.  I just tried to install a Python program that uses
>wxPython, except that meant I had to download both wxPython and
>wxWidgets, and the installations failed because of some version
>mismatch between the current wxWidgets distro and the version of GTK
>included with FC3.  I spent an hour or so messing with it and then
>said screw it and gave up on the GUI part of that program.  I'm more
>technical than most users (I'm a programmer) yet this installation
>stuff is too much hassle even for me.  So I'd really rather that all
>that stuff be pre-configured.
There are several parts to those frustrations. But you are presuming
that they would have been solved for you and put on a DVD with all
dependency problems resolved. Ok, let's assume that. In that case,
an installation stub module could just as well have the solution built
into it as to what versions etc are needed to make the module work.
With a large collection, you may need several versions of some support libs.

To bring a large collection into version-alignment ISTM you need a version
freeze across too many libraries of different kinds with different
development schedules and resources to make it reliable.

So you're still going to need the ability to add updates and new modules
and more. I'd rather see effort going into making that process simple
and reliable (and fully controlled by the user -- i.e. no unauthorized
hidden internet activity!!) than to solve the same version problems
for some mega DVD make file where you don't have the script and config info
in a concise single-problem stub form, and can't ask here for help finding
an updated stub. It's a matter of being able to limit the problem you
need to solve when something particular doesn't work.

When your wxPython-using program didn't work, wouldn't it have been nice
to have downloaded a standard stub program (with older stub versions still
available if you have an older system) and have it tell you what
was missing that it needed before you decided to let it continue and
get those things? Or choose not to? With broadband most apps
will be ready before you can make fresh coffee, or maybe watch the Simpsons.

Otherwise what? Send for a new DVD? Yes, core stuff + plenty of compatible goodies
in a distro is a good idea, but problems are inevitable, and IMO it's more
important to have a standard reliable way to solve problems than to have
them "solved" on periodic monoliths DVDs that can't ever be problem free.

>
>If a system has N downloadable components that are supposedly
>independent, there are 2**N combinations of them that anyone might
>have installed.  In reality the indepdence is never that complete, so
>something can easily go wrong if you pick a combination that hasn't
>been tested and debugged by someone, and there's no way to test more
>than a few of the possibilities.  So I'd rather that all N components
>already be included with the OS so that the combination will have been
>tested by the distro maintainers before the end user has to deal with
You are asking a lot from these distro maintainers if you expect recent
versions of everything, and for them to watch for new stuff to evaluate
and include after researching compatibility problems. They aren't in the
best position to do that. The author/s of the new stuff is/are. And if
such authors had a standard stub module they could prepare, then distros
could include those, and you would find version updates for those rather than
trying to solve the integration problems yourself. And if there were
still bugs, a new version would likely be posted here after some discussion.
And then everyone could have an easy download of the new stub, and be able to
go for coffee. I think if python.org had a trusted-software registry that could
be a flat CSV text file of names, versions, urls, sizes, and md5 digests and maybe
some trust level, then the stubs could access that for a standard way of finding
components. Or course for a DVD distro, stubs could access the DVD rather than
the internet for things at the DVD's version level.

I realize this problem has been "solved" with various RPM and app-loading methods,
but I think python could wrap its solution nicely. I don't think distutils and setup.py
is easy enough to create (at least I have been somewhat frustrated in using it effectively),
though it deals with a lot of what has to be done.

>it.  Hard drives and distro media (DVD) are big enough now that it's
>quite reasonable for distros to include just about everything that
>most users could want.
Agreed for some "core" set. How shall we define what belongs in the "core?" ;-)

Regards,
Bengt Richter