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

[has]

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.

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?


>>>I think your effort would be better spent filing bugs, feature 
>>>requests, and PEPs for what we have.  It's definitely not as 
>>>fundamentally flawed as you make it out to be.  If you really do 
>>>believe it's broken beyond repair, then feel free to start 
>>>developing an alternative.
>>
>>You've told me this already, and I've done exactly that. And I've 
>>asked for feedback on what I've done and whether it would be 
>>suitable for inclusion in the standard distribution, and I'm 
>>_still_ waiting for a response.
>
>Ok, here's some feedback.

Thank you. And I say that with 100% absolute sincerity. Just what the 
doctor ordered.


>I downloaded PyMod and the following things happen:
>- It launches with a window that says "Path" and has some buttons. 
>If it worked, I wouldn't really know what to do with it.  Path to 
>what?

Path to the setup.py script of the distutils package to build or 
install. Or to a .zip or .tar.gz archive assumed to be a compressed 
package. (Note: I suspect I should cater to other compressed forms 
too, e.g. .tar.bz2 or whatever it's called. Any easy way of doing 
this, other than writing a different archive-decompression shell 
script each time?)

FWIW, the tool tip and built-in help do explain what this field is 
for. But you're quite right that the visible label is poor, so I'm 
wide open to suggestions for a better name.


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

To use PyMod, the user must first specify the Python executable with 
which to run distutils via the combo text field in the Preferences 
dialog. For their convenience, a list of known python executables is 
provided under the combo box's drop-down menu, so folks can usually 
just pick the one they want without having to type the path from 
scratch (though they can do that too if.

Given the length of the delay, the application should really do 
something to indicate it's working rather than just frozen, e.g. drop 
down a sheet with a barber-pole and "Looking for installed python 
executables..." message.

Though see the next point for why this may cease to be an issue anyway...


>- Eventually it comes up with an error dialog that says "find: 
>/usr/local/pgsql/data: Permission denied" twice, with a Quit button.

Looks like my genius shell script just blew up. I'm open to suggestions:

-  Could a better 'python exe locator' be written?

- Or should I bundle one in the app, or just link dynamically to the 
MacPython framework? Though if I did that, how then would users 
indicate which Python installation they wanted to install into?

-  Or I could hardcode a few 'reasonable guess' paths like 
/usr/bin/python, /usr/local/bin/python, /usr/local/bin/pythonw (whose 
presence I can easily check for at startup and eliminate invalid 
paths from the list before showing it to the user). That'd be easy 
enough to do, and might be an adequate compromise. (It'd also 
eliminate the slow startup.)

- Or I could just leave it entirely to the user to key in the path(s) 
they want. (Not very friendly, but about as simple and reliable as it 
could get.)


>- After clicking Quit, which is the only thing I am allowed to do, 
>it pops up another dialog titled "AppleScript Error" that says 
>"NSReceiverEvaluationScriptError: 4(1)" with an Ok button.

Yeah, welcome to Cocoa Scripting. Worst. Error. Messages. EVER. 
Scripters have been bollocking Apple over its cruddy incomprehensible 
error messages since year dot, and they still haven't sorted it yet. 
(This is one of the reasons I've been making appscript so anal about 
checking event params, specifiers, etc. before dispatching them, btw; 
better the premature faked-up error message you can grok than the 
real one you can't.)

Anyway, it's noted now. Though I'll not worry too much about this one 
right now, as it's probably just a knock-on effect from the other 
bugs, so let's see if it clears up when those are fixed.


>- I cilck Ok, and it quits.

Yayy! SOMETHING worked! ("But it works just fine OMM!")

Anyway, this is what [third-party user] testing is for. Much 
appreciated, and in return I've posted a modified version with the 
funky 'python mis-finder' script disabled so you can [hopefully] try 
the rest of it out:

http://freespace.virgin.net/hamish.sanderson/PyMod_for_Bob.sit

Let me know what other horrors you find. ;)

(BTW, delete any PyMod.plist preferences file before running, just to 
get a clean shot at it.)


>So much for simple, general-purpose, reusable software eh?

When your v0.3 releases are all the very shining models of 
perfection, I'll happily concede you that jibe... but NOT before. :p

Thanks,

has
-- 
http://freespace.virgin.net/hamish.sanderson/