[Zope3-dev] Mail delivery failed: returning message to sender

[Mail Delivery System]

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  corey at streamreel.net
    SMTP error from remote mailer after RCPT TO:<corey at streamreel.net>:
    host iris2.directnic.com [204.251.10.82]: 550 5.7.1 No such recipient

------ This is a copy of the message, including all the headers. ------

Return-path: <zope3-dev at zope.org>
Received: from cache1.zope.org ([12.155.117.38])
	by mail.python.org with esmtp (Exim 4.22)
	id 1AsO85-00082u-7C; Sun, 15 Feb 2004 10:24:21 -0500
From: zope3-dev at zope.org (jim)
Reply-To: zope3-dev at zope.org
To: ;
Subject: [Zope 3 Packaging Proposal] (new) 
Message-ID: <20040215102421EST at dev.zope.org>
X-BeenThere: zope3-dev at zope.org
X-Zwiki-Version: 0.21.1
Precedence: bulk
List-Id:  <zope3-dev at zope.org>
List-Post: <mailto:zope3-dev at zope.org>
List-Subscribe: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/Zope3PackagingProposal/subscribeform>
List-Unsubscribe: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/Zope3PackagingProposal/subscribeform>
List-Archive: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/Zope3PackagingProposal>
List-Help: <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture>
Date: Sun, 15 Feb 2004 10:24:21 -0500
X-Spam-Status: OK (default 0.000)

Packaging of Zope 3 file-system-based software

  Status: IsPreProposal

  Author
 
    JimFulton

  Problem 

    An important feature of Zope 3 is that it provides a highly
    flexable and modular architecture for creating applications.  It
    is hoped that Zope components will be arranged in a variety of
    ways to meet various application needs. (Certainly, at least one
    configuration will be an web application server recognizable as
    Zope. :)

    To support this flexability, we'd like to provide a fine-grained
    packaging system that supports:

    - Easy creation of software distributions to meet a variety of
      needs. For example, we'd like to make it easy to support both
      stable and development Zope distributions.  The Zope X3.0.0
      distribution will include only features that are either very
      stable or needed for file-system-based development.  There are
      many other components in the Zope 3 repository that would be
      useful to people willing to work with still-under-development
      software.  We'd like to be able to easily generate alternative
      "development" distributions with these components.

    - Flexible update and maintenance of distribution components

    This document, which will eventually become a proposal, proposes
    some goals for selection and or design of a packaging system for
    Zope.

    Goals (and assumptions)

      - Support fine-grained software distribution packaging.

        Software distribution packages will often correspond directly
        to Python packages that are rather small. For example, a small
        software distribution package might include a single Python
        package with only a few source files.

        Note that supporting fine-grained distribution packages
        requires a packaging system that supports (requires) and
        leverages information about package dependencies.

      - Work with distutils.  We don't want to reinvent the wheel.
        OTOH, we may have to work with the rest of the Python
        community to improve the wheel we have to provide or support
        package management. The most imporatnt need being dependency
        management.  See PEP 262.

        We should strive to have needed distutils improvements ready
        for inclusion in Python 2.4.    

      - Work with existing platform packaging systems, most notably,
        RPM, Debian packages, and Fink.

      - Support platforms without their own packaging systems, most
        notably windows.

      - Support easy creation of various Zope distributions. These
        distributions will allow simple installation of a collection
        of packages easily without use of a package system by end
        users. 

      - Liberate the Zope repository from having to reflect
        distribution or packages status (e.g. core or not core.)

      - It should remain possible to check out the Zope 3 CVS module, 
        execute a simple build command and run Zope in place.  It
        should be easy to modify software, run tests and Zope and
        check in changes without having to resort to separate
        "install" steps after each change.

      - Provide a simpler repository layout to make Zope 3 software
        easier to understand and navigate.

      - Provide greater visability to software dependencies

    Non Goal

      - An important non-goal is Zope instance creation.  The software
        packaging mechanism will be responsible for installing
        software. It will generally not be responsible for setting up
        Zope instances. Rather, among the software installed will be
        software for creating Zope instances. 

    Jargon problems

      We use the term "package" to refer *both* to Python packages and
      to units of software distribution.  There will often, but not
      always be a one-to-one correspondence between software
      distribution packages and Python packages.   Distutils attempts
      to solve this by refering to software distributions as "module
      distributions". I (Jim) find this rather unsatisfying.  This is
      an issue that will, ultimately, need to be resolved by the
      Python community. We will follow thier lead.

    Possible vision

      - Work with the Python community at large to extend distutils
        to manage information necessary for packaging and create a
        simple package-management system for python.

      - From the above system, provide utilities for automatically
        generating platform (RPM, Debian, etc.) packages.

      - Create a system for generating distributions from packages.
        For example, a source distribution might be defined by
        specifying a root pacakge and satisfying it's deoendency. A
        source distribution might then be simply a collection of
        gathered source packages and glue utilities (obviously based
        on distutils) that build and install the collected packages.

        Note that source and binary distributions may not look
        anything like the CVS repository.

    Distutils issues

      We are aware of a number of issues using distutils to package
      Zope software. These are collected here so we can seek to
      address them in this project:

      - Lack of dependency data needed to support a packaging
        system. See PEP 262.

      - No support for package data files.  Zope makes extensive use
        of Python packages to include files in addition to Python
        modules, including:

        o Source files for other languages (e.g. ZPT and DTML)

        o Configuration files

        o Images

        Distutils has minimal support for installing data files, but
        has no notion of data files that are in and that should be
        installed with packages.

      - Issues with generating (or generated) platforn packages
        (e.g. RPMs).

        This space for Tres to fill in. :)

  Proposal

    Note yet

--
forwarded from http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/Zope3PackagingProposal