[Pythonmac-SIG] PackageManager philosophy

[Kevin Ollivier]

On Saturday, August 2, 2003, at 03:11  PM, Jack Jansen wrote:

> As it turns out Bob's ideas and my ideas are pretty similar, see his 
> last message.
>
> The only difference seems to be that I prefer to have a small number 
> of moderately rigorously (if that isn't a contradictio in terminis:-) 
> tested modules, and he wants a more comprehensive set of lightly 
> tested modules.
>
> And Kevin points at a solution:
>
>> To make PM behave more in line with your goals (as I understand them, 
>> anyways) while still giving Bob and others (myself included) the 
>> functionality and flexibility they desire, I was thinking there could 
>> be some sort of "stamp of approval" to say that the 'scapegoat' 
>> (Package Inspector - PI? =) has tested package X binaries on 
>> platforms X, Y and Z. A warning could pop up if such an approval 
>> doesn't exist - "Warning: This package has not been confirmed to work 
>> on your particular platform or sufficiently tested. If you experience 
>> any installation problems, please report any problems to 
>> scapegoat at python.org" - sort of like digital signatures. Or, the end 
>> user could configure PM to simply not show any untested packages. (it 
>> could also be shipped this way by default)
>
> I think the stamp of approval is that a package is in the default 
> database. How about the following: per platform there are two 
> databases, the stable one and the experimental one. The experimental 
> one is easier to select than currently, probably with a checkbox. The 
> experimental database is actually only a set of include directives 
> pointing off to a small number of databases maintained by Bob, Kevin, 
> me and a few others. PM is modified so that when a database is 
> included it knows that the maintainer of the included database is the 
> scapegoat for those packages (currently the maintainer of the toplevel 
> database is responsible for everything).

I'd like the experimental database to not have an 'official' scapegoat; 
that is, anyone could add their own packages in (ala PyPI). Then, 
anyone can add a package and if there is a demand, it could get moved 
into the stable database.

> One problem that we would still need to solve on the user side 
> (there's lots of issues to solve on the scapegoat side) is that of 
> finding packages, especially in the potentially large experimental 
> database. The logical thing to do would be to use the PyPI model, but 
> as of this writing it just doesn't cut it. I just tried find a gui 
> package for MacOSX (pretending I didn't know any names). Whatever I 
> typed in I couldn't find anything. I eventually located pyobjc by 
> typing "cocoa" into the *description* field, but that's it.

IMHO, the basic problem with the PyPI search is that it requires you to 
think about which 'field' contains the term you're searching for. 
Summary? Description? Keywords? I just want to type in a term and have 
it search name AND summary AND description AND keywords AND 
classifiers, unless I specifically tell it not to. I think the 'finder' 
search model works best here - just have a simple text box and have 
people type into it. Then if they click on something (maybe Edit->Find) 
they can be more specific about their search.

Thanks,

Kevin