From altis@semi-retired.com Sat Aug 2 23:45:25 2003
From: altis@semi-retired.com (Kevin Altis)
Date: Sat, 2 Aug 2003 15:45:25 -0700
Subject: [Catalog-sig] RE: [Pythonmac-SIG] PackageManager philosophy
In-Reply-To: <3F7A4DE4-C536-11D7-9384-000A27B19B96@cwi.nl>
Message-ID: <KJEOLDOPMIDKCMJDCNDPIEOKDOAA.altis@semi-retired.com>
> 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.
The other side of the coin is whether the fields that make up the PyPI info
need to be expanded or get more structure for things like the keywords. The
trove categories are quite limited.
ka
From richardjones@optushome.com.au Sun Aug 3 00:12:47 2003
From: richardjones@optushome.com.au (Richard Jones)
Date: Sun, 3 Aug 2003 09:12:47 +1000
Subject: [Catalog-sig] RE: [Pythonmac-SIG] PackageManager philosophy
In-Reply-To: <KJEOLDOPMIDKCMJDCNDPIEOKDOAA.altis@semi-retired.com>
References: <KJEOLDOPMIDKCMJDCNDPIEOKDOAA.altis@semi-retired.com>
Message-ID: <200308030912.51894.richardjones@optushome.com.au>
--Boundary-02=_zVEL/6OgYeFgeau
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Description: signed data
Content-Disposition: inline
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.
=46WIW, I found pyobjc by clicking "browse" then "Environment :: Mac OS X" =
=2E.. I=20
presume this means that the interface is not user-friendly enough? Perhaps =
it=20
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=20
submission to the index. I think it'd be a valuable change, if others=20
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.
>
> http://www.python.org/pypi?:action=3Dsearch_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 agree with this. The search part of the interface was quick-n-dirty :)
In terms of the "present a list of all the Classifiers" ... have you tried =
the=20
browsing interface? I recently fixed a bug so it no longer hides Mac OS X=20
apps (and emailed the pythonmac-sig, but I don't know whether my message wa=
s=20
allowed through moderation).
> I would probably put that=20
> 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.
>
> The other side of the coin is whether the fields that make up the PyPI in=
fo
> need to be expanded or get more structure for things like the keywords. T=
he
> trove categories are quite limited.
IMO, keywords are far from structured unless there's a strict set of them -=
=20
and that's what the trove categories are for. I'm always willing to accept=
=20
new classifiers for the places where it's lacking. A statement like "quite=
=20
limited" leads me to believe you see large holes in its coverage - please, =
I=20
need to know where those are or it'll never be fixed.
Richard
--Boundary-02=_zVEL/6OgYeFgeau
Content-Type: application/pgp-signature
Content-Description: signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
iD8DBQA/LEVzrGisBEHG6TARAgeeAJwLt4n5aa/jXjA39Qd8YWAIiA1AjwCeJw76
MShTA7mYqZUJXkyWJ7r4d0Y=
=22n+
-----END PGP SIGNATURE-----
--Boundary-02=_zVEL/6OgYeFgeau--
From jeremy at alum.mit.edu Tue Aug 26 11:02:15 2003
From: jeremy at alum.mit.edu (Jeremy Hylton)
Date: Tue Aug 26 10:02:24 2003
Subject: [Catalog-sig] sig page has wrong info
Message-ID: <1061906534.2290.117.camel@localhost.localdomain>
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
From jeremy at alum.mit.edu Tue Aug 26 11:06:43 2003
From: jeremy at alum.mit.edu (Jeremy Hylton)
Date: Tue Aug 26 10:07:04 2003
Subject: [Catalog-sig] names vs. releases
Message-ID: <1061906802.2290.122.camel@localhost.localdomain>
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
From richardjones at optushome.com.au Wed Aug 27 10:36:37 2003
From: richardjones at optushome.com.au (Richard Jones)
Date: Tue Aug 26 19:36:49 2003
Subject: [Catalog-sig] names vs. releases
In-Reply-To: <1061906802.2290.122.camel@localhost.localdomain>
References: <1061906802.2290.122.camel@localhost.localdomain>
Message-ID: <200308270936.37384.richardjones@optushome.com.au>
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
> if they want to see different releases. I expect most users will just
> want the most recent release.
As partially demonstrated above, the problem is that it's hard for a program
to know what the "most recent release" is, especially when a project has
stable and unstable branches both producing releases.
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 release"? PyPI
uses distutils' version number sorting code, but do you want to see the
package with the highest version number, or the one that was updated most
recently? Modifying the interface to do this would be a bit of work, and
assuming we have a consensus on "most recent release" then I'd be happy to
accept a patch (project members welcome :)
Richard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
Url : http://mail.python.org/pipermail/catalog-sig/attachments/20030827/ededa250/attachment.bin
From amk at amk.ca Tue Aug 26 18:58:55 2003
From: amk at amk.ca (A.M. Kuchling)
Date: Tue Aug 26 21:55:03 2003
Subject: [Catalog-sig] sig page has wrong info
In-Reply-To: <1061906534.2290.117.camel@localhost.localdomain>
References: <1061906534.2290.117.camel@localhost.localdomain>
Message-ID: <20030826215854.GA16939@nyman.amk.ca>
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
From jeremy at alum.mit.edu Wed Aug 27 00:30:19 2003
From: jeremy at alum.mit.edu (Jeremy Hylton)
Date: Tue Aug 26 23:30:17 2003
Subject: [Catalog-sig] names vs. releases
In-Reply-To: <200308270936.37384.richardjones@optushome.com.au>
References: <1061906802.2290.122.camel@localhost.localdomain>
<200308270936.37384.richardjones@optushome.com.au>
Message-ID: <1061955018.13897.27.camel@localhost.localdomain>
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
happy if we only got one current release for each name.
> 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 release"? PyPI
> uses distutils' version number sorting code, but do you want to see the
> package with the highest version number, or the one that was updated most
> recently? Modifying the interface to do this would be a bit of work, and
> assuming we have a consensus on "most recent release" then I'd be happy to
> accept a patch (project members welcome :)
Yes. I'm thinking that the ZODB3 package should be listed with the
update time and description from the most recent package. Since it's
just a summary page, it doesn't matter much to me if it's the most
recent update or perhaps the most recent non-alpha/beta release.
Thinking out loud: Then the link from "ZODB3" wouldn't go to a specific
release page like it does now. It would go to a page that listed all of
the releases. Or it could list the most recent release with links to
earlier releases on that page.
Jeremy
From richardjones at optushome.com.au Wed Aug 27 15:28:03 2003
From: richardjones at optushome.com.au (Richard Jones)
Date: Wed Aug 27 00:28:23 2003
Subject: [Catalog-sig] names vs. releases
In-Reply-To: <1061955018.13897.27.camel@localhost.localdomain>
References: <1061906802.2290.122.camel@localhost.localdomain>
<200308270936.37384.richardjones@optushome.com.au>
<1061955018.13897.27.camel@localhost.localdomain>
Message-ID: <200308271428.07045.richardjones@optushome.com.au>
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
> > release"? PyPI uses distutils' version number sorting code, but do you
> > want to see the package with the highest version number, or the one that
> > was updated most recently? Modifying the interface to do this would be a
> > bit of work, and assuming we have a consensus on "most recent release"
> > then I'd be happy to accept a patch (project members welcome :)
>
> Yes. I'm thinking that the ZODB3 package should be listed with the
> update time and description from the most recent package. Since it's
> just a summary page, it doesn't matter much to me if it's the most
> recent update or perhaps the most recent non-alpha/beta release.
OK. Does anyone disagree with this?
> Thinking out loud: Then the link from "ZODB3" wouldn't go to a specific
> release page like it does now. It would go to a page that listed all of
> the releases. Or it could list the most recent release with links to
> earlier releases on that page.
I don't believe users should have to select a version (ie. select package,
then select version) to get information about a package. The first page they
see relating to a package could list the most recently updated release
information, with links to other versions from that page.
Note: I don't have time to work on this at the moment!
Richard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
Url : http://mail.python.org/pipermail/catalog-sig/attachments/20030827/41519b33/attachment.bin