[Pythonmac-SIG] PackMan engine version 0.4

[Kevin Ollivier]

Hi,

On Mar 8, 2004, at 8:01 AM, has wrote:

[snip]

>> and the GUI implementation is just uh.. awful.
>
> Also redundant. (e.g. PyPI provides a reasonably good graphical 
> interface for browsing/searching for modules; why not try to lever 
> that?)

BTW, on the GUI front, you mind find wxPackMan to be an improvement... 
=) http://www.theolliviers.com/python/wxpm/

This isn't any radical revision, just something to simplify the 
interface a bit and prepare us for a cross-platform offering. =)

>
>>> 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.
>
> This statement is incorrect. The vast majority of third-party modules 
> require no compilation, being written in pure Python. These are 
> precisely the modules PM fails to consider because all its attention 
> is on the small number of modules that do contain C extensions. Worse, 
> there's no way PM can reasonably address this omission, as its 
> reliance on centralised 'gurus' to do all the support work means its 
> scalability is inherently poor.
>
> This is another aspect of PM's flawed "policy", btw; placing too much 
> control/responsibility in the hands of a few individuals upon whom all 
> other developers and users must rely to get anything done. PyPI's 
> decentralised model, where each developer is wholly responsible for 
> managing their own work is much more robust. (BTW, earlier you 
> mentioned the need for platform gurus to ensure third-party modules 
> are MacPython-compatible; the decentralised model in no way prevents 
> this: 'gurus' can work directly with third-party developers to resolve 
> compatibility issues or produce their own repackaged distros as they 
> like.)

Yes, I agree. I think the major failing with PackMan's current design 
model is that it places responsibility on specific people, and this 
being open source, whether or not these people will have time to 
maintain the packages is very uncertain and more importantly varies 
with time. I understand Jack's point about having "Quality Assured" 
packages, but again this is open source, why not have the *community* 
Quality Assure the packages? For example, enable a "report a bug" 
feature in the GUI to send the package maintainer, and also the 
'scapegoat', an error report containing the user's system info and 
comments about how the install or compilation failed. Since PackMan can 
detect unsuccessful installs, this process could be mostly automated. 
The system could also, with the user's explicit permission, send a 
successful installation report to the database so that PackMan can know 
how many people have successfully installed the package, by platform, 
and thus have a rough idea of how stable the package installation is. 
We could even categorize those packages as 'stable' or 'unstable' so 
that people can make the call as to whether to use unstable packages or 
not. (Stable could even be determined by number of successful installs 
or similar criteria.) A package rating system could also be in place.

Of course, the integration with PyPI and its centralized database makes 
a lot of sense to me here. I've always thought it would be good for 
PackMan to pull package metadata from PyPI and utilize that.

I personally think this route could make Jack and others happy without 
overly burdening any one person to do testing on a variety of platforms 
and versions. I personally would have no problem installing a module in 
the unstable branch, and would be happy to provide an error report if 
something went wrong, and I think there's lots of folks like me. I 
actually think that the error reporting feature would also provide an 
extra incentive for package developers to use PackMan - getting a good 
error report from a user isn't always the easiest thing to do. =)

Thanks,

Kevin