From master@89894.com Tue Feb 11 02:03:26 2003
From: master@89894.com (신용 철)
Date: Tue, 11 Feb 2003 11:03:26 +0900
Subject: [Catalog-sig] (no subject)
Message-ID: <26250-2200322112326812@89894.com>
<HTML> <p align=3D"center">
<FONT size=3D2>=C1=A4=BA=B8=C5=EB=BD=C5=BA=CE =B1=C7=B0=ED =BB=E7=C7=D7=BF=
=A1 =C0=C7=B0=C5 =C1=A6=B8=F1=BF=A1
<B>[=B1=A4=B0=ED]</B>=B6=F3=B0=ED =C7=A5=B1=E2=C7=D1 =B1=A4=B0=ED =B8=DE=C0=
=CF=C0=D4=B4=CF=B4=D9=2E<BR>=BC=F6=BD=C5=C0=BB =BF=F8=C4=A1 =BE=CA=C0=B8=BD=
=C3=B8=E9
<a href=3D"mailto:master@89894=2Ecom?subject=3D=BC=F6=BD=C5=B0=C5=BA=CE">=
<b>=BC=F6=BD=C5=B0=C5=BA=CE</b></a>=B8=A6
=B4=AD=B7=AF=C1=D6=BC=BC=BF=E4</FONT>
<HEAD>
<META NAME=3D"GENERATOR" Content=3D"Microsoft DHTML Editing Control">
<TITLE></TITLE>
</HEAD>
<BODY>
<P> </P>
<P>[=B0=FA=C7=D0] =B2=DE=C0=C7 =BF=A1=B3=CA=C1=F6 =B9=AB=C7=D1 =B5=BF=
=B7=C2</P>
<P>=B9=AB=C7=D1 =B5=BF=B7=C2=C0=BA =B2=DE=C0=C7 =BF=A1=B3=CA=C1=F6=B0=A1 =BE=
=C6=B4=D2 =BC=F6 =BE=F8=BD=C0=B4=CF=B4=D9=2E=2E=2E=2E<BR>=C8=AD=BC=AE =BF=AC=
=B7=E1=B8=A6 =BB=E7=BF=EB=C7=CF=C1=F6
=BE=CA=B0=ED, <BR>=BF=AC=B7=E1=B0=A1=BE=F8=C0=CC =B5=B9=BE=C6=B0=A1=B4=C2 =
=BF=A3=C1=F8=C0=CC =C0=D6=B4=D9=B8=E9 =BF=A1=B3=CA=C1=F6=BF=A1=20
=B4=EB=C7=D1 =B9=AE=C1=A6=B4=C2 =B8=F0=B5=CE =C7=D8=B0=E1=B5=C9 =BC=F6 =C0=
=D6=B0=DA=C1=F6=BF=E4=2E<BR>=C0=DA=B5=BF=C2=F7=B0=A1 =B1=E2=B8=A7=C0=CC =BE=
=F8=C0=CC =B4=DE=B8=B1
=BC=F6=C0=D6=B4=D9=B8=E9=2E=2E=2E=2E=2E?<BR>=BF=AC=B7=E1=B8=A6 =BE=B2=C1=F6=
=BE=CA=B0=ED =B9=DF=C0=FC=B1=E2=BF=A1=BC=AD =B9=AB=C7=D1=C1=A4 =C0=FC=B1=E2=
=B0=A1=20
=B9=DF=BB=FD=B5=C8=B4=D9=B8=E9 =B1=D7 =BE=EE=B5=F0=BF=A1=BC=AD=B5=E7=C1=F6=
=C0=CE=B0=A3=C0=C7 =BB=EE=C0=BA =C7=B3=BF=E4=B7=CE=BF=EF=B0=CD=C0=CC=B8=E7=
,<BR>=C8=AD=BC=AE =BF=AC=B7=E1=C0=C7 =B8=C5=BF=AC
=B0=F8=C7=D8=B9=AE=C1=A6=B4=C2 =B4=F5 =C0=CC=BB=F3=C0=C7 =BF=AC=B1=B8 =B4=EB=
=BB=F3=C0=CC =B5=C9 =BC=F6 =BE=F8=C0=B8=B8=E7=2E=2E=2E=2E=2E</P>
<P>=B1=D7=B7=AF=B3=AA =BE=D6=BC=AE =C7=CF=B0=D4=B5=B5 =BE=C6=C1=F7 =BF=EC=B8=
=AE =C0=CE=B7=F9=B4=C2 =C0=CC =B9=AB=C7=D1 =B5=BF=B7=C2=C0=BB =B0=B3=
=B9=DF=C0=BB =BC=BA=B0=F8
=C7=CF=C1=F6 =B8=F8=C7=DF=BD=C0=B4=CF=B4=D9=2E=2E=2E=2E=2E</P>
<P>=B8=B9=C0=BA =BB=E7=B6=F7=C0=CC =BF=A9=B1=E2=BF=A1 =B5=B5=C0=FC=C0=BB =C7=
=CF=B0=ED =C0=D6=C0=B8=B8=E7 =BC=BA=B0=F8=C0=C7 =B1=D7 =BC=F8=B0=A3 =
=C0=CE=B7=F9=C0=C7
=C7=E0=BA=B9=C0=CF=B0=CD=C0=D4=B4=CF=B4=D9=2E=2E=2E=2E<BR>=C0=CE=B0=A3=C0=BA=
=C0=FA =B9=AB=C7=D1=C0=C7 =B0=F8=B0=A3=20
<BR>=BF=EC=C1=D6=B7=CE =BF=EC=C1=D6=B7=CE =B0=C5=C4=A7=BE=F8=C0=CC =B9=
=DF=C0=FC=C7=D8 =B3=AA=B0=A5 =B0=CD=C0=D4=B4=CF=B4=D9=2E=2E=2E</P>
<P>=C0=CC=B4=C2 =B0=F8=B0=A3 =C1=A6=C7=D1=C0=BB =B9=E7=C1=F6=BE=CA=B0=ED =BF=
=A1=B3=CA=C1=F6=B8=A6 =B9=AB=C7=D1=BB=FD=BB=EA=C7=D2 =BC=F6 =C0=D6=B4=C2 =B9=
=AB=C7=D1 =B5=BF=B7=C2=C0=CC =C0=D6=C0=BB
=B0=E6=BF=EC=BF=A1=B8=B8 =B0=A1=B4=C9=C7=D1 =C0=CF=C0=D4=B4=CF=B4=D9=2E=2E=
=2E</P>
<P>=BF=A9=B1=E2=BF=A1 =B0=ED=C1=A4 =BF=A1=B3=CA=C1=F6=B8=A6 =C0=CC=BF=EB=C7=
=D1 =BF=A3=C1=F8=C0=BB 16=B3=E2=B0=A3=BF=A1=B0=C9=C3=C4 =B2=D9=C1=D8=C8=F7=
=B0=B3=B9=DF=C7=CF=B0=ED=C0=D6=C0=B8=B8=E7
=C3=D6=B1=D9 5=B3=E2=BF=A9=B5=BF=BE=C8 6=C8=B8=BF=A1=B0=C9=C3=C4 =BA=CE=BA=
=D0 =BA=CE=BA=D0=C0=BB =C1=A6=C0=DB=C7=CF=BF=A9 =B0=CB=C1=F5=C0=BB =C7=D8=BF=
=C2=B9=D9=20
=C1=F6=B1=DD=C0=BA =BC=B3=B0=E8=B0=A1 =B8=B6=B9=AB=B8=AE=B5=C7=BE=EE =C1=BE=
=C7=D5 =C0=FB=C0=CE =C1=A6=C0=DB =B0=FA=C1=A4=BF=A1 =BF=CD=C0=D6=C0=B8=B8=E7=
, </P>
<P>=BA=B8=B4=D9 =B8=B9=C0=BA =C0=CC =B5=E9=B7=CE=BA=CE=C5=CD =C7=D4=B2=B2 =
=C7=CF=B0=ED=C0=DA =C4=AB=C6=E4 =BB=E7=C0=CC=C6=AE=B8=A6 =B0=B3=BC=B3=C7=CF=
=BF=A9 =B5=BF=C8=A3=C0=CE=C0=C7 =B2=DE=C0=BB
=B8=B8=B5=E9=BE=EE =B0=A1=B0=ED=C0=DA =C7=D5=B4=CF=B4=D9=2E=2E=2E</P>
<P>=C4=AB=C6=E4 =BB=E7=C0=CC=C6=AE : cafe=2Edaum=2Enet/106030 =C0=D4=
=B4=CF=B4=D9=2E</P>
<P>=B8=B9=C0=CC =B9=E6=B9=AE=C7=CF=BD=C3=BE=EE =C0=DA=B7=E1 =B0=CB=BB=F6=C7=
=CF=BD=C3=B0=ED =B6=C7 =B1=DB=C0=BB =B8=B9=C0=CC =BF=C3=B7=C1 =C1=D6=BC=BC=
=BF=E4=2E=2E=2E=2E</P>
<P> ^^ ** ^^
^^ ** ^^
</P>
<P>tel : 011-281-1434 =BD=C5 =BF=EB =C3=B6</P>
<P><BR></P>
</BODY>
</HTML>
From Jack.Jansen@cwi.nl Tue Feb 11 10:28:10 2003
From: Jack.Jansen@cwi.nl (Jack Jansen)
Date: Tue, 11 Feb 2003 11:28:10 +0100
Subject: [Catalog-sig] Fwd: [Pythonmac-SIG] Install manager engine available
Message-ID: <846613F9-3DAB-11D7-8CF6-0030655234CE@cwi.nl>
Andrew Kuchling suggested I also post this announcement here. I was
actually going to keep this module
more-or-less secret until 2.3 is out, because I need it for a very
specific problem and I at this moment
I don't have the time to go into full-fledged design discussions (and
an install manager can be an
incredible sink of design effort:-). I'll elaborate a little on the
design below, though.
Begin forwarded message:
> From: Jack Jansen <Jack.Jansen@cwi.nl>
> Date: Mon Feb 10, 2003 17:07:48 Europe/Amsterdam
> To: pythonmac-SIG@python.org
> Subject: [Pythonmac-SIG] Install manager engine available
>
> Folks,
> the install manager for Python we discussed last fall is available. At
> least: the engine is. At least:
> there's enough of the engine that it managed to install Numeric and
> PIL, and actually notice it had
> done so:-)
>
> It is called the Package Install Manager for Python and it lives in
> Lib/plat-mac/pimp.py. If you wonder
> about the name, think that "it may be shabby, but it gets you what you
> need" :-) There's docstrings
> all over the place, and that is also the only documentation. The pimp
> module has a minimal commandline
> interface, I'm going to work on a GUI next.
>
> It only works for Python 2.3a1 on MacOSX 10.2 at the moment, but I
> would at least like it to work
> for older Pythons and older MacOSX releases as well, so any help there
> is appreciated.
>
> I would like it if people could test this with other packages (wxMac,
> PyOpenGL, PyObjC, etc), and if
> they could test it with binary packages. For 2.3a2 I would like to
> have a sizable number of packages
> in there (at least the 5 mentioned above, maybe more). During
> development I guess it's probably best
> if I am the maintainer of the pimp database, but I would like to push
> that responsibility off as soon
> as possible, so if anyone feels like doing this: please speak up!
>
> If you try this with your favorite package and notice there is
> functionality missing: speak up! I would
> like to keep functionality as minimal as possible, but no smaller. (As
> an example: I had to add the preInstall
> functionality today because "python setup.py install" isn't enough for
> PIL. You need to run configure
> and make too).
The specific problem this module is designed to fix is that the
MacPython community has grown accustomed to
MacPython coming with "batteries included", the distribution contains
popular packages like Numeric and img.
I don't want to do this anymore for MacPython-OSX. The intention is
that Pimp will make it so easy to install
selected extension packages that to the end user it is almost as good
as having the package included in
the distribution. Possibly even better, because you don't have to
download packages you don't want.
Because of the target audience I've made a couple of design decisions:
- Pimp shouldn't depend on a development environment, i.e. it should be
able to handle binary
packages (and these should be the default).
- If a package is listed and the end user tries to install it this
should work correctly 100% of
the time.
Especially the latter leads the design in a specific direction. First,
the database of packages (which
is loaded over the net) is specific to a (os-version, python-version)
combination and there's a maintainer
of the database who is considered responsible that everything in the
database actually works. Second,
MD5 checksums of the package archives are kept, so if package authors
change a package and the database
maintainer hasn't noticed (at which point s/he would presumably test
the new version of the package and update
the database) the end user is warned about the package being untested.
Pimp handles dependencies, and it can also handle dependencies to
things it can't install itself (i.e. all
packages that come as source depend on the Apple Developer Tools) in
which case the user is told
how to proceed if the dependency isn't available.
Unlike fink or inst or some such it doesn't keep a database of what it
installed, in stead it actively figures
this out on the fly. This may need to be changed when we want to do
uninstall, but the idea is that it should
remain as robust as possible, and not get upset if people install or
remove things behind its back.
From a first look at pypi I think pypi and pimp together could form a
winning team. I'll read up on pypi and
I'll join the catalog-sig to see whether the issues mentioned above are
handled in pypi, and/or think of how
they could be handled.
--
Jack Jansen, <Jack.Jansen@cwi.nl>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma
Goldman
From rjones@ekit-inc.com Wed Feb 19 00:36:55 2003
From: rjones@ekit-inc.com (Richard Jones)
Date: Wed, 19 Feb 2003 11:36:55 +1100
Subject: [Catalog-sig] PyPI now live on python.org
Message-ID: <200302191136.55609.rjones@ekit-inc.com>
I've just "switched on" the package index on python.org. The register command
in python2.3a2 (current CVS) uses this address by default now, and the
www.amk.ca script does a "half 301"* to tell users that the server has moved.
Thanks Andrew for your support!
The new address is http://www.python.org/pypi
There's still a couple of outstanding issues: the big one is the download url
handling. See http://www.python.org/sf/683939 for info on that. The verbosity
issue is known about and awaiting patching (http://www.python.org/sf/684398).
Neither are blockers as far as I'm concerned.
Richard
*"half 301" - for those who are curious, I respond with a Status: 301 and an
explanation of what's going on. I don't supply the Location: header because
the python urllib libraries will automatically follow it, and not supply the
basic auth credentials. The missing Location: results in the register command
just displaying the server response. The user is prompted to use the
different URL.
From fredrik@pythonware.com Wed Feb 19 11:02:21 2003
From: fredrik@pythonware.com (Fredrik Lundh)
Date: Wed, 19 Feb 2003 12:02:21 +0100
Subject: [Catalog-sig] Re: PyPI now live on python.org
References: <200302191136.55609.rjones@ekit-inc.com>
Message-ID: <b2vo7v$aoj$1@main.gmane.org>
Richard Jones wrote:
> I've just "switched on" the package index on python.org.
excellent!
one nit: the RSS feed seems to be broken; it seems to contain
HTML stuff mixed in with the RSS data:
http://www.python.org/pypi?:action=rss
here's what wget gives me:
<?xml version="1.0"?>
<!-- name="generator" content="PyPI/1.0" -->
<!DOCTYPE rss PUBLIC "-//Netscape Communications//DTD RSS 0.91//EN" "http://my.n
etscape.com/publish/formats/rss-0.91.dtd">
<rss version="0.91">
<channel>
<title>PyPI recent updates</title>
<link>http://www.python.org/pypi</link>
<description>Updates to the Python Packages Index (PyPI)</description>
<language>en</language>
Status: 500 Internal Server Error
Content-Type: text/html
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<?xml-stylesheet href="http://www.python.org/style.css" type="text/css"?>
<html><head><title>Python Packages Index</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="generator" content="HT2HTML/2.0">
<link rel="SHORTCUT ICON" href="http://www.python.org/pics/pyfav.gif">
<link rel="STYLESHEET" href="http://www.python.org/style.css" type="text/css">
<link rel="STYLESHEET" href="http://mechanicalcat.net/pypi.css" type="text/css">
</head>
<body bgcolor="#ffffff" text="#000000"
marginwidth="0" marginheight="0"
link="#0000bb" vlink="#551a8b"
alink="#ff0000">
...
I'm also having serious problems setting trove classifiers for my
contributions, but that's probably my fault.
</F>
From rjones@ekit-inc.com Wed Feb 19 20:50:32 2003
From: rjones@ekit-inc.com (Richard Jones)
Date: Thu, 20 Feb 2003 07:50:32 +1100
Subject: [Catalog-sig] Re: PyPI now live on python.org
In-Reply-To: <b2vo7v$aoj$1@main.gmane.org>
References: <200302191136.55609.rjones@ekit-inc.com> <b2vo7v$aoj$1@main.gmane.org>
Message-ID: <200302200750.32551.rjones@ekit-inc.com>
On Wed, 19 Feb 2003 10:02 pm, Fredrik Lundh wrote:
> Richard Jones wrote:
> > I've just "switched on" the package index on python.org.
>
> excellent!
>
> one nit: the RSS feed seems to be broken; it seems to contain
> HTML stuff mixed in with the RSS data:
>
> http://www.python.org/pypi?:action=rss
>
> here's what wget gives me:
>
> <?xml version="1.0"?>
> <!-- name="generator" content="PyPI/1.0" -->
> <!DOCTYPE rss PUBLIC "-//Netscape Communications//DTD RSS 0.91//EN"
> "http://my.n etscape.com/publish/formats/rss-0.91.dtd">
> <rss version="0.91">
> <channel>
> <title>PyPI recent updates</title>
> <link>http://www.python.org/pypi</link>
> <description>Updates to the Python Packages Index (PyPI)</description>
> <language>en</language>
> Status: 500 Internal Server Error
> Content-Type: text/html
>
>
> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
> <?xml-stylesheet href="http://www.python.org/style.css" type="text/css"?>
> <html><head><title>Python Packages Index</title>
> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
> <meta name="generator" content="HT2HTML/2.0">
> <link rel="SHORTCUT ICON" href="http://www.python.org/pics/pyfav.gif">
> <link rel="STYLESHEET" href="http://www.python.org/style.css"
> type="text/css"> <link rel="STYLESHEET"
> href="http://mechanicalcat.net/pypi.css" type="text/css"> </head>
> <body bgcolor="#ffffff" text="#000000"
> marginwidth="0" marginheight="0"
> link="#0000bb" vlink="#551a8b"
> alink="#ff0000">
Hurm - I can't reproduce this - if you get it again, could you submit the
entire response to the bug tracker on sf.net? The project is "pypi" and is
linked to from the pypi pages as "Bug Reports".
> I'm also having serious problems setting trove classifiers for my
> contributions, but that's probably my fault.
Please let me know if there's anything that can be done at my end to make this
work better for you.
Richard
From rjones@ekit-inc.com Wed Feb 19 21:00:15 2003
From: rjones@ekit-inc.com (Richard Jones)
Date: Thu, 20 Feb 2003 08:00:15 +1100
Subject: [Catalog-sig] Re: PyPI now live on python.org
In-Reply-To: <200302200750.32551.rjones@ekit-inc.com>
References: <200302191136.55609.rjones@ekit-inc.com> <b2vo7v$aoj$1@main.gmane.org> <200302200750.32551.rjones@ekit-inc.com>
Message-ID: <200302200800.15297.rjones@ekit-inc.com>
On Thu, 20 Feb 2003 7:50 am, Richard Jones wrote:
> Hurm - I can't reproduce this - if you get it again, could you submit the
> entire response to the bug tracker on sf.net? The project is "pypi" and is
> linked to from the pypi pages as "Bug Reports".
Arg, my apologies, I could reproduce this, I was just looking at the wrong
".N" download from wget. It's fixed now.
Richard
From theller@python.net Thu Feb 20 21:15:11 2003
From: theller@python.net (Thomas Heller)
Date: 20 Feb 2003 22:15:11 +0100
Subject: [Catalog-sig] Re: PyPI now live on python.org
In-Reply-To: <b2vo7v$aoj$1@main.gmane.org>
References: <200302191136.55609.rjones@ekit-inc.com>
<b2vo7v$aoj$1@main.gmane.org>
Message-ID: <k7fuvelc.fsf@python.net>
"Fredrik Lundh" <fredrik@pythonware.com> writes:
> Richard Jones wrote:
>
> > I've just "switched on" the package index on python.org.
>
> excellent!
>
> one nit: the RSS feed seems to be broken; it seems to contain
> HTML stuff mixed in with the RSS data:
>
Now that this is fixed, I'm having much fun reading the pypi channel with the
effnews reader. Thanks to both of you!
Thomas
From guido@python.org Fri Feb 21 14:06:39 2003
From: guido@python.org (Guido van Rossum)
Date: Fri, 21 Feb 2003 09:06:39 -0500
Subject: [Catalog-sig] catalog sig homepage
Message-ID: <200302211406.h1LE6dB30289@pcp02138704pcs.reston01.va.comcast.net>
The catalog sig's home page (http://www.python.org/sigs/catalog-sig/)
seems out of date: e.g. no mention of PEP 301 or PyPI. Could someone
update the page? (If you don't have write access to python.org but
still want to help, you can edit
http://www.python.org/sigs/catalog-sig/index.ht and mail the result to
pydotorg@python.org.)
--Guido van Rossum (home page: http://www.python.org/~guido/)
From akuchlin@mems-exchange.org Fri Feb 21 15:06:36 2003
From: akuchlin@mems-exchange.org (Andrew Kuchling)
Date: Fri, 21 Feb 2003 10:06:36 -0500
Subject: [Catalog-sig] Re: [Pydotorg] catalog sig homepage
In-Reply-To: <200302211406.h1LE6dB30289@pcp02138704pcs.reston01.va.comcast.net>
References: <200302211406.h1LE6dB30289@pcp02138704pcs.reston01.va.comcast.net>
Message-ID: <20030221150636.GC14667@ute.mems-exchange.org>
On Fri, Feb 21, 2003 at 09:06:39AM -0500, Guido van Rossum wrote:
>The catalog sig's home page (http://www.python.org/sigs/catalog-sig/)
>seems out of date: e.g. no mention of PEP 301 or PyPI. Could someone
I'm on it.
--amk
From rjones@ekit-inc.com Thu Feb 27 01:18:46 2003
From: rjones@ekit-inc.com (Richard Jones)
Date: Thu, 27 Feb 2003 12:18:46 +1100
Subject: [Catalog-sig] More documentation for setup meta-data
Message-ID: <200302271218.46287.rjones@ekit-inc.com>
I'm trying to better document the meta-data for the distutils (and hence
PyPI). I've added words to the section in the dev doc about meta-data, and
would like some feedback before I post the patch to be applied. Sorry, it's
in LaTeX form (until someone writes the ReST->python doc converter ;)
\subsection{Additional meta-data}
\label{meta-data}
The setup script may include additional meta-data beyond the name and
version. This information includes:
\begin{tableiii}{l|l|l|c}{code}%
{Meta-Data}{Description}{Value}{Notes}
\lineiii{name}{the name of the package}{short string}{(1)}
\lineiii{version}{the version of this release}{short string}{(1)(4)}
\lineiii{author}{package author's name}{short string}{(2)}
\lineiii{author_email}{email address of the package author}{email
address}{(2)}
\lineiii{maintainer}{package maintainer's name}{short string}{(2)}
\lineiii{maintainer_email}{email address of the package maintainer}{email
address}{(2)}
\lineiii{home_page}{the location of the homepage for the package}{URL}{(1)}
\lineiii{description}{a short, summary description of the package}{short
string}{}
\lineiii{long_description}{a longer description of the package}{long
string}{}
\lineiii{download_url}{a location where the package may be
downloaded}{URL}{(3)}
\lineiii{classifiers}{a list of Trove classifiers}{list of strings}{(3)}
\end{tableiii}
\noindent Notes:
\begin{description}
\item[(1)] these fields are required
\item[(2)] either the author or the maintainer must be nominated
\item[(3)] should not be used if your package is to be compatible with
Python versions prior to 2.2.3 or 2.3. The list is available from the
PyPI website.
\item[(4)] it is recommended that versions take the form
<major>.<minor>.<patch>[.<sub>]
\item["short string"] a single line of text, not more than 200 characters
\item["long string"] multiple lines of text
\item["list of strings"] see below
\end{description}
\option{version} encoding is an art in itself. Python packages generally
adhere to the version format \em{major.minor.patch}. The major number is
0 for initial, experimental releases of software. It is incremented for
releases that represent major milestones in a package. The minor number is
incremented when important new features are added to the package. The patch
number increments when bug-fix releases are made. Additional trailing
version information is sometimes used to indicate sub-releases.
These are "a1,a2,...,aN" (for alpha releases, where
functionality and API may change), "b1,b2,...,bN" (for beta releases, which
only fix bugs) and "pr1,pr2,...,prN" (for final pre-release release
testing). Some examples:
\begin{description}
\item[0.1.0] the first, experimental release of a package
\item[1.0.1a2] the second alpha release of the first patch version of 1.0
\end{description}
\option{classifiers} are specified in a python list:
\begin{verbatim}
setup(...
classifiers = [
'Development Status :: 4 - Beta',
'Environment :: Console',
'Environment :: Web Environment',
'Intended Audience :: End Users/Desktop',
'Intended Audience :: Developers',
'Intended Audience :: System Administrators',
'License :: OSI Approved :: Python Software Foundation License',
'Operating System :: MacOS :: MacOS X',
'Operating System :: Microsoft :: Windows',
'Operating System :: POSIX',
'Programming Language :: Python',
'Topic :: Communications :: Email',
'Topic :: Office/Business',
'Topic :: Software Development :: Bug Tracking',
],
...
)
\end{verbatim}
If you wish to include classifiers in your \file{setup.py} file and also
wish to remain backwards-compatible with Python releases prior to 2.2.3,
then you can include the following code fragment in your \file{setup.py}
before the \code{setup()} call.
\begin{verbatim}
# patch distutils if it can't cope with the "classifiers" or
# "download_url" keywords
if sys.version < '2.2.3':
from distutils.dist import DistributionMetadata
DistributionMetadata.classifiers = None
DistributionMetadata.download_url = None
\end{verbatim}
From stuart.b@commonground.com.au Thu Feb 27 02:51:46 2003
From: stuart.b@commonground.com.au (Stuart Bishop)
Date: Thu, 27 Feb 2003 13:51:46 +1100
Subject: [Catalog-sig] More documentation for setup meta-data
In-Reply-To: <200302271218.46287.rjones@ekit-inc.com>
Message-ID: <68E3A0DE-49FE-11D7-A92D-000393B63DDC@commonground.com.au>
On Thursday, February 27, 2003, at 12:18 PM, Richard Jones wrote:
> I'm trying to better document the meta-data for the distutils (and
> hence
> PyPI). I've added words to the section in the dev doc about meta-data,
> and
> would like some feedback before I post the patch to be applied. Sorry,
> it's
> in LaTeX form (until someone writes the ReST->python doc converter ;)
A patch was applied yesterday to dist.tex btw:
https://sourceforge.net/tracker/
?func=detail&atid=105470&aid=693474&group_id=5470
In particular, 'home_page' should be 'url'
I think a definition of 'short string' and 'long string' are required:
- Are Unicode strings allowed?
- What formatting is allowed (eg. none whatsoever for short string,
and ReST for long string)? I think either ReST or an HTML subset
is required for the long description. It would suck if long
description
ended up in a <pre> section on pypi, although this would be usable if
lines were shoved through textwrap.wrap()
It would be benefitial to mandate certain trove classifiers, to make
browsing
usable on pypi (at the moment, about 75% of projects are implemented in
no
language whatsoever!)
How about at least one of:
Development Status :: *
Environment :: *
Intended Audience :: *
License :: *
Operating System :: *
Programming Language :: *
Topic :: *
and possibly to complete the set of top level classifiers:
Natural Language :: * (does this mean the language the docstrings are
written
in, or programs dealing with language
processing?)
--
Stuart Bishop <zen@shangri-la.dropbear.id.au>
http://shangri-la.dropbear.id.au/
From stuart.b@commonground.com.au Thu Feb 27 03:45:58 2003
From: stuart.b@commonground.com.au (Stuart Bishop)
Date: Thu, 27 Feb 2003 14:45:58 +1100
Subject: [Catalog-sig] More documentation for setup meta-data
In-Reply-To: <200302271419.06949.rjones@ekit-inc.com>
Message-ID: <FB60EB1C-4A05-11D7-A92D-000393B63DDC@commonground.com.au>
On Thursday, February 27, 2003, at 02:19 PM, Richard Jones wrote:
> The current layout of the metadata on the release display page is ...
> well,
> it's a slightly refined version of a quick hack. It's the result of
> competing
> interests of getting something out there, and making it look pretty :)
I think it more important getting the docs right for the Python 2.3
release
and before the database gets too polluted. Making pypi render stuff
correctly
can be done whenever someone finds the time to deal with the bug report.
> Unicode hadn't occurred to me. Any thoughts? I don't believe sqlite
> can store
> unicode, but we could probably work around that...
If Unicode is supported, the trick would actually be to make sure that
distutils
and web forms submit the data in the correct encoding. I think adding
a <meta http-equiv="content-type" content="text/html; charset=utf-8" />
tag to the main template and making distutils do a foo.encode('utf8') on
Unicode strings would be all that is required (and sqllite wouldn't
know the
difference).
--
Stuart Bishop <zen@shangri-la.dropbear.id.au>
http://shangri-la.dropbear.id.au/
From rjones@ekit-inc.com Thu Feb 27 03:57:01 2003
From: rjones@ekit-inc.com (Richard Jones)
Date: Thu, 27 Feb 2003 14:57:01 +1100
Subject: [Catalog-sig] More documentation for setup meta-data
In-Reply-To: <FB60EB1C-4A05-11D7-A92D-000393B63DDC@commonground.com.au>
References: <FB60EB1C-4A05-11D7-A92D-000393B63DDC@commonground.com.au>
Message-ID: <200302271457.01068.rjones@ekit-inc.com>
On Thu, 27 Feb 2003 2:45 pm, Stuart Bishop wrote:
> If Unicode is supported, the trick would actually be to make sure that
> distutils
> and web forms submit the data in the correct encoding. I think adding
> a <meta http-equiv="content-type" content="text/html; charset=utf-8" />
> tag to the main template and making distutils do a foo.encode('utf8') on
> Unicode strings would be all that is required (and sqllite wouldn't
> know the
> difference).
As far as I can tell, unicode strings are coerced into ASCII when stored in
sqlite.
Richard
From rjones@ekit-inc.com Thu Feb 27 03:19:06 2003
From: rjones@ekit-inc.com (Richard Jones)
Date: Thu, 27 Feb 2003 14:19:06 +1100
Subject: [Catalog-sig] More documentation for setup meta-data
In-Reply-To: <68E3A0DE-49FE-11D7-A92D-000393B63DDC@commonground.com.au>
References: <68E3A0DE-49FE-11D7-A92D-000393B63DDC@commonground.com.au>
Message-ID: <200302271419.06949.rjones@ekit-inc.com>
On Thu, 27 Feb 2003 1:51 pm, Stuart Bishop wrote:
> On Thursday, February 27, 2003, at 12:18 PM, Richard Jones wrote:
> > I'm trying to better document the meta-data for the distutils (and
> > hence
> > PyPI). I've added words to the section in the dev doc about meta-data,
> > and
> > would like some feedback before I post the patch to be applied. Sorry,
> > it's
> > in LaTeX form (until someone writes the ReST->python doc converter ;)
>
> A patch was applied yesterday to dist.tex btw:
> https://sourceforge.net/tracker/
> ?func=detail&atid=105470&aid=693474&group_id=5470
Note that python.org has an auto-forwarder set up to make sf references
easier:
http://www.python.org/sf/<aid>
> In particular, 'home_page' should be 'url'
Huh. News to me :)
> I think a definition of 'short string' and 'long string' are required:
> - Are Unicode strings allowed?
> - What formatting is allowed (eg. none whatsoever for short string,
> and ReST for long string)? I think either ReST or an HTML subset
> is required for the long description. It would suck if long
> description
> ended up in a <pre> section on pypi, although this would be usable if
> lines were shoved through textwrap.wrap()
The current layout of the metadata on the release display page is ... well,
it's a slightly refined version of a quick hack. It's the result of competing
interests of getting something out there, and making it look pretty :)
Unicode hadn't occurred to me. Any thoughts? I don't believe sqlite can store
unicode, but we could probably work around that...
I think that ReST might be an option, but it's going to involve a bit of work
hooking the parser/formatter into PyPI. Regardless, most long-description
text will take to being ReST'ed just fine, since they're mostly all just
paras.
> It would be benefitial to mandate certain trove classifiers, to make
> browsing
> usable on pypi (at the moment, about 75% of projects are implemented in
> no
> language whatsoever!)
+1 (there should be at least one of each top-level group specified)
Note that in my modified documentation, the "platforms", "license" and
"keywords" distutils meta-data are removed. I suspect that "license" must
remain (to cope with oddities like the "Don't Bug Me Later License"). I don't
believe we should promote the other two though. I realise that there will
probably be disagreements about keywords ;)
> (does this mean the language the docstrings are
> written
> in, or programs dealing with language
> processing?)
It's been pointed out (after I went live) that "Native Language" makes more
sense. It's probably early enough days to make the change now. People who
have already set up classifiers in their setup files will be annoyed though
:(
Richard
From mal@lemburg.com Thu Feb 27 08:25:16 2003
From: mal@lemburg.com (M.-A. Lemburg)
Date: Thu, 27 Feb 2003 09:25:16 +0100
Subject: [Catalog-sig] Re: [Distutils] More documentation for setup meta-data
In-Reply-To: <200302271218.46287.rjones@ekit-inc.com>
References: <200302271218.46287.rjones@ekit-inc.com>
Message-ID: <3E5DCB6C.9030008@lemburg.com>
Richard Jones wrote:
> I'm trying to better document the meta-data for the distutils (and hence
> PyPI). I've added words to the section in the dev doc about meta-data, and
> would like some feedback before I post the patch to be applied. Sorry, it's
> in LaTeX form (until someone writes the ReST->python doc converter ;)
>
> \lineiii{download_url}{a location where the package may be
> downloaded}{URL}{(3)}
> \lineiii{classifiers}{a list of Trove classifiers}{list of strings}{(3)}
> \end{tableiii}
download_url is not a valid Distribution option (even though it
is listed in the DistributionMetaData). I wonder why you mention
it here.
The concept of a single URL for downloads seems to simplistic to
handle the issues involved with automatic installation. This
information should also be provided in a lazy way, so that the
package author can easily update the download links, e.g. by
placing the information in an XML file on his site and then
referencing this file in the distutils meta data.
The file should then be parsed by a distutils subcommand to
find the right download URL depending on the platform and
Python version.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Software directly from the Source (#1, Feb 27 2003)
>>> Python/Zope Products & Consulting ... http://www.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
Python UK 2003, Oxford: 33 days left
EuroPython 2003, Charleroi, Belgium: 117 days left
From lac@strakt.com Thu Feb 27 08:31:29 2003
From: lac@strakt.com (Laura Creighton)
Date: Thu, 27 Feb 2003 09:31:29 +0100
Subject: [Catalog-sig] Re: [Distutils] More documentation for setup meta-data
In-Reply-To: Message from "M.-A. Lemburg" <mal@lemburg.com>
of "Thu, 27 Feb 2003 09:25:16 +0100." <3E5DCB6C.9030008@lemburg.com>
References: <200302271218.46287.rjones@ekit-inc.com> <3E5DCB6C.9030008@lemburg.com>
Message-ID: <200302270831.h1R8VTjL028637@ratthing-b246.strakt.com>
>The concept of a single URL for downloads seems to simplistic to
>handle the issues involved with automatic installation. This
>information should also be provided in a lazy way, so that the
>package author can easily update the download links, e.g. by
>placing the information in an XML file on his site and then
>referencing this file in the distutils meta data.
>
>The file should then be parsed by a distutils subcommand to
>find the right download URL depending on the platform and
>Python version.
>
>--
>Marc-Andre Lemburg
>eGenix.com
>
Will this make it possible to list multiple places where one can find
software that is hosted more than one place? Seems desirable.
Laura Creighton
From mal@lemburg.com Thu Feb 27 10:00:56 2003
From: mal@lemburg.com (M.-A. Lemburg)
Date: Thu, 27 Feb 2003 11:00:56 +0100
Subject: [Catalog-sig] Re: [Distutils] More documentation for setup meta-data
In-Reply-To: <200302270831.h1R8VTjL028637@ratthing-b246.strakt.com>
References: <200302271218.46287.rjones@ekit-inc.com> <3E5DCB6C.9030008@lemburg.com> <200302270831.h1R8VTjL028637@ratthing-b246.strakt.com>
Message-ID: <3E5DE1D8.5040505@lemburg.com>
Laura Creighton wrote:
>>The concept of a single URL for downloads seems too simplistic to
>>handle the issues involved with automatic installation. This
>>information should also be provided in a lazy way, so that the
>>package author can easily update the download links, e.g. by
>>placing the information in an XML file on his site and then
>>referencing this file in the distutils meta data.
>>
>>The file should then be parsed by a distutils subcommand to
>>find the right download URL depending on the platform and
>>Python version.
>
> Will this make it possible to list multiple places where one can find
> software that is hosted more than one place? Seems desirable.
Right, that's the idea.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Software directly from the Source (#1, Feb 27 2003)
>>> Python/Zope Products & Consulting ... http://www.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
Python UK 2003, Oxford: 33 days left
EuroPython 2003, Charleroi, Belgium: 117 days left
From rjones@ekit-inc.com Thu Feb 27 21:51:51 2003
From: rjones@ekit-inc.com (Richard Jones)
Date: Fri, 28 Feb 2003 08:51:51 +1100
Subject: [Catalog-sig] Re: [Distutils] More documentation for setup meta-data
In-Reply-To: <3E5DCB6C.9030008@lemburg.com>
References: <200302271218.46287.rjones@ekit-inc.com> <3E5DCB6C.9030008@lemburg.com>
Message-ID: <200302280851.52571.rjones@ekit-inc.com>
On Thu, 27 Feb 2003 7:25 pm, M.-A. Lemburg wrote:
> Richard Jones wrote:
> > I'm trying to better document the meta-data for the distutils (and hence
> > PyPI). I've added words to the section in the dev doc about meta-data,
> > and would like some feedback before I post the patch to be applied.
> > Sorry, it's in LaTeX form (until someone writes the ReST->python doc
> > converter ;)
> >
> > \lineiii{download_url}{a location where the package may be
> > downloaded}{URL}{(3)}
> > \lineiii{classifiers}{a list of Trove classifiers}{list of
> > strings}{(3)} \end{tableiii}
>
> download_url is not a valid Distribution option (even though it
> is listed in the DistributionMetaData). I wonder why you mention
> it here.
It is new in 2.3
> The concept of a single URL for downloads seems to simplistic to
> handle the issues involved with automatic installation. This
> information should also be provided in a lazy way, so that the
> package author can easily update the download links, e.g. by
> placing the information in an XML file on his site and then
> referencing this file in the distutils meta data.
>
> The file should then be parsed by a distutils subcommand to
> find the right download URL depending on the platform and
> Python version.
This system sounds quite useful and flexible. It could also get very
complicated, very quickly (for a package maintainer). The download_url may
still be used for this purpose if it specifies a metadata file as the
download.
On the other hand, Anthony Baxter has written a distutils command that will
download a specified package and install it. This was recently posted to
distutils-sig "first cut at a distutils 'fetch' command". Sure, it's not an
optimal solution - in the same way that PyPI is going to need tweaking over
time once it's actually used. It's a start though.
Note that I would like to see an alternative system that is used to
disseminate packages which uses a set of mirrors similar to CPAN. There's an
accepted naming system so that the package may be found just using the
package name and version, and a fatch command that attempts to download the
package from one or more of the mirrors (depending on availability). PyPI
then supplies a list of the mirror sites. Distutils may also offer an upload
command, to make life even easier for the package maintainer. No need to
maintain download urls or even download sites. The kicker with this plan is
the provision of the bandwidth. The other elements of it are ... well,
trivial. They could be implemented before 2.3 is released.
Richard
From hpk@trillke.net Thu Feb 27 22:50:40 2003
From: hpk@trillke.net (holger krekel)
Date: Thu, 27 Feb 2003 23:50:40 +0100
Subject: [Catalog-sig] Re: [Distutils] More documentation for setup meta-data
In-Reply-To: <200302280851.52571.rjones@ekit-inc.com>; from rjones@ekit-inc.com on Fri, Feb 28, 2003 at 08:51:51AM +1100
References: <200302271218.46287.rjones@ekit-inc.com> <3E5DCB6C.9030008@lemburg.com> <200302280851.52571.rjones@ekit-inc.com>
Message-ID: <20030227235040.O11666@prim.han.de>
[Richard Jones Fri, Feb 28, 2003 at 08:51:51AM +1100]
> Note that I would like to see an alternative system that is used to
> disseminate packages which uses a set of mirrors similar to CPAN. There's an
> accepted naming system so that the package may be found just using the
> package name and version, and a fatch command that attempts to download the
> package from one or more of the mirrors (depending on availability). PyPI
> then supplies a list of the mirror sites. Distutils may also offer an upload
> command, to make life even easier for the package maintainer. No need to
> maintain download urls or even download sites. The kicker with this plan is
> the provision of the bandwidth. The other elements of it are ... well,
> trivial. They could be implemented before 2.3 is released.
Maybe asking c.l.py subscribers for servers (with bandwidth)
as mirrors for such a project would help. After all, python
distutils-packages are usually not that big. And many people
are longing for a way to upload/download packages semi-automatically.
holger
From mal@lemburg.com Fri Feb 28 16:22:04 2003
From: mal@lemburg.com (M.-A. Lemburg)
Date: Fri, 28 Feb 2003 17:22:04 +0100
Subject: [Catalog-sig] Re: [Distutils] More documentation for setup meta-data
In-Reply-To: <200302280851.52571.rjones@ekit-inc.com>
References: <200302271218.46287.rjones@ekit-inc.com> <3E5DCB6C.9030008@lemburg.com> <200302280851.52571.rjones@ekit-inc.com>
Message-ID: <3E5F8CAC.8010000@lemburg.com>
Richard Jones wrote:
> On Thu, 27 Feb 2003 7:25 pm, M.-A. Lemburg wrote:
>
>>Richard Jones wrote:
>>
>>>I'm trying to better document the meta-data for the distutils (and hence
>>>PyPI). I've added words to the section in the dev doc about meta-data,
>>>and would like some feedback before I post the patch to be applied.
>>>Sorry, it's in LaTeX form (until someone writes the ReST->python doc
>>>converter ;)
>>>
>>> \lineiii{download_url}{a location where the package may be
>>>downloaded}{URL}{(3)}
>>> \lineiii{classifiers}{a list of Trove classifiers}{list of
>>>strings}{(3)} \end{tableiii}
>>
>>download_url is not a valid Distribution option (even though it
>>is listed in the DistributionMetaData). I wonder why you mention
>>it here.
>
> It is new in 2.3
Uhm, it doesn't work in Python 2.3... that's why I was asking.
>>The concept of a single URL for downloads seems to simplistic to
>>handle the issues involved with automatic installation. This
>>information should also be provided in a lazy way, so that the
>>package author can easily update the download links, e.g. by
>>placing the information in an XML file on his site and then
>>referencing this file in the distutils meta data.
>>
>>The file should then be parsed by a distutils subcommand to
>>find the right download URL depending on the platform and
>>Python version.
>
> This system sounds quite useful and flexible. It could also get very
> complicated, very quickly (for a package maintainer). The download_url may
> still be used for this purpose if it specifies a metadata file as the
> download.
>
> On the other hand, Anthony Baxter has written a distutils command that will
> download a specified package and install it. This was recently posted to
> distutils-sig "first cut at a distutils 'fetch' command". Sure, it's not an
> optimal solution - in the same way that PyPI is going to need tweaking over
> time once it's actually used. It's a start though.
>
> Note that I would like to see an alternative system that is used to
> disseminate packages which uses a set of mirrors similar to CPAN. There's an
> accepted naming system so that the package may be found just using the
> package name and version, and a fatch command that attempts to download the
> package from one or more of the mirrors (depending on availability). PyPI
> then supplies a list of the mirror sites. Distutils may also offer an upload
> command, to make life even easier for the package maintainer. No need to
> maintain download urls or even download sites. The kicker with this plan is
> the provision of the bandwidth. The other elements of it are ... well,
> trivial. They could be implemented before 2.3 is released.
If you intend to use the download_url for this purpose, then
you ought to reserve it's usage for this now. Otherwise,
people will simply put a link to the download web-site
into this field.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Software directly from the Source (#1, Feb 28 2003)
>>> Python/Zope Products & Consulting ... http://www.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
Python UK 2003, Oxford: 32 days left
EuroPython 2003, Charleroi, Belgium: 116 days left