headers
Kevin Altis | 3 Aug 2003 00:45

RE: [Pythonmac-SIG] PackageManager philosophy

> From: Jack Jansen
>
> 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.

This is likely a combination of issues. One is that PyPI has a variety of
different descriptors, some of which overlap, and only one field, the
Classifiers is actually structured data, and only two fields: name and
version are actually required for a PyPI entry.

The search page let's you enter Summary, Description, and Keywords, though
those should probably be reserved for an Advanced Search. The advanced
search could also present a list of all the Classifiers or somehow present a
more detailed specification from the trove categories.

  http://www.python.org/pypi?:action=search_form

So, there should be simple one field search that does a case-insensitive
search of all the fields to get the most hits. I would probably put that
search on the main PyPI page and have both simple and advanced searches on
the Search page.

Even if PyPI doesn't follow the simpler model, the Package Manager can do
its own simple search.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Richard Jones | 3 Aug 2003 01:12
Picon

Re: [Catalog-sig] RE: PackageManager philosophy

On Sun, 3 Aug 2003 08:45 am, Kevin Altis wrote:
> > From: Jack Jansen
> >
> > 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.

FWIW, I found pyobjc by clicking "browse" then "Environment :: Mac OS X" ... I 
presume this means that the interface is not user-friendly enough? Perhaps it 
needs to be more prominent? Differently worded?

> This is likely a combination of issues. One is that PyPI has a variety of
> different descriptors, some of which overlap, and only one field, the
> Classifiers is actually structured data, and only two fields: name and
> version are actually required for a PyPI entry.

It's already been suggested that the classifiers field be required for 
submission to the index. I think it'd be a valuable change, if others 
agree...

> The search page let's you enter Summary, Description, and Keywords, though
> those should probably be reserved for an Advanced Search. The advanced
> search could also present a list of all the Classifiers or somehow present
> a more detailed specification from the trove categories.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jeremy Hylton | 26 Aug 2003 16:02
Picon
Favicon

sig page has wrong info

http://www.python.org/sigs/catalog-sig/

says:
"""SIG on Tabular Databases in Python
This list is intended to work through and resolve issues related to
tabular database access from Python. Being somewhat related, this list
may also cover persistency issues in Python.

The list will cover a number of topics, attempting to produce
documentation, modules, and/or sample code.
"""

Has this page always been a copy of the db-sig page?  Or did something
go wrong?

Jeremy
Permalink | Reply | 1 comment |
headers
Jeremy Hylton | 26 Aug 2003 16:06
Picon
Favicon

names vs. releases

The current package index lists every release of as a separate item.  If
a look at a set of packages, I will see separate entries for each
release of a package.  I'm keenly aware of this, because I do a lot of
ZODB releases; there are nine different entries with two different names
in pypi.

How hard would it be to collapse the nine ZODB entries into a two
packages, one with eight releases and the other with one?  It seems more
useful to have a single entry for each package, and let users drill down
if they want to see different releases.  I expect most users will just
want the most recent release.

Jeremy
Permalink | Reply | 3 comments |
headers
Richard Jones | 27 Aug 2003 01:36
Picon

Re: names vs. releases

On Wed, 27 Aug 2003 12:06 am, Jeremy Hylton wrote:
> The current package index lists every release of as a separate item.  If
> a look at a set of packages, I will see separate entries for each
> release of a package.  I'm keenly aware of this, because I do a lot of
> ZODB releases; there are nine different entries with two different names
> in pypi.

This is what the "hide" flag on the releases is for (see the "tip of the week" 
on the front page that's been active for the last couple of months :)

> How hard would it be to collapse the nine ZODB entries into a two
> packages, one with eight releases and the other with one?

What criteria is used to determine which bucket the releases fall into? 
Currently ZODB has these releases:

ZODB3 3.1.2
ZODB3 3.1.2b1
ZODB3 3.1.2b2
ZODB3 3.1.3
ZODB3 3.2a0
ZODB3 3.2b1
ZODB3 3.2b2
ZODB3 3.3a1

So from my guessing, there's a stable release (3.1.3) and two development 
releases (3.2b2 and 3.3a1) currently active.

> It seems more 
> useful to have a single entry for each package, and let users drill down
(Continue reading)

Permalink | Reply | 2 comments |
headers
A.M. Kuchling | 26 Aug 2003 23:58
Picon
Gravatar

Re: sig page has wrong info

On Tue, Aug 26, 2003 at 10:02:15AM -0400, Jeremy Hylton wrote:
>Has this page always been a copy of the db-sig page?  Or did something
>go wrong?

Curious; the page in pydotorg CVS is OK.  I can't figure out what
happened, maybe a manual scp that messed up.  I've run "make install"
to fix things up.

--amk
Permalink | Reply | 0 comments |
headers
Jeremy Hylton | 27 Aug 2003 05:30
Picon
Favicon

Re: names vs. releases

On Tue, 2003-08-26 at 19:36, Richard Jones wrote:
> This is what the "hide" flag on the releases is for (see the "tip of the week" 
> on the front page that's been active for the last couple of months :)

It's never been obvious to me why I would want to login.  What advantage
does it have for the user?  

The tip of the week (I usually ignore tips :-) talks about packages "you
submitted."  Does it apply to all packages or just the ones I own?

> > How hard would it be to collapse the nine ZODB entries into a two
> > packages, one with eight releases and the other with one?
> 
> What criteria is used to determine which bucket the releases fall into? 
> Currently ZODB has these releases:
> 
> ZODB3 3.1.2
> ZODB3 3.1.2b1
> ZODB3 3.1.2b2
> ZODB3 3.1.3
> ZODB3 3.2a0
> ZODB3 3.2b1
> ZODB3 3.2b2
> ZODB3 3.3a1
> 
> So from my guessing, there's a stable release (3.1.3) and two development 
> releases (3.2b2 and 3.3a1) currently active.

When I was talking about two buckets, I meant for ZODB3 and ZODB4. 
We've got different names for the two different major releases.  I'd be
(Continue reading)

Permalink | Reply | 1 comment |
headers
Richard Jones | 27 Aug 2003 06:28
Picon

Re: names vs. releases

On Wed, 27 Aug 2003 01:30 pm, Jeremy Hylton wrote:
> On Tue, 2003-08-26 at 19:36, Richard Jones wrote:
> > This is what the "hide" flag on the releases is for (see the "tip of the
> > week" on the front page that's been active for the last couple of months
> > :)
>
> It's never been obvious to me why I would want to login.  What advantage
> does it have for the user?

The reasons you'd log in are to:

. manually add new packages / releases
. edit existing releases
. remove releases
. remove packages
. hide or unhide releases
. perform role changes

The same interface (ie. HTTP Basic auth etc) is used by the distutils register 
command, BTW.

> The tip of the week (I usually ignore tips :-) talks about packages "you 
> submitted."  Does it apply to all packages or just the ones I own?

Generally, you're the owner of the packages that you submit the initial 
information for. Otherwise you might be a maintainer. Either way, you're 
still submitting information.

> > I *think* you're advocating not to show any version information at the
> > front page, and to suck up the information from the "most recent
(Continue reading)

Permalink | Reply | 0 comments |

Gmane