headers
Medical Knowledge Institute | 2 Jun 2004 00:40

MKI Health Reporter: Take Action Now on Childhood Obesity, Expert Says

=========================================================
M.K.I   N.E.W.S.L.E.T.T.E.R.
=========================================================

{sectie::Introductie}

---------------------------------------------------------

{sectie::Linksboven}

---------------------------------------------------------

{sectie::Rechtsboven}

---------------------------------------------------------

{sectie::Linksonder}

---------------------------------------------------------

{sectie::Rechtsonder}

=========================================================

Copyright 2004 Medical Knowledge Institute

Website:
http://mki.massmailer.nl/klik.php?m=13&id=8770&url=http%3A%2F%2Fwww.infomki.com

Unsubscribe:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ian Bicking | 16 Jun 2004 03:53
Gravatar

PyPI improvements

Howdy.  I just recently posted some ideas for PyPI 
(http://blog.colorstudy.com/ianb/weblog/2004/06/15.html#P123), but some 
of the basic features I was thinking about should be generally useful:

1. Express relationships between packages.  These are relationships 
like alternative-implementation, fork, part-of, recommends, requires, 
etc.  At the moment I'm thinking purely about displaying this 
information, not any fancy distutils magic installation of 
dependencies.
2. Cache packages.  I.e., download a copy of the package, and if the 
package disappears then we have a backup.

These are both more important when dealing with smaller pieces of code 
-- code that is part of a more interdependent ecosystem (1), and code 
that is more transient (2) -- but these apply just as well to 
full-blown packages.

The other thing that might be useful is some improved categorization of 
code.  The Trove categories are... well, they are stupid.  No fault of 
anyone here.  CPAN's much more coarsely-grained categories are much 
better, in my opinion (Acme, AI, Algorithm, Apache, AppConfig, Archive, 
Array, and so on: http://www.cpan.org/modules/by-module

But even more coarsely-grained than that, there are classes of package. 
  Right now we have libraries and applications.  I'd like to add modules 
-- though the name is vague, I'm thinking of code on the sophisticated 
end of the Python Cookbook entries.  Small, reusable, and not worth 
distutilifying (I just can't imagine making a whole package for one 
100-line module, nor can I imagine using such a package).
(Continue reading)

Permalink | Reply | 7 comments |
headers
Richard Jones | 16 Jun 2004 05:30
Picon

Re: PyPI improvements


On Wednesday 16 Jun 2004 11:53, Ian Bicking wrote:
> Howdy.  I just recently posted some ideas for PyPI
> (http://blog.colorstudy.com/ianb/weblog/2004/06/15.html#P123)

I commented there, but I might repeat some of my comments here too where 
appropriate.

> 1. Express relationships between packages.  These are relationships
> like alternative-implementation, fork, part-of, recommends, requires,
> etc.  At the moment I'm thinking purely about displaying this
> information, not any fancy distutils magic installation of
> dependencies.

There's been a number of proposals and I believe some code towards 
implementing this kind of meta-data capture. 

The two extensions to distutils dealing with this issue that I know of are 
PIMP (/PackMan) and the ZPKG tools:

http://undefined.org/python/pimp/
http://www.python.org/packman/
   (couldn't find a page giving the technical details of PIMP)
http://zope.org/Members/fdrake/zpkgtools/
   (this page has a good list of links to prior discussions / proposals)

Various proposals have also been made on this list. I have no idea how related 
those projects are. It would be a shame to develop *another* system.

> 2. Cache packages.  I.e., download a copy of the package, and if the
(Continue reading)

Permalink | Reply | 6 comments |
headers
Ian Bicking | 16 Jun 2004 06:32
Gravatar

Re: PyPI improvements

On Jun 15, 2004, at 10:30 PM, Richard Jones wrote:
>> 1. Express relationships between packages.  These are relationships
>> like alternative-implementation, fork, part-of, recommends, requires,
>> etc.  At the moment I'm thinking purely about displaying this
>> information, not any fancy distutils magic installation of
>> dependencies.
>
> There's been a number of proposals and I believe some code towards
> implementing this kind of meta-data capture.
>
> The two extensions to distutils dealing with this issue that I know of 
> are
> PIMP (/PackMan) and the ZPKG tools:
>
> http://undefined.org/python/pimp/
> http://www.python.org/packman/
>    (couldn't find a page giving the technical details of PIMP)
> http://zope.org/Members/fdrake/zpkgtools/
>    (this page has a good list of links to prior discussions / 
> proposals)
>
> Various proposals have also been made on this list. I have no idea how 
> related
> those projects are. It would be a shame to develop *another* system.

I'm not entirely clear on all of these, but I think they all are 
looking for dependencies.  Along with that they need canonical 
identifiers, which PyPI already has well enough (package names).  For 
modules this wouldn't work, as the naming would be less unique.  Module 
identifiers would be an issue, but I don't think they'd participate in
(Continue reading)

Permalink | Reply | 3 comments |
headers
Richard Jones | 16 Jun 2004 11:59
Picon

Re: PyPI improvements


On Wednesday 16 Jun 2004 14:32, Ian Bicking wrote:
> For modules this wouldn't work, as the naming would be less unique.
> Module identifiers would be an issue, but I don't think they'd
> participate in automated dependencies quite so much.

If you're going to have some meta-data embedded in the module, then one of 
those fields can be a name in the PyPI namespace.

I think that if the modules are going to be in PyPI, then they've got to have 
a unique name. Names are keys in PyPI (just as they are in CPAN / PAUSE).

> It should mostly take disk space, at least how I'm envisioning it.

Then current python.org (creosote) is definitely not up to the task.

> If 
> each package has a download URL (that's a real download URL, not just a
> web page with other references) then we cache the archives and provide
> a link to that archive if we detect that the source archive is gone.

I guess the issue is how we know what the download_url points to.

I think we agree that the distutils meta-data is going to have to grow some 
additional fields (or single a complex field) that point specifically to 
source, win32 binary, redhat RPM, etc. download files. Of course, for 
projects hosted on sourceforge, all this is moot since there is no such thing 
as a URL pointing to a file (ok, there is, but I suspect your project would 
be booted if you used URLs pointing directly at mirrors).
(Continue reading)

Permalink | Reply | 2 comments |
headers
Ian Bicking | 16 Jun 2004 18:51
Gravatar

Upgrading infrastructure

I also noticed in those comments a note on Postgres, and that it still 
needed to be installed, and who knows when that would happen...

Would it be suffient just to move to a threaded, long-running model 
instead of CGI?  For all its flaws (in a highly concurrent environment), 
I suspect SQLite probably wouldn't be so bad once the CGI overhead is 
gone, and the CGI overhead will be significant even if Postgres is in place.

Thoughts on what to use?

Static generation of a few key files would also be helpful (like the RSS 
feed).

   Ian
Permalink | Reply | 1 comment |
headers
Ian Bicking | 17 Jun 2004 18:48
Gravatar

Category suggestions

Here's a list of categories that I think are unneeded, with a few 
additions as well (marked with +).

Generally I think a category should only exist if ...

(a) Someone would say "I want something like X", where X is a category, 
or...
(b) Having found a package, I want to know if it has property X (e.g., 
licensing, maturity)
(c) It can't be replace with a unamgiuous keyword, or an element of the 
description (e.g., Z39.50)
(d) If a subcategory, a user would be genuinely interested in the 
specific subcategory, where there would be an *excess* of uninteresting 
packages in the parent category.
(e) If not a property-based category (e.g., maturity level), it 
shouldn't apply to a significant number of the packages.  "Utilities" is 
silly.  "Python" is obvious.

With a bit more thought, it would probably be possible to trim the 
remaining categories considerably, and add in some more useful 
categories.  E.g., "metaclasses".  Generally there should be more 
Python-specific categories (e.g., Zope, etc).  Any Python framework that 
has a significant number of packages that depend on that framework 
should be a category.  (Unless a relationship system makes that 
redundant, which might be an interesting way to factor it.)

Maybe the properties should also be removed and turned into normal 
fields.  E.g., we already have a license field.  It's nice to sort on 
free/proprietary, and maybe permissive/GPL (for free) and 
free-but-proprietary/not-free... but maybe those categories can be
(Continue reading)

Permalink | Reply | 4 comments |
headers
A.M. Kuchling | 17 Jun 2004 20:01
Picon
Gravatar

Which PostgreSQL interface?

I've embarked on compiling PostgreSQL on www.python.org, and am
wondering which Python interface to use.  I've used Pygresql and have
been happy with it, but Richard and Ian, I'd like to know if you have
opinions about this.

--amk
Permalink | Reply | 4 comments |
headers
Ian Bicking | 17 Jun 2004 20:36
Gravatar

Re: Which PostgreSQL interface?

A.M. Kuchling wrote:
> I've embarked on compiling PostgreSQL on www.python.org, and am
> wondering which Python interface to use.  I've used Pygresql and have
> been happy with it, but Richard and Ian, I'd like to know if you have
> opinions about this.

PyGreSQL is kind of wonky sometimes.  Psycopg seems to be the better 
interface, in my experience.

   Ian
Permalink | Reply | 1 comment |
headers
Mark W. Alexander | 17 Jun 2004 21:03

Re: Which PostgreSQL interface?

On Thu, Jun 17, 2004 at 01:36:59PM -0500, Ian Bicking wrote:
> A.M. Kuchling wrote:
> >I've embarked on compiling PostgreSQL on www.python.org, and am
> >wondering which Python interface to use.  I've used Pygresql and have
> >been happy with it, but Richard and Ian, I'd like to know if you have
> >opinions about this.
> 
> PyGreSQL is kind of wonky sometimes.  Psycopg seems to be the better 
> interface, in my experience.

This was some time ago, but the author of PyGreSQL stated that he did
not use the DB-ABI compatible mode so his support for it was hit & miss
based on contributions.

psycopg, otoh, was written to the DB-API-2.0 spec, with thread-safety in
mind, and transparently supports connection pooling.

I switched to psycopg and haven't looked back (though I'd be interested
in more current experiences with PyGreSQL.)

mwa
--

-- 
Mark W. Alexander
slash <at> dotnetslash.net

The contents of this message authored by Mark W. Alexander are
released under the Creative Commons Attribution-NonCommercial license.
Copyright of quoted materials are retained by the original author(s).

http://creativecommons.org/licenses/by-nc/2.0/
(Continue reading)

Permalink | Reply | 0 comments |

Gmane