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: > 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: References: 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