Python evolution: Unease

[Bulba!]

On Thu, 6 Jan 2005 23:42:40 -0500, "Terry Reedy" <tjreedy at udel.edu>
wrote:
>>> Would it be possible, at least for Windows, to write a Python script 
>>> implementing a 'virtual distribution'?  IE, download Python, install it, 
>>> download next package, install it, etc.  -- prefereably table driven?
>>
>> How would you run the script in the first place?
>
>Duh... with my existing version of Python (which I have had some version of 
>for so long that I had forgotten what it is to not have one handy) ;-).

>Ok, 2 step process for first timers.

That is not a problem. The problem is "complex dependencies
of stuff you use on plethora of stuff you never even heard of,
some of which is missing or WRONG VERSION or broken". 

Sometimes it gets on the nerves of the developers, too - I
remember Vietse Venema, author of Postfix, pulling his 
hair out, because RedHat was systematically shipping the
broken package with DB library that Postfix relied on. 

The significant problem was, even if you tried to rip out 
broken DB package (it was Berkeley  DB IIRC), and replace 
with fixed version, packages X, Y and Z from RH whined 
that they needed previous version. Arrrgh.. (finally, not 
wanting to break dependencies with using things like --nodeps, 
I compiled Postfix entirely myself, with everything in custom
directories - doesn't that defeat the very purpose of having 
the package system in the first place?).

This problem doesn't appear around that often, but when it 
does, it stinks, has warts, and bites you in the bottom.

Now suppose you have a single tree that Vietse blesses or 
not. The problem would never arise in the first place. 
You can't do it in Linux, but you (probably) can do it with
Python.

When you have it ALL in the single distro, released from time
to time, you can easily test it _together_. You don't 
get _temporal dependencies between various versions_.
The released, stable distro has the same things on the
same days, and either it all works together or it doesn't. 

When you depend on a tree of packages, some of which are present 
and some are not,  you _have_ to resolve dependencies like
above on the user's side. Which means development has to be
done for this, like with a dozen or so of online update programs for
Linux (went through it all, from small and primitive programs to
using rpmfind.net almost daily to up2date to yum, to finally arrive
in the near-paradise of apt). Which means some of the precious
and scarce time of developers has to be devoted to solving
unnecessary problem. 




--
It's a man's life in a Python Programming Association.