Python evolution: Unease

[Paul Rubin]

bokr at oz.net (Bengt Richter) writes:
> I agree 1000% !! Importing a stub should get you an imported stub that
> prints info as it imports, so you know its not functional. 

But I don't even understand why I'd even want to use these stubs,
instead of just having the full installation from day 1.

> >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.
> 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.

I might want the latest enhancements for particular programs that I'm
willing to devote a lot of attention to, but for the most part I don't
want to be a beta tester, I only want to use stable software, where
the definition of stable is that the latest version isn't much
different from the previous version.  I try quite hard to avoid ever
upgrading software ("upgrade" means replace an existing, working
version of something with a newer version) on my PC.  I only want new
software when I buy a new computer, or at least a new hard drive.  I
don't try to migrate system or configuration files.  I just install
the OS distro from scratch and migrate my user files.

> 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.

How can it work just as well, when it requires a high-speed internet
connection which I might not have?  And why is "just as well" good
enough, given how inconvenient and error-prone it is, compared with
just installing from a DVD once and for all?  To have any attraction
what ever, the installation stub scheme (for me at least) has to work
"an order of magnitude better", not "just as well", as a one-time
complete install.

> 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.

One part of the problem is excessive version dependence between
package X and package Y.  That's why I think there should be more
integration within packages, i.e. the Python distro should include a
lot more modules that you currently have to download from other
places.

> 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? 

Huh?  Getting those stubs to work properly has to be even harder than
getting the distros to play nice with each other in the first place.
So I'd rather that the stub-writing effort instead be put into
eliminating the version conflicts.

> With broadband most apps will be ready before you can make fresh
> coffee, or maybe watch the Simpsons.

In reality, whenever I try to install or download anything, something
fails as often as not.  I don't think I've ever seen a CPAN download
work right on the first try.  Really, I just want to buy a new
computer, turn it on, and have everything there.  That's generally
impossible without running satanware from Redmond, so I approximate it
as best as I can by doing a DVD install on new computers.  I don't
care if the software I'm running isn't the bleeding-edge latest.  GCC
today isn't different from GCC five years ago in any way that I care
about.  With Emacs, it's more like 10 years.  I buy a new computer
every 2 years or so, which means that any software I'm using by then
will be at least 2 years old unless it's something I'm making special
effort to stay on top of.  If it's already a year or so old when I
first start running it, I'm ok with that.

> 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.

Since all these schemes have failed whenever they've been tried, all I
can think is that it's a harder problem than it sounds.