[Pythonmac-SIG] Pack Man issues on OS X 10.3.4

[Ronald Oussoren]

On 7-jun-04, at 14:38, has wrote:

> Bob Ippolito
>
> [snip 'Bill Cosby' moment]
>
>> PackageManager was designed to have as simple of an *implementation* 
>> as possible, and it pretty much does.  You do a lot of hand-waving 
>> about how awful it is, but the reality is that it is VERY simple and 
>> works pretty well.  The GUI application is horrible and has lots of 
>> bugs, but that is easy to fix.  The underlying system doesn't have 
>> very many real problems.
>
> My problem isn't that it's inherently awful, it's that it's inherently 
> pointless. 1. Expending 100% of labour creating a solution that caters 
> to <1% of module installations if not an efficient use of extremely 
> scarce, and therefore extremely valuable, manpower and brainpower 
> resources (i.e. yours, Jack's and the other core MacPython 
> developers). 2. Its administration model is inherently non-scalable, 
> being utterly dependent on the good will and hard work of a few elite 
> MacPython gurus to maintain its custom databases.

PackMan tries to provide an easy to use interface for installing 
*tested* packages. I hope it
will grow an easy to use interface for maintaining a database and for 
doing coopereative management of the database. The debian projects 
seems to manage this just fine for an entire
Linux distribution :-)

What you seem to forget is that there is a difference between theory 
and practice. In theory
installing a package is as easy as 'tar zxf some-packaget.tgz && cd 
some-package && python setup.py install'. In practice, there are a 
number of interesting packages where you have to modify setup.py or 
some other configuration file before you get a working installation.

An anecdote from the real world: this morning I tried to install the 
perl BerkelyDB package on a Solaris machine at work. The obvious way to 
do this is "perl -MCPAN -e 'install BerkelyDB'", but that didn't work 
because it's config.in contained data that didn't work on this 
particular machine.

I've had simular problems with python python packages.

There's also a big mound of software that assumes that the entire Unix 
world uses Linux.

>
> I've stated several times that I couldn't care less about the state of 
> its GUI. PackMan's major problem _isn't_ its technical glitches (which 
> can be easily resolved with a bit of elbow grease as we're both happy 
> to acknowledge). It's a complete failure to perform a proper 
> cost-vs-benefit analysis of its basic concept/design, which would 
> quickly show it to be a classic white elephant, impossible to support 
> at the kind of level that would make it genuinely useful due to the 
> high ongoing support costs that will spiral out of control long before 
> you ever reach that point. And _that_ is the foundation of my argument 
> for abandoning PackMan and starting over again. (So please don't haul 
> out the old "minor technical glitches" canard again, because it'll 
> only annoying me... and Hulk Smash when he get angry, which won't do 
> any of us any favours.)
>
> So if you want to refute my argument as an unmigitated load of old 
> codswallop then you're going to have to explain how the logistics of 
> creating, expanding and maintaining a centrally managed package 
> database can be justified, and how they're not going to cause the 
> entire system to slowly suffocate under its own weight. (Because, you 
> know, that whole central planning and control thing really didn't pan 
> out too well for the old USSR or People's Republic of China.) And how 
> it's going to be more cost-effective than cutting a deal with 
> something like PyPI that already has a robust and sustainable - not to 
> mention well established and quite successful - model for doing this 
> sort of thing. (Decentralisation rocks. Cooperation rocks.) Because as 
> the whole history of software development shows, a 50%-good practical 
> solution that addresses 90% of the common need will beat out a 
> 100%-perfect ivory tower one that obsesses over a few % of corner 
> cases to the neglect of everything else.
>
> I realise a lot of programmers get a bit funny about throwing out 
> "working" software, but that's just something y'all need to get over. 
> e.g. See the arts and sciences which, being rather older and wiser 
> than software dev, have no such hangups about letting go and moving 
> on. Time to cast aside your inner albatrosses, yes?

The hardware engeneering folks are very serious about creating working 
stuff, I suppose programmers get inspired by that (why else would we 
have the misnomer software engeneering?).

BTW. PyPI isn't very useful as a component of a larger system (at least 
not at the moment). It doesn't seem to have a UI for querying it 
programmaticly, there are no links to downloadable archives (neither 
source nor binary), .... Fixing those issues is at least as much work 
as fixing PackMan, that's without considering the "politics" that would 
be needed to get those changes accepted.

>
>
>> - I can't focus the application because it's busy doing something. 
>> There is no indication of what this something is.
>
> There's a few seconds' delay upon startup as it initialises itself. I 
> suspect the bottleneck is the following shell script:
>
> 	find /usr -name python; find /usr -name pythonw

Like some others noted I'd hardcode a few know locations 
(/usr/bin/python, /usr/local/bin/python, /opt/darwinports/python, 
/sw/bin/python, ...) instead of running find. Your find manages to mis 
some of the interesting locations :-)

ronald
--
X|support bv            http://www.xsupport.nl/
T:  +31 610271479       F:  +31 204416173