[Pythonmac-SIG] PackageManager philosophy
kevino at tulane.edu
Sat Aug 2 17:20:28 EDT 2003
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.
More information about the Pythonmac-SIG