[Pythonmac-SIG] PackMan engine version 0.4

[Bob Ippolito]

On Mar 3, 2004, at 1:38 PM, has wrote:

> Bob wrote:
>
>>   And then there's the C dependency game.  If you have Fink 
>> installed, it can really screw things up, too.
>>
>> Basically, you just haven't been trying to compile the 'right' 
>> modules, and you don't have an environment that gets in the way.
>
> I've been compiling the modules that I've needed; so you could say 
> they're the 'right' ones for me. And my environment is straight out of 
> the box; I'm not smart enough to modify it, and therefore not smart 
> enough to break it either. :)

Yes, and that's fine, but many of the modules I offer are ones that 
people can't compile on their own without some serious hand holding.  
I'd rather just give it to them in binary form than hold everyone's 
hand.  I'd rather code than do tech support.. :)

> I do understand what you're saying, btw, so feel I ought to clarify 
> where I'm coming from as it's rather a different perspective and I 
> don't want anyone to think I'm just doing this to honk folk off with a 
> malicious troll or anything like that:

The more input, of any kind, the better.

> First, the reason for asking these questions is that I already realise 
> PM has been designed to handle the worst-case installations; however, 
> in doing so it's completely dropped the ball on light-to-average 
> installations. First rule of software usability: simple things should 
> be simple, difficult things should at least be possible. PM, in trying 
> hard to make latter simple, completely neglects the former; and it's 
> reasonable to assume that it's the former that makes up the vast 
> majority of use cases.

I think you have the wrong impression here.  PM is certainly not 
designed to handle worst-case installations.  I would say the opposite, 
it is designed to handle only best-case situations, and isn't capable 
of dealing with much deviation without kicking, screaming, and possible 
explosion.  From what I can tell, the constraint on PM's design was to 
minimize development effort (Jack calls this a "straw man" 
implementation).  Its usability and flexibility sucks because the 
"engine" is oversimplified, distutils doesn't understand a three level 
system (vendor/admin/user) or dyld linking, current versions of Python 
are linked and installed in strange ways, and the GUI implementation is 
just uh.. awful.

> Now, this wouldn't be such a problem if PM was positioned as a 
> complement to a broader distribution mechanism; the latter taking care 
> of light-to-average installations, with PM stepping in only for those 
> special-cases that the more general system isn't intended to cater 
> for. However, it seems to be marketed as the main [sole?] system for 
> _Mac_Python users to install third-party modules.

I don't agree with you here.  If PM was better, this wouldn't be an 
issue.  It's marketed as the only option to install third-party modules 
other than compiling them yourself because well, it *is* the only 
option.  Is it the best option? Certainly not.  Is suffering through a 
PM session better than compiling it yourself?  In some cases, yes.

> So, to summarise where I'm going with this... I see three main areas 
> where PM has problems: 1. usability, 2. concept/policy and 3. 
> positioning/marketing. The first is what folk are most likely to 
> identify problems in simply because it's the most obvious. However, 
> although I've found various usability flaws myself, I'm not going to 
> ignore these for now and concentrate on what I see as much more 
> significant problems in the other two areas.

1. Improvements to the implementation will fix usability.
2. Could you elaborate on what you mean by concept/policy?
3. Because of its "straw man" implementation, it's not even ready for 
any real position/marketing.

-bob