Discussion of an index of Python resources

Jeremy Hylton | 26 Aug 2003 16:06

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

headers

Richard Jones | 27 Aug 2003 01:36

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)

headers

Jeremy Hylton | 27 Aug 2003 05:30

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)

headers

Richard Jones | 27 Aug 2003 06:28

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)