Mega-patch from the first day of the Cheese Shop sprinting.

* update to new pydotorg template (johannes)
* Bugger off search bots. (richard)
* "handle" strange charsets in PKG-INFO file uploads (richard)
* fix strange xml-rpc search() implementation (richard)
* add sidebar links in new template (richard)
* remove search, index and search_form actions. Index is useless now
  that Cheese Shop is so large. Search form has been replaced by a
  Google search. (johannes)
* remove random banner function, not necessary in the new design.
  (johannes)
* prevent date-field from wrapping around (bjorn stabell)
* better naming for xml-rpc functions (richard/andrew dalke)
* Add a radio button to switch between searching cheeseshop.python.org
  and python.org. (johannes)
* refactor query_info from returning text to template to returning a
  structure the template can work on (bjorn stabell)
* trim leading whitespace from rest docs (felix wiemann)
* move documentation into 'doc' directory (johannes)
* remove old flamenco implementation (johannes)

4 files changed, 633 insertions, 0 deletions

diff --git a/doc/dist.py.patch b/doc/dist.py.patch
new file mode 100644
index 0000000..19dec85
--- /dev/null
+++ b/doc/dist.py.patch
@@ -0,0 +1,75 @@
+*** dist.py	Wed Dec  4 15:41:53 2002
+--- dist.py-new	Wed Dec  4 15:41:32 2002
+***************
+*** 93,98 ****
+--- 93,100 ----
+           "print the long package description"),
+          ('platforms', None,
+           "print the list of platforms"),
++         ('classifiers', None,
++          "print the list of classifiers"),
+          ('keywords', None,
+           "print the list of keywords"),
+          ]
+***************
+*** 634,639 ****
+--- 636,643 ----
+                  value = getattr(self.metadata, "get_"+opt)()
+                  if opt in ['keywords', 'platforms']:
+                      print string.join(value, ',')
++                 elif opt == 'classifiers':
++                     print string.join(value, '\n')
+                  else:
+                      print value
+                  any_display_options = 1
+***************
+*** 962,968 ****
+                           "maintainer", "maintainer_email", "url",
+                           "license", "description", "long_description",
+                           "keywords", "platforms", "fullname", "contact",
+!                          "contact_email", "licence")
+  
+      def __init__ (self):
+          self.name = None
+--- 966,972 ----
+                           "maintainer", "maintainer_email", "url",
+                           "license", "description", "long_description",
+                           "keywords", "platforms", "fullname", "contact",
+!                          "contact_email", "licence", "classifiers")
+  
+      def __init__ (self):
+          self.name = None
+***************
+*** 977,982 ****
+--- 981,987 ----
+          self.long_description = None
+          self.keywords = None
+          self.platforms = None
++         self.classifiers = None
+  
+      def write_pkg_info (self, base_dir):
+          """Write the PKG-INFO file into the release tree.
+***************
+*** 1003,1008 ****
+--- 1008,1016 ----
+          for platform in self.get_platforms():
+              pkg_info.write('Platform: %s\n' % platform )
+  
++         for classifier in self.get_classifiers():
++             pkg_info.write('Classifier: %s\n' % classifier )
++ 
+          pkg_info.close()
+  
+      # write_pkg_info ()
+***************
+*** 1059,1064 ****
+--- 1067,1075 ----
+      def get_platforms(self):
+          return self.platforms or ["UNKNOWN"]
+  
++     def get_classifiers(self):
++         return self.classifiers or []
++ 
+  # class DistributionMetadata
+  
+  
diff --git a/doc/dist.tex.patch b/doc/dist.tex.patch
new file mode 100644
index 0000000..0b86a00
--- /dev/null
+++ b/doc/dist.tex.patch
@@ -0,0 +1,146 @@
+--- dist.tex	Thu Dec  5 07:29:20 2002
++++ dist.tex-new	Tue Dec 24 14:15:21 2002
+@@ -282,7 +282,8 @@
+ rather than by module.  This is important since the Distutils consist of
+ a couple of dozen modules split into (so far) two packages; an explicit
+ list of every module would be tedious to generate and difficult to
+-maintain.
++maintain. For more information on the additional meta-data, see
++section~\ref{meta-data}.
+ 
+ Note that any pathnames (files or directories) supplied in the setup
+ script should be written using the \UNIX{} convention, i.e.
+@@ -680,6 +681,75 @@
+ To install data files directly in the target directory, an empty
+ string should be given as the directory.
+ 
++  
++\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|c}{code}%
++  {Meta-Data}{Description}{Notes}
++  \lineiii{name}{the name of the package}{(1)}
++  \lineiii{version}{the version of this release}{(1)}
++  \lineiii{author}{package author's name}{(2)}
++  \lineiii{author_email}{email address of the package author}{(2)}
++  \lineiii{maintainer}{package maintainer's name}{(2)}
++  \lineiii{maintainer_email}{email address of the package maintainer}{(2)}
++  \lineiii{home_page}{a URL}{(1)}
++  \lineiii{license}{the terms the package is released under}{}
++  \lineiii{description}{a short, summary description of the package}{}
++  \lineiii{long_description}{a longer description of the package}{}
++  \lineiii{keywords}{some keywords appropriate to the package}{}
++  \lineiii{platform}{a list of the target platforms}{}
++  \lineiii{classifiers}{a list of Trove classifiers}{(2)}
++\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.
++\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" keyword
++if sys.version < '2.2.3':
++    from distutils.dist import DistributionMetadata
++    DistributionMetadata.classifiers = None
++\end{verbatim}
++
+ 
+ \section{Writing the Setup Configuration File}
+ \label{setup-config}
+@@ -1314,6 +1384,57 @@
+ The installer file will be written to the ``distribution directory''
+ --- normally \file{dist/}, but customizable with the
+ \longprogramopt{dist-dir} option.
++  
++\section{Registering with the Package Index}
++\label{package-index}
++
++The Python Package Index (PyPI) holds meta-data describing distributions
++packaged with distutils. The distutils command \command{register} is
++used to submit your distribution's meta-data to the index. It is invoked
++as follows:
++
++\begin{verbatim}
++python setup.py register
++\end{verbatim}
++
++Distutils will respond with the following prompt:
++
++\begin{verbatim}
++running register
++We need to know who you are, so please choose either:
++ 1. use your existing login,
++ 2. register as a new user,
++ 3. have the server generate a new password for you (and email it to you), or
++ 4. quit
++Your selection [default 1]:
++\end{verbatim}
++
++\noindent Note: if your username and password are saved locally, you will
++not see this menu.
++
++If you have not registered with PyPI, then you will need to do so now. You
++should choose option 2, and enter your details as required. Soon after
++submitting your details, you will receive an email which will be used to
++confirm your registration.
++
++Once you are registered, you may choose option 1 from the menu. You will
++be prompted for your PyPI username and password, and \command{register}
++will then submit your meta-data to the index.
++
++You may submit any number of versions of your distribution to the index. If
++you alter the meta-data for a particular version, you may submit it again
++and the index will be updated.
++
++PyPI holds a record for each (name, version) combination submitted. The
++first user to submit information for a given name is designated the Owner
++of that name. They may submit changes through the \command{register}
++command or through the web interface. They may also designate other users
++as Owners or Maintainers. Maintainers may edit the package information, but
++not designate other Owners or Maintainers.
++
++By default PyPI will list all versions of a given package. To hide certain
++versions, the Hidden property should be set to yes. This must be edited
++through the web interface.
+ 
+ 
+ \section{Examples}
diff --git a/doc/metadata-1.2-pep.txt b/doc/metadata-1.2-pep.txt
new file mode 100644
index 0000000..23d38f1
--- /dev/null
+++ b/doc/metadata-1.2-pep.txt
@@ -0,0 +1,391 @@
+THIS PEP HAS BEEN SUBMITTED.
+
+THE MASTER COPY OF THIS PEP IS NOW IN PYDOTORG CVS.
+
+DO NOT EDIT THIS VERSION OF THE PEP.
+
+
+PEP: 345
+Title: Medatadata for Python Software Packages 1.2
+Version: $Revision$
+Last-Modified: $Date$
+Author: Richard Jones, Anthony Baxter, Matthias Klose
+Discussions-To: Distutils SIG
+Status: Draft
+Type: Standards Track
+Created: 28-04-2005
+Python-Version: 2.5
+
+Abstract
+========
+
+This PEP describes a mechanism for adding metadata to Python
+packages.  It includes specifics of the field names, and their
+semantics and usage.
+
+This document specifies version 1.2 of the metadata format.
+Version 1.0 is specified in PEP 241.
+Version 1.1 is specified in PEP 314.
+
+Version 1.2 of the metadata format adds a number of optional 
+fields designed to make third-party packaging of Python Software
+easier. These fields are "Requires-Python" and "Requires-External".
+Also, the "Metadata-Version" field is updated.
+
+
+Fields
+======
+
+This section specifies the names and semantics of each of the
+supported metadata fields.
+ 
+Fields marked with "(Multiple use)" may be specified multiple
+times in a single PKG-INFO file.  Other fields may only occur
+once in a PKG-INFO file.  Fields marked with "(optional)" are
+not required to appear in a valid PKG-INFO file; all other
+fields must be present.
+
+XXX add in some note about charsets (Cheese Shop assumes UTF-8
+incoming data)
+
+Metadata-Version
+
+    Version of the file format; "1.0", "1.1" and "1.2" are the
+    only legal values here.
+
+      Example: 
+
+        Metadata-Version: 1.2
+
+Name
+
+    The name of the package.  
+
+      Example: 
+
+        Name: BeagleVote
+      
+Version
+
+    A string containing the package's version number.  This
+    field should be parseable by one of the Version classes
+    (StrictVersion or LooseVersion) in the distutils.version
+    module.
+
+    Example: 
+
+        Version: 1.0a2
+      
+Platform (multiple use)
+
+    A comma-separated list of platform specifications, summarizing
+    the operating systems supported by the package which are not
+    listed in the "Operating System" Trove classifiers. See
+    "Classifier" below.
+
+    Example: 
+
+        Platform: ObscureUnix, RareDOS
+
+Supported-Platform (multiple use)
+
+    Binary distributions containing a PKG-INFO file will use the
+    Supported-Platform field in their metadata to specify the OS and
+    CPU for which the binary package was compiled.  The semantics of
+    the Supported-Platform field are not specified in this PEP.
+
+    Example: 
+
+        Supported-Platform: RedHat 7.2
+        Supported-Platform: i386-win32-2791
+
+Summary
+
+    A one-line summary of what the package does.
+
+    Example: 
+
+        Summary: A module for collecting votes from beagles.
+    
+Description (optional)
+
+    A longer description of the package that can run to several
+    paragraphs.  Software that deals with metadata should not assume
+    any maximum size for this field, though people shouldn't include
+    their instruction manual as the description.  
+
+    The contents of this field can be written using reStructuredText
+    markup [1].  For programs that work with the metadata,
+    supporting markup is optional; programs can also display the
+    contents of the field as-is.  This means that authors should be
+    conservative in the markup they use.
+
+    Example: 
+    
+        Description: This module collects votes from beagles
+                    in order to determine their electoral wishes.
+                    Do *not* try to use this module with basset hounds;
+                    it makes them grumpy.
+    
+Keywords (optional)
+
+    A list of additional keywords to be used to assist searching
+    for the package in a larger catalog.
+
+    Example: 
+
+        Keywords: dog puppy voting election
+    
+Home-page (optional)
+
+    A string containing the URL for the package's home page.
+
+    Example: 
+
+        Home-page: http://www.example.com/~cschultz/bvote/
+    
+Download-URL
+
+    A string containing the URL from which this version of the package 
+    can be downloaded.  (This means that the URL can't be something like
+    ".../package-latest.tgz", but instead must be "../package-0.45.tgz".)
+    
+Author (optional)
+
+    A string containing the author's name at a minimum; additional
+    contact information may be provided.  
+
+    Example: 
+
+        Author: C. Schultz, Universal Features Syndicate,
+                Los Angeles, CA <cschultz@peanuts.example.com>
+    
+Author-email
+
+    A string containing the author's e-mail address.  It can contain
+    a name and e-mail address in the legal forms for a RFC-822
+    'From:' header.  It's not optional because cataloging systems
+    can use the e-mail portion of this field as a unique key
+    representing the author.  A catalog might provide authors the
+    ability to store their GPG key, personal home page, and other
+    additional metadata *about the author*, and optionally the
+    ability to associate several e-mail addresses with the same
+    person.  Author-related metadata fields are not covered by this
+    PEP.  
+
+    Example: 
+
+        Author-email: "C. Schultz" <cschultz@example.com>
+    
+License
+    
+    Text indicating the license covering the package where the license
+    is not a selection from the "License" Trove classifiers. See
+    "Classifier" below.
+
+    Example: 
+
+        License: This software may only be obtained by sending the
+                author a postcard, and then the user promises not
+                to redistribute it.
+
+Classifier (multiple use)
+
+    Each entry is a string giving a single classification value
+    for the package.  Classifiers are described in PEP 301 [2].
+
+    Examples:
+
+      Classifier: Development Status :: 4 - Beta
+      Classifier: Environment :: Console (Text Based)
+    
+Requires (multiple use)
+    
+    Each entry contains a string describing some other module or
+    package required by this package. 
+
+    The format of a requirement string is identical to that of a
+    module or package name usable with the 'import' statement,
+    optionally followed by a version declaration within parentheses.
+
+    A version declaration is a series of conditional operators and
+    version numbers, separated by commas.  Conditional operators
+    must be one of "<", ">", "<=", ">=", "==", and "!=".  Version
+    numbers must be in the format accepted by the
+    distutils.version.StrictVersion class: two or three
+    dot-separated numeric components, with an optional "pre-release"
+    tag on the end consisting of the letter 'a' or 'b' followed by a
+    number.  Example version numbers are "1.0", "2.3a2", "1.3.99", 
+
+    Any number of conditional operators can be specified, e.g.
+    the string ">1.0, !=1.3.4, <2.0" is a legal version declaration.
+
+    All of the following are possible requirement strings: "rfc822",
+    "zlib (>=1.1.4)", "zope".
+
+    There's no canonical list of what strings should be used; the
+    Python community is left to choose its own standards.
+
+    Example: 
+
+        Requires: re
+        Requires: sys
+        Requires: zlib
+        Requires: xml.parsers.expat (>1.0)
+        Requires: psycopg
+    
+Provides (multiple use)
+
+    Each entry contains a string describing a package or module that
+    will be provided by this package once it is installed.  These
+    strings should match the ones used in Requirements fields.  A
+    version declaration may be supplied (without a comparison
+    operator); the package's version number will be implied if none
+    is specified.
+
+    Example: 
+
+        Provides: xml
+        Provides: xml.utils
+        Provides: xml.utils.iso8601
+        Provides: xml.dom
+        Provides: xmltools (1.3)
+
+Obsoletes (multiple use)
+
+    Each entry contains a string describing a package or module
+    that this package renders obsolete, meaning that the two packages
+    should not be installed at the same time.  Version declarations
+    can be supplied.  
+
+    The most common use of this field will be in case a package name
+    changes, e.g. Gorgon 2.3 gets subsumed into Torqued Python 1.0.
+    When you install Torqued Python, the Gorgon package should be
+    removed.
+    
+    Example:
+
+        Obsoletes: Gorgon
+
+Requires-Python 
+
+    This field specifies the Python version(s) that the package is
+    guaranteed to be compatible with. The format of the field is a
+    series of conditional operators and version numbers, separated
+    by commas.  Conditional operators must be one of "<", ">", "<=",
+    ">=", "==", and "!=".  Version numbers must be in the format
+    accepted by the distutils.version.StrictVersion class: two or three
+    dot-separated numeric components, with an optional "pre-release"
+    tag on the end consisting of the letter 'a' or 'b' followed by a
+    number.  Example version numbers are "1.0", "2.3a2" and "1.3.99".
+
+    Any number of conditional operators can be specified, e.g.
+    the string ">1.0, !=1.3.4, <2.0" is a legal version declaration.
+
+    Example:
+
+      Requires-Python: >2.1
+      Requires-Python: >=2.3.4
+
+    XXX This field doesn't take into account possible future
+    incompatibilities through deprecation. We could specify that the ">"
+    operator only work for up to two releases? This is based on the typical
+    deprecation plan that Python usually follows (warning for two releases
+    and then error). That is, >=2.3.4 works for 2.3.4, 2.4 and 2.5.
+
+Requires-External (multiple use)
+      
+    Each entry contains a string describing some dependency in the
+    system that the package is to be used.
+
+    The format of a requirement string is a name of an external
+    dependency, optionally followed by a version declaration within
+    parentheses.
+
+    A version declaration is a series of conditional operators and
+    version numbers, separated by commas.  Conditional operators
+    must be one of "<", ">", "<=", ">=", "==", and "!=".  Version
+    numbers must be in the format accepted by the
+    distutils.version.StrictVersion class: two or three
+    dot-separated numeric components, with an optional "pre-release"
+    tag on the end consisting of the letter 'a' or 'b' followed by a
+    number.  Example version numbers are "1.0", "2.3a2", "1.3.99", 
+
+    Any number of conditional operators can be specified, e.g.
+    the string ">1.0, !=1.3.4, <2.0" is a legal version declaration.
+
+    The canonical list of what strings are allowed is available
+    in the `Cheese Shop`_ database. New names may be added to the
+    database either through the web or using the command-line;
+    Python community is left to choose its own standards.
+
+    Some dependencies are anticipated to be quite broad, eg. "C",
+    indicating a C compiler is required.
+
+    Example: 
+
+      Requires: C
+      Requires: libpng
+
+
+Copyright
+
+    Indicates the party or parties, and the year of copyright
+    covering the package.
+
+    XXX should be default the copyright to the author and date of
+    metadata submission?
+
+    Example:
+
+       Copyright: Guido van Rossum, 1991
+       Copyright: Python Software Foundation, 2005
+       Copyright: Public Domain
+
+
+External References Registry
+============================
+
+Stores in the Cheese Shop database a list of (name, description, URI)
+identifying an external reference that may be used as a value in a
+Requires-External field.
+
+The name and description are required, but URI is not (as there is no
+single useful URI for "C").
+
+Submissions to the registry are open to the community, and may be performed
+through the web or using the command-line.
+
+The names in the registry will be created under a first-comes first-wins
+basis. Other packagers of Python software (eg. to deb, rpm, etc) should be
+able to translate the requires-external field to names in their own
+packaging system.
+
+XXX command-line interface needs work, obviously
+
+
+References
+==========
+
+This document specifies version 1.2 of the metadata format.
+Version 1.0 is specified in PEP 241.
+Version 1.1 is specified in PEP 314.
+
+.. _`Cheese Shop`: http://cheeseshop.python.org/
+
+
+Copyright
+=========
+
+This document has been placed in the public domain.
+
+
+
+..
+   Local Variables:
+   mode: indented-text
+   indent-tabs-mode: nil
+   sentence-end-double-space: t
+   fill-column: 70
+   End:
+
diff --git a/doc/operational_manual.txt b/doc/operational_manual.txt
new file mode 100644
index 0000000..dc9c275
--- /dev/null
+++ b/doc/operational_manual.txt
@@ -0,0 +1,21 @@
+This document is intended for administrators of the python.org host, and
+contains information about operationally maintaining the PyPI system.
+
+
+Maintenance
+-----------
+
+The cgi-bin script "pypi.cgi" has a section which should be enabled that
+informs the user that the cgi interface is down for maintenance. This is a
+simple case of changing the "if 0:" to "if 1:" above the "503" response
+line.
+
+
+Administrative tasks
+--------------------
+
+The "admin.py" script will perform several admin tasks (constantly growing
+as the need arises):
+
+   password <username> <password>
+   rmpackage <package name>