diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/_templates/indexsidebar.html | 8 | ||||
| -rw-r--r-- | docs/conf.py | 20 | ||||
| -rw-r--r-- | docs/easy_install.txt | 20 | ||||
| -rw-r--r-- | docs/formats.txt | 696 | ||||
| -rw-r--r-- | docs/index.txt | 33 | ||||
| -rw-r--r-- | docs/merge-faq.txt | 80 | ||||
| -rw-r--r-- | docs/merge.txt | 122 | ||||
| -rw-r--r-- | docs/python3.txt | 31 | ||||
| -rw-r--r-- | docs/roadmap.txt | 88 | ||||
| -rw-r--r-- | docs/setuptools.txt | 12 | ||||
| -rw-r--r-- | docs/using.txt | 19 |
11 files changed, 969 insertions, 160 deletions
diff --git a/docs/_templates/indexsidebar.html b/docs/_templates/indexsidebar.html index 932909f3..a27c85fe 100644 --- a/docs/_templates/indexsidebar.html +++ b/docs/_templates/indexsidebar.html @@ -1,8 +1,8 @@ -<h3>Download</h3> +<h3>Download</h3> -<p>Current version: <b>{{ version }}</b></p> -<p>Get Distribute from the <a href="http://pypi.python.org/pypi/distribute"> Python Package Index</a> +<p>Current version: <b>{{ version }}</b></p> +<p>Get Setuptools from the <a href="https://pypi.python.org/pypi/setuptools"> Python Package Index</a> <h3>Questions? Suggestions? Contributions?</h3> -<p>Visit the <a href="http://bitbucket.org/tarek/distribute">Distribute project page</a> </p> +<p>Visit the <a href="https://bitbucket.org/pypa/setuptools">Setuptools project page</a> </p> diff --git a/docs/conf.py b/docs/conf.py index 4146dcaa..3fccd87f 100644 --- a/docs/conf.py +++ b/docs/conf.py @@ -1,6 +1,6 @@ # -*- coding: utf-8 -*- # -# Distribute documentation build configuration file, created by +# Setuptools documentation build configuration file, created by # sphinx-quickstart on Fri Jul 17 14:22:37 2009. # # This file is execfile()d with the current directory set to its containing dir. @@ -40,17 +40,17 @@ source_suffix = '.txt' master_doc = 'index' # General information about the project. -project = u'Distribute' -copyright = u'2009-2011, The fellowship of the packaging' +project = 'Setuptools' +copyright = '2009-2013, The fellowship of the packaging' # The version info for the project you're documenting, acts as replacement for # |version| and |release|, also used in various other places throughout the # built documents. # # The short X.Y version. -version = '0.6.49' +version = '0.8' # The full version, including alpha/beta/rc tags. -release = '0.6.49' +release = '0.8' # The language for content autogenerated by Sphinx. Refer to documentation # for a list of supported languages. @@ -106,10 +106,10 @@ html_theme_path = ['_theme'] # The name for this set of Sphinx documents. If None, it defaults to # "<project> v<release> documentation". -html_title = "Distribute documentation" +html_title = "Setuptools documentation" # A shorter title for the navigation bar. Default is the same as html_title. -html_short_title = "Distribute" +html_short_title = "Setuptools" # The name of an image file (relative to this directory) to place at the top # of the sidebar. @@ -161,7 +161,7 @@ html_use_index = False #html_file_suffix = '' # Output file base name for HTML help builder. -htmlhelp_basename = 'Distributedoc' +htmlhelp_basename = 'Setuptoolsdoc' # -- Options for LaTeX output -------------------------------------------------- @@ -175,8 +175,8 @@ htmlhelp_basename = 'Distributedoc' # Grouping the document tree into LaTeX files. List of tuples # (source start file, target name, title, author, documentclass [howto/manual]). latex_documents = [ - ('index', 'Distribute.tex', ur'Distribute Documentation', - ur'The fellowship of the packaging', 'manual'), + ('index', 'Setuptools.tex', 'Setuptools Documentation', + 'The fellowship of the packaging', 'manual'), ] # The name of an image file (relative to this directory) to place at the top of diff --git a/docs/easy_install.txt b/docs/easy_install.txt index 9b4fcfbb..12bc73ea 100644 --- a/docs/easy_install.txt +++ b/docs/easy_install.txt @@ -31,7 +31,7 @@ Using "Easy Install" Installing "Easy Install" ------------------------- -Please see the `setuptools PyPI page <http://pypi.python.org/pypi/setuptools>`_ +Please see the `setuptools PyPI page <https://pypi.python.org/pypi/setuptools>`_ for download links and basic installation instructions for each of the supported platforms. @@ -94,7 +94,7 @@ directory, you can also retarget the installation location for scripts so they go on a directory that's already on the ``PATH``. For more information see the sections below on `Command-Line Options`_ and `Configuration Files`_. You can pass command line options (such as ``--script-dir``) to -``distribute_setup.py`` to control where ``easy_install.exe`` will be installed. +``ez_setup.py`` to control where ``easy_install.exe`` will be installed. @@ -776,10 +776,12 @@ Command-Line Options package not being available locally, or due to the use of the ``--update`` or ``-U`` option. -``--no-find-links`` Blocks the addition of any link. (New in Distribute 0.6.11) - This is useful if you want to avoid adding links defined in a project - easy_install is installing (wether it's a requested project or a - dependency.). When used, ``--find-links`` is ignored. +``--no-find-links`` Blocks the addition of any link. + This parameter is useful if you want to avoid adding links defined in a + project easy_install is installing (whether it's a requested project or a + dependency). When used, ``--find-links`` is ignored. + + Added in Distribute 0.6.11 and Setuptools 0.7. ``--delete-conflicting, -D`` (Removed in 0.6a11) (As of 0.6a11, this option is no longer necessary; please do not use it!) @@ -804,7 +806,7 @@ Command-Line Options ``--index-url=URL, -i URL`` (New in 0.4a1; default changed in 0.6c7) Specifies the base URL of the Python Package Index. The default is - http://pypi.python.org/simple if not specified. When a package is requested + https://pypi.python.org/simple if not specified. When a package is requested that is not locally available or linked from a ``--find-links`` download page, the package index will be searched for download pages for the needed package, and those download pages will be searched for links to download @@ -993,7 +995,7 @@ that the User installation scheme alone does not provide, e.g. the ability to hi Please refer to the `virtualenv`_ documentation for more details. -.. _virtualenv: http://pypi.python.org/pypi/virtualenv +.. _virtualenv: https://pypi.python.org/pypi/virtualenv @@ -1126,7 +1128,7 @@ History 0.6c7 * ``ftp:`` download URLs now work correctly. - * The default ``--index-url`` is now ``http://pypi.python.org/simple``, to use + * The default ``--index-url`` is now ``https://pypi.python.org/simple``, to use the Python Package Index's new simpler (and faster!) REST API. 0.6c6 diff --git a/docs/formats.txt b/docs/formats.txt new file mode 100644 index 00000000..dbfc2812 --- /dev/null +++ b/docs/formats.txt @@ -0,0 +1,696 @@ +===================================== +The Internal Structure of Python Eggs +===================================== + +STOP! This is not the first document you should read! + +This document assumes you have at least some passing familiarity with +*using* setuptools, the ``pkg_resources`` module, and EasyInstall. It +does not attempt to explain basic concepts like inter-project +dependencies, nor does it contain detailed lexical syntax for most +file formats. Neither does it explain concepts like "namespace +packages" or "resources" in any detail, as all of these subjects are +covered at length in the setuptools developer's guide and the +``pkg_resources`` reference manual. + +Instead, this is **internal** documentation for how those concepts and +features are *implemented* in concrete terms. It is intended for people +who are working on the setuptools code base, who want to be able to +troubleshoot setuptools problems, want to write code that reads the file +formats involved, or want to otherwise tinker with setuptools-generated +files and directories. + +Note, however, that these are all internal implementation details and +are therefore subject to change; stick to the published API if you don't +want to be responsible for keeping your code from breaking when +setuptools changes. You have been warned. + + +.. contents:: **Table of Contents** + + +---------------------- +Eggs and their Formats +---------------------- + +A "Python egg" is a logical structure embodying the release of a +specific version of a Python project, comprising its code, resources, +and metadata. There are multiple formats that can be used to physically +encode a Python egg, and others can be developed. However, a key +principle of Python eggs is that they should be discoverable and +importable. That is, it should be possible for a Python application to +easily and efficiently find out what eggs are present on a system, and +to ensure that the desired eggs' contents are importable. + +There are two basic formats currently implemented for Python eggs: + +1. ``.egg`` format: a directory or zipfile *containing* the project's + code and resources, along with an ``EGG-INFO`` subdirectory that + contains the project's metadata + +2. ``.egg-info`` format: a file or directory placed *adjacent* to the + project's code and resources, that directly contains the project's + metadata. + +Both formats can include arbitrary Python code and resources, including +static data files, package and non-package directories, Python +modules, C extension modules, and so on. But each format is optimized +for different purposes. + +The ``.egg`` format is well-suited to distribution and the easy +uninstallation or upgrades of code, since the project is essentially +self-contained within a single directory or file, unmingled with any +other projects' code or resources. It also makes it possible to have +multiple versions of a project simultaneously installed, such that +individual programs can select the versions they wish to use. + +The ``.egg-info`` format, on the other hand, was created to support +backward-compatibility, performance, and ease of installation for system +packaging tools that expect to install all projects' code and resources +to a single directory (e.g. ``site-packages``). Placing the metadata +in that same directory simplifies the installation process, since it +isn't necessary to create ``.pth`` files or otherwise modify +``sys.path`` to include each installed egg. + +Its disadvantage, however, is that it provides no support for clean +uninstallation or upgrades, and of course only a single version of a +project can be installed to a given directory. Thus, support from a +package management tool is required. (This is why setuptools' "install" +command refers to this type of egg installation as "single-version, +externally managed".) Also, they lack sufficient data to allow them to +be copied from their installation source. easy_install can "ship" an +application by copying ``.egg`` files or directories to a target +location, but it cannot do this for ``.egg-info`` installs, because +there is no way to tell what code and resources belong to a particular +egg -- there may be several eggs "scrambled" together in a single +installation location, and the ``.egg-info`` format does not currently +include a way to list the files that were installed. (This may change +in a future version.) + + +Code and Resources +================== + +The layout of the code and resources is dictated by Python's normal +import layout, relative to the egg's "base location". + +For the ``.egg`` format, the base location is the ``.egg`` itself. That +is, adding the ``.egg`` filename or directory name to ``sys.path`` +makes its contents importable. + +For the ``.egg-info`` format, however, the base location is the +directory that *contains* the ``.egg-info``, and thus it is the +directory that must be added to ``sys.path`` to make the egg importable. +(Note that this means that the "normal" installation of a package to a +``sys.path`` directory is sufficient to make it an "egg" if it has an +``.egg-info`` file or directory installed alongside of it.) + + +Project Metadata +================= + +If eggs contained only code and resources, there would of course be +no difference between them and any other directory or zip file on +``sys.path``. Thus, metadata must also be included, using a metadata +file or directory. + +For the ``.egg`` format, the metadata is placed in an ``EGG-INFO`` +subdirectory, directly within the ``.egg`` file or directory. For the +``.egg-info`` format, metadata is stored directly within the +``.egg-info`` directory itself. + +The minimum project metadata that all eggs must have is a standard +Python ``PKG-INFO`` file, named ``PKG-INFO`` and placed within the +metadata directory appropriate to the format. Because it's possible for +this to be the only metadata file included, ``.egg-info`` format eggs +are not required to be a directory; they can just be a ``.egg-info`` +file that directly contains the ``PKG-INFO`` metadata. This eliminates +the need to create a directory just to store one file. This option is +*not* available for ``.egg`` formats, since setuptools always includes +other metadata. (In fact, setuptools itself never generates +``.egg-info`` files, either; the support for using files was added so +that the requirement could easily be satisfied by other tools, such +as the distutils in Python 2.5). + +In addition to the ``PKG-INFO`` file, an egg's metadata directory may +also include files and directories representing various forms of +optional standard metadata (see the section on `Standard Metadata`_, +below) or user-defined metadata required by the project. For example, +some projects may define a metadata format to describe their application +plugins, and metadata in this format would then be included by plugin +creators in their projects' metadata directories. + + +Filename-Embedded Metadata +========================== + +To allow introspection of installed projects and runtime resolution of +inter-project dependencies, a certain amount of information is embedded +in egg filenames. At a minimum, this includes the project name, and +ideally will also include the project version number. Optionally, it +can also include the target Python version and required runtime +platform if platform-specific C code is included. The syntax of an +egg filename is as follows:: + + name ["-" version ["-py" pyver ["-" required_platform]]] "." ext + +The "name" and "version" should be escaped using the ``to_filename()`` +function provided by ``pkg_resources``, after first processing them with +``safe_name()`` and ``safe_version()`` respectively. These latter two +functions can also be used to later "unescape" these parts of the +filename. (For a detailed description of these transformations, please +see the "Parsing Utilities" section of the ``pkg_resources`` manual.) + +The "pyver" string is the Python major version, as found in the first +3 characters of ``sys.version``. "required_platform" is essentially +a distutils ``get_platform()`` string, but with enhancements to properly +distinguish Mac OS versions. (See the ``get_build_platform()`` +documentation in the "Platform Utilities" section of the +``pkg_resources`` manual for more details.) + +Finally, the "ext" is either ``.egg`` or ``.egg-info``, as appropriate +for the egg's format. + +Normally, an egg's filename should include at least the project name and +version, as this allows the runtime system to find desired project +versions without having to read the egg's PKG-INFO to determine its +version number. + +Setuptools, however, only includes the version number in the filename +when an ``.egg`` file is built using the ``bdist_egg`` command, or when +an ``.egg-info`` directory is being installed by the +``install_egg_info`` command. When generating metadata for use with the +original source tree, it only includes the project name, so that the +directory will not have to be renamed each time the project's version +changes. + +This is especially important when version numbers change frequently, and +the source metadata directory is kept under version control with the +rest of the project. (As would be the case when the project's source +includes project-defined metadata that is not generated from by +setuptools from data in the setup script.) + + +Egg Links +========= + +In addition to the ``.egg`` and ``.egg-info`` formats, there is a third +egg-related extension that you may encounter on occasion: ``.egg-link`` +files. + +These files are not eggs, strictly speaking. They simply provide a way +to reference an egg that is not physically installed in the desired +location. They exist primarily as a cross-platform alternative to +symbolic links, to support "installing" code that is being developed in +a different location than the desired installation location. For +example, if a user is developing an application plugin in their home +directory, but the plugin needs to be "installed" in an application +plugin directory, running "setup.py develop -md /path/to/app/plugins" +will install an ``.egg-link`` file in ``/path/to/app/plugins``, that +tells the egg runtime system where to find the actual egg (the user's +project source directory and its ``.egg-info`` subdirectory). + +``.egg-link`` files are named following the format for ``.egg`` and +``.egg-info`` names, but only the project name is included; no version, +Python version, or platform information is included. When the runtime +searches for available eggs, ``.egg-link`` files are opened and the +actual egg file/directory name is read from them. + +Each ``.egg-link`` file should contain a single file or directory name, +with no newlines. This filename should be the base location of one or +more eggs. That is, the name must either end in ``.egg``, or else it +should be the parent directory of one or more ``.egg-info`` format eggs. + +As of setuptools 0.6c6, the path may be specified as a platform-independent +(i.e. ``/``-separated) relative path from the directory containing the +``.egg-link`` file, and a second line may appear in the file, specifying a +platform-independent relative path from the egg's base directory to its +setup script directory. This allows installation tools such as EasyInstall +to find the project's setup directory and build eggs or perform other setup +commands on it. + + +----------------- +Standard Metadata +----------------- + +In addition to the minimum required ``PKG-INFO`` metadata, projects can +include a variety of standard metadata files or directories, as +described below. Except as otherwise noted, these files and directories +are automatically generated by setuptools, based on information supplied +in the setup script or through analysis of the project's code and +resources. + +Most of these files and directories are generated via "egg-info +writers" during execution of the setuptools ``egg_info`` command, and +are listed in the ``egg_info.writers`` entry point group defined by +setuptools' own ``setup.py`` file. + +Project authors can register their own metadata writers as entry points +in this group (as described in the setuptools manual under "Adding new +EGG-INFO Files") to cause setuptools to generate project-specific +metadata files or directories during execution of the ``egg_info`` +command. It is up to project authors to document these new metadata +formats, if they create any. + + +``.txt`` File Formats +===================== + +Files described in this section that have ``.txt`` extensions have a +simple lexical format consisting of a sequence of text lines, each line +terminated by a linefeed character (regardless of platform). Leading +and trailing whitespace on each line is ignored, as are blank lines and +lines whose first nonblank character is a ``#`` (comment symbol). (This +is the parsing format defined by the ``yield_lines()`` function of +the ``pkg_resources`` module.) + +All ``.txt`` files defined by this section follow this format, but some +are also "sectioned" files, meaning that their contents are divided into +sections, using square-bracketed section headers akin to Windows +``.ini`` format. Note that this does *not* imply that the lines within +the sections follow an ``.ini`` format, however. Please see an +individual metadata file's documentation for a description of what the +lines and section names mean in that particular file. + +Sectioned files can be parsed using the ``split_sections()`` function; +see the "Parsing Utilities" section of the ``pkg_resources`` manual for +for details. + + +Dependency Metadata +=================== + + +``requires.txt`` +---------------- + +This is a "sectioned" text file. Each section is a sequence of +"requirements", as parsed by the ``parse_requirements()`` function; +please see the ``pkg_resources`` manual for the complete requirement +parsing syntax. + +The first, unnamed section (i.e., before the first section header) in +this file is the project's core requirements, which must be installed +for the project to function. (Specified using the ``install_requires`` +keyword to ``setup()``). + +The remaining (named) sections describe the project's "extra" +requirements, as specified using the ``extras_require`` keyword to +``setup()``. The section name is the name of the optional feature, and +the section body lists that feature's dependencies. + +Note that it is not normally necessary to inspect this file directly; +``pkg_resources.Distribution`` objects have a ``requires()`` method +that can be used to obtain ``Requirement`` objects describing the +project's core and optional dependencies. + + + +``dependency_links.txt`` +------------------------ + +A list of dependency URLs, one per line, as specified using the +``dependency_links`` keyword to ``setup()``. These may be direct +download URLs, or the URLs of web pages containing direct download +links, and will be used by EasyInstall to find dependencies, as though +the user had manually provided them via the ``--find-links`` command +line option. Please see the setuptools manual and EasyInstall manual +for more information on specifying this option, and for information on +how EasyInstall processes ``--find-links`` URLs. + + +``depends.txt`` -- Obsolete, do not create! +------------------------------------------- + +This file follows an identical format to ``requires.txt``, but is +obsolete and should not be used. The earliest versions of setuptools +required users to manually create and maintain this file, so the runtime +still supports reading it, if it exists. The new filename was created +so that it could be automatically generated from ``setup()`` information +without overwriting an existing hand-created ``depends.txt``, if one +was already present in the project's source ``.egg-info`` directory. + + +``namespace_packages.txt`` -- Namespace Package Metadata +======================================================== + +A list of namespace package names, one per line, as supplied to the +``namespace_packages`` keyword to ``setup()``. Please see the manuals +for setuptools and ``pkg_resources`` for more information about +namespace packages. + + +``entry_points.txt`` -- "Entry Point"/Plugin Metadata +===================================================== + +This is a "sectioned" text file, whose contents encode the +``entry_points`` keyword supplied to ``setup()``. All sections are +named, as the section names specify the entry point groups in which the +corresponding section's entry points are registered. + +Each section is a sequence of "entry point" lines, each parseable using +the ``EntryPoint.parse`` classmethod; please see the ``pkg_resources`` +manual for the complete entry point parsing syntax. + +Note that it is not necessary to parse this file directly; the +``pkg_resources`` module provides a variety of APIs to locate and load +entry points automatically. Please see the setuptools and +``pkg_resources`` manuals for details on the nature and uses of entry +points. + + +The ``scripts`` Subdirectory +============================ + +This directory is currently only created for ``.egg`` files built by +the setuptools ``bdist_egg`` command. It will contain copies of all +of the project's "traditional" scripts (i.e., those specified using the +``scripts`` keyword to ``setup()``). This is so that they can be +reconstituted when an ``.egg`` file is installed. + +The scripts are placed here using the disutils' standard +``install_scripts`` command, so any ``#!`` lines reflect the Python +installation where the egg was built. But instead of copying the +scripts to the local script installation directory, EasyInstall writes +short wrapper scripts that invoke the original scripts from inside the +egg, after ensuring that sys.path includes the egg and any eggs it +depends on. For more about `script wrappers`_, see the section below on +`Installation and Path Management Issues`_. + + +Zip Support Metadata +==================== + + +``native_libs.txt`` +------------------- + +A list of C extensions and other dynamic link libraries contained in +the egg, one per line. Paths are ``/``-separated and relative to the +egg's base location. + +This file is generated as part of ``bdist_egg`` processing, and as such +only appears in ``.egg`` files (and ``.egg`` directories created by +unpacking them). It is used to ensure that all libraries are extracted +from a zipped egg at the same time, in case there is any direct linkage +between them. Please see the `Zip File Issues`_ section below for more +information on library and resource extraction from ``.egg`` files. + + +``eager_resources.txt`` +----------------------- + +A list of resource files and/or directories, one per line, as specified +via the ``eager_resources`` keyword to ``setup()``. Paths are +``/``-separated and relative to the egg's base location. + +Resource files or directories listed here will be extracted +simultaneously, if any of the named resources are extracted, or if any +native libraries listed in ``native_libs.txt`` are extracted. Please +see the setuptools manual for details on what this feature is used for +and how it works, as well as the `Zip File Issues`_ section below. + + +``zip-safe`` and ``not-zip-safe`` +--------------------------------- + +These are zero-length files, and either one or the other should exist. +If ``zip-safe`` exists, it means that the project will work properly +when installedas an ``.egg`` zipfile, and conversely the existence of +``not-zip-safe`` means the project should not be installed as an +``.egg`` file. The ``zip_safe`` option to setuptools' ``setup()`` +determines which file will be written. If the option isn't provided, +setuptools attempts to make its own assessment of whether the package +can work, based on code and content analysis. + +If neither file is present at installation time, EasyInstall defaults +to assuming that the project should be unzipped. (Command-line options +to EasyInstall, however, take precedence even over an existing +``zip-safe`` or ``not-zip-safe`` file.) + +Note that these flag files appear only in ``.egg`` files generated by +``bdist_egg``, and in ``.egg`` directories created by unpacking such an +``.egg`` file. + + + +``top_level.txt`` -- Conflict Management Metadata +================================================= + +This file is a list of the top-level module or package names provided +by the project, one Python identifier per line. + +Subpackages are not included; a project containing both a ``foo.bar`` +and a ``foo.baz`` would include only one line, ``foo``, in its +``top_level.txt``. + +This data is used by ``pkg_resources`` at runtime to issue a warning if +an egg is added to ``sys.path`` when its contained packages may have +already been imported. + +(It was also once used to detect conflicts with non-egg packages at +installation time, but in more recent versions, setuptools installs eggs +in such a way that they always override non-egg packages, thus +preventing a problem from arising.) + + +``SOURCES.txt`` -- Source Files Manifest +======================================== + +This file is roughly equivalent to the distutils' ``MANIFEST`` file. +The differences are as follows: + +* The filenames always use ``/`` as a path separator, which must be + converted back to a platform-specific path whenever they are read. + +* The file is automatically generated by setuptools whenever the + ``egg_info`` or ``sdist`` commands are run, and it is *not* + user-editable. + +Although this metadata is included with distributed eggs, it is not +actually used at runtime for any purpose. Its function is to ensure +that setuptools-built *source* distributions can correctly discover +what files are part of the project's source, even if the list had been +generated using revision control metadata on the original author's +system. + +In other words, ``SOURCES.txt`` has little or no runtime value for being +included in distributed eggs, and it is possible that future versions of +the ``bdist_egg`` and ``install_egg_info`` commands will strip it before +installation or distribution. Therefore, do not rely on its being +available outside of an original source directory or source +distribution. + + +------------------------------ +Other Technical Considerations +------------------------------ + + +Zip File Issues +=============== + +Although zip files resemble directories, they are not fully +substitutable for them. Most platforms do not support loading dynamic +link libraries contained in zipfiles, so it is not possible to directly +import C extensions from ``.egg`` zipfiles. Similarly, there are many +existing libraries -- whether in Python or C -- that require actual +operating system filenames, and do not work with arbitrary "file-like" +objects or in-memory strings, and thus cannot operate directly on the +contents of zip files. + +To address these issues, the ``pkg_resources`` module provides a +"resource API" to support obtaining either the contents of a resource, +or a true operating system filename for the resource. If the egg +containing the resource is a directory, the resource's real filename +is simply returned. However, if the egg is a zipfile, then the +resource is first extracted to a cache directory, and the filename +within the cache is returned. + +The cache directory is determined by the ``pkg_resources`` API; please +see the ``set_cache_path()`` and ``get_default_cache()`` documentation +for details. + + +The Extraction Process +---------------------- + +Resources are extracted to a cache subdirectory whose name is based +on the enclosing ``.egg`` filename and the path to the resource. If +there is already a file of the correct name, size, and timestamp, its +filename is returned to the requester. Otherwise, the desired file is +extracted first to a temporary name generated using +``mkstemp(".$extract",target_dir)``, and then its timestamp is set to +match the one in the zip file, before renaming it to its final name. +(Some collision detection and resolution code is used to handle the +fact that Windows doesn't overwrite files when renaming.) + +If a resource directory is requested, all of its contents are +recursively extracted in this fashion, to ensure that the directory +name can be used as if it were valid all along. + +If the resource requested for extraction is listed in the +``native_libs.txt`` or ``eager_resources.txt`` metadata files, then +*all* resources listed in *either* file will be extracted before the +requested resource's filename is returned, thus ensuring that all +C extensions and data used by them will be simultaneously available. + + +Extension Import Wrappers +------------------------- + +Since Python's built-in zip import feature does not support loading +C extension modules from zipfiles, the setuptools ``bdist_egg`` command +generates special import wrappers to make it work. + +The wrappers are ``.py`` files (along with corresponding ``.pyc`` +and/or ``.pyo`` files) that have the same module name as the +corresponding C extension. These wrappers are located in the same +package directory (or top-level directory) within the zipfile, so that +say, ``foomodule.so`` will get a corresponding ``foo.py``, while +``bar/baz.pyd`` will get a corresponding ``bar/baz.py``. + +These wrapper files contain a short stanza of Python code that asks +``pkg_resources`` for the filename of the corresponding C extension, +then reloads the module using the obtained filename. This will cause +``pkg_resources`` to first ensure that all of the egg's C extensions +(and any accompanying "eager resources") are extracted to the cache +before attempting to link to the C library. + +Note, by the way, that ``.egg`` directories will also contain these +wrapper files. However, Python's default import priority is such that +C extensions take precedence over same-named Python modules, so the +import wrappers are ignored unless the egg is a zipfile. + + +Installation and Path Management Issues +======================================= + +Python's initial setup of ``sys.path`` is very dependent on the Python +version and installation platform, as well as how Python was started +(i.e., script vs. ``-c`` vs. ``-m`` vs. interactive interpreter). +In fact, Python also provides only two relatively robust ways to affect +``sys.path`` outside of direct manipulation in code: the ``PYTHONPATH`` +environment variable, and ``.pth`` files. + +However, with no cross-platform way to safely and persistently change +environment variables, this leaves ``.pth`` files as EasyInstall's only +real option for persistent configuration of ``sys.path``. + +But ``.pth`` files are rather strictly limited in what they are allowed +to do normally. They add directories only to the *end* of ``sys.path``, +after any locally-installed ``site-packages`` directory, and they are +only processed *in* the ``site-packages`` directory to start with. + +This is a double whammy for users who lack write access to that +directory, because they can't create a ``.pth`` file that Python will +read, and even if a sympathetic system administrator adds one for them +that calls ``site.addsitedir()`` to allow some other directory to +contain ``.pth`` files, they won't be able to install newer versions of +anything that's installed in the systemwide ``site-packages``, because +their paths will still be added *after* ``site-packages``. + +So EasyInstall applies two workarounds to solve these problems. + +The first is that EasyInstall leverages ``.pth`` files' "import" feature +to manipulate ``sys.path`` and ensure that anything EasyInstall adds +to a ``.pth`` file will always appear before both the standard library +and the local ``site-packages`` directories. Thus, it is always +possible for a user who can write a Python-read ``.pth`` file to ensure +that their packages come first in their own environment. + +Second, when installing to a ``PYTHONPATH`` directory (as opposed to +a "site" directory like ``site-packages``) EasyInstall will also install +a special version of the ``site`` module. Because it's in a +``PYTHONPATH`` directory, this module will get control before the +standard library version of ``site`` does. It will record the state of +``sys.path`` before invoking the "real" ``site`` module, and then +afterwards it processes any ``.pth`` files found in ``PYTHONPATH`` +directories, including all the fixups needed to ensure that eggs always +appear before the standard library in sys.path, but are in a relative +order to one another that is defined by their ``PYTHONPATH`` and +``.pth``-prescribed sequence. + +The net result of these changes is that ``sys.path`` order will be +as follows at runtime: + +1. The ``sys.argv[0]`` directory, or an emtpy string if no script + is being executed. + +2. All eggs installed by EasyInstall in any ``.pth`` file in each + ``PYTHONPATH`` directory, in order first by ``PYTHONPATH`` order, + then normal ``.pth`` processing order (which is to say alphabetical + by ``.pth`` filename, then by the order of listing within each + ``.pth`` file). + +3. All eggs installed by EasyInstall in any ``.pth`` file in each "site" + directory (such as ``site-packages``), following the same ordering + rules as for the ones on ``PYTHONPATH``. + +4. The ``PYTHONPATH`` directories themselves, in their original order + +5. Any paths from ``.pth`` files found on ``PYTHONPATH`` that were *not* + eggs installed by EasyInstall, again following the same relative + ordering rules. + +6. The standard library and "site" directories, along with the contents + of any ``.pth`` files found in the "site" directories. + +Notice that sections 1, 4, and 6 comprise the "normal" Python setup for +``sys.path``. Sections 2 and 3 are inserted to support eggs, and +section 5 emulates what the "normal" semantics of ``.pth`` files on +``PYTHONPATH`` would be if Python natively supported them. + +For further discussion of the tradeoffs that went into this design, as +well as notes on the actual magic inserted into ``.pth`` files to make +them do these things, please see also the following messages to the +distutils-SIG mailing list: + +* http://mail.python.org/pipermail/distutils-sig/2006-February/006026.html +* http://mail.python.org/pipermail/distutils-sig/2006-March/006123.html + + +Script Wrappers +--------------- + +EasyInstall never directly installs a project's original scripts to +a script installation directory. Instead, it writes short wrapper +scripts that first ensure that the project's dependencies are active +on sys.path, before invoking the original script. These wrappers +have a #! line that points to the version of Python that was used to +install them, and their second line is always a comment that indicates +the type of script wrapper, the project version required for the script +to run, and information identifying the script to be invoked. + +The format of this marker line is:: + + "# EASY-INSTALL-" script_type ": " tuple_of_strings "\n" + +The ``script_type`` is one of ``SCRIPT``, ``DEV-SCRIPT``, or +``ENTRY-SCRIPT``. The ``tuple_of_strings`` is a comma-separated +sequence of Python string constants. For ``SCRIPT`` and ``DEV-SCRIPT`` +wrappers, there are two strings: the project version requirement, and +the script name (as a filename within the ``scripts`` metadata +directory). For ``ENTRY-SCRIPT`` wrappers, there are three: +the project version requirement, the entry point group name, and the +entry point name. (See the "Automatic Script Creation" section in the +setuptools manual for more information about entry point scripts.) + +In each case, the project version requirement string will be a string +parseable with the ``pkg_resources`` modules' ``Requirement.parse()`` +classmethod. The only difference between a ``SCRIPT`` wrapper and a +``DEV-SCRIPT`` is that a ``DEV-SCRIPT`` actually executes the original +source script in the project's source tree, and is created when the +"setup.py develop" command is run. A ``SCRIPT`` wrapper, on the other +hand, uses the "installed" script written to the ``EGG-INFO/scripts`` +subdirectory of the corresponding ``.egg`` zipfile or directory. +(``.egg-info`` eggs do not have script wrappers associated with them, +except in the "setup.py develop" case.) + +The purpose of including the marker line in generated script wrappers is +to facilitate introspection of installed scripts, and their relationship +to installed eggs. For example, an uninstallation tool could use this +data to identify what scripts can safely be removed, and/or identify +what scripts would stop working if a particular egg is uninstalled. + diff --git a/docs/index.txt b/docs/index.txt index 5f3b945b..162a5f6f 100644 --- a/docs/index.txt +++ b/docs/index.txt @@ -1,36 +1,25 @@ -Welcome to Distribute's documentation! -====================================== +Welcome to Setuptools' documentation! +===================================== -`Distribute` is a fork of the `Setuptools` project. +Setuptools is a fully-featured, actively-maintained, and stable library +designed to facilitate packaging Python projects, where packaging includes: -Distribute is intended to replace Setuptools as the standard method for -working with Python module distributions. - -For those who may wonder why they should switch to Distribute over Setuptools, it’s quite simple: - -- Distribute is a drop-in replacement for Setuptools -- The code is actively maintained, and has over 10 commiters -- Distribute offers Python 3 support ! + - Python package and module definitions + - Distribution package metadata + - Test hooks + - Project installation + - Platform-specific details + - Python 3 support Documentation content: .. toctree:: :maxdepth: 2 + merge roadmap python3 using setuptools easy_install pkg_resources - - -.. image:: http://python-distribute.org/pip_distribute.png - -Design done by Idan Gazit (http://pixane.com) - License: cc-by-3.0 - -Copy & paste:: - - curl -O http://python-distribute.org/distribute_setup.py - python distribute_setup.py - easy_install pip
\ No newline at end of file diff --git a/docs/merge-faq.txt b/docs/merge-faq.txt new file mode 100644 index 00000000..52013098 --- /dev/null +++ b/docs/merge-faq.txt @@ -0,0 +1,80 @@ +Setuptools/Distribute Merge FAQ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +How do I upgrade from Distribute? +================================= + +Distribute specifically prohibits installation of Setuptools 0.7 from Distribute 0.6. There are then two options for upgrading. + +Note that after upgrading using either technique, the only option to downgrade to either version is to completely uninstall Distribute and Setuptools 0.7 versions before reinstalling an 0.6 release. + +Use Distribute 0.7 +------------------ + +The PYPA has put together a compatibility wrapper, a new release of Distribute version 0.7. This package will install over Distribute 0.6.x installations and will replace Distribute with a simple wrapper that requires Setuptools 0.7 or later. This technique is experimental, but initial results indicate this technique is the easiest upgrade path. + + +Uninstall +--------- + +First, completely uninstall Distribute. Since Distribute does not have an automated installation routine, this process is manual. Follow the instructions in the README for uninstalling. + + +How do I upgrade from Setuptools 0.6? +===================================== + +There are no special instructions for upgrading over older versions of Setuptools. Simply use `easy_install -U` or run the latest `ez_setup.py`. + +Where does the merge occur? +======================================================== + +The merge is occurring between the heads of the default branch of Distribute and the setuptools-0.6 branch of Setuptools. The Setuptools SVN repo has been converted to a Mercurial repo hosted on Bitbucket. The work is still underway, so the exact changesets included may change, although the anticipated merge targets are Setuptools at 0.6c12 and Distribute at 0.6.35. + +What happens to other branches? +======================================================== + +Distribute 0.7 was abandoned long ago and won't be included in the resulting code tree, but may be retained for posterity in the original repo. + +Setuptools default branch (also 0.7 development) may also be abandoned or may be incorporated into the new merged line if desirable (and as resources allow). + +What history is lost/changed? +======================================================== + +As setuptools was not on Mercurial when the fork occurred and as Distribute did not include the full setuptools history (prior to the creation of the setuptools-0.6 branch), the two source trees were not compatible. In order to most effectively communicate the code history, the Distribute code was grafted onto the (originally private) setuptools Mercurial repo. Although this grafting maintained the full code history with names, dates, and changes, it did lose the original hashes of those changes. Therefore, references to changes by hash (including tags) are lost. + +Additionally, any heads that were not actively merged into the Distribute 0.6.35 release were also omitted. As a result, the changesets included in the merge repo are those from the original setuptools repo and all changesets ancestral to the Distribute 0.6.35 release. + +What features will be in the merged code base? +======================================================== + +In general, all "features" added in distribute will be included in setuptools. Where there exist conflicts or undesirable features, we will be explicit about what these limitations are. Changes that are backward-incompatible from setuptools 0.6 to distribute will likely be removed, and these also will be well documented. + +Bootstrapping scripts (ez_setup/distribute_setup) and docs, as with distribute, will be maintained in the repository and built as part of the release process. Documentation and bootstrapping scripts will be hosted at python.org, as they are with distribute now. Documentation at telecommunity will be updated to refer or redirect to the new, merged docs. + +On the whole, the merged setuptools should be largely compatible with the latest releases of both setuptools and distribute and will be an easy transition for users of either library. + +Who is invited to contribute? Who is excluded? +======================================================== + +While we've worked privately to initiate this merge due to the potential sensitivity of the topic, no one is excluded from this effort. We invite all members of the community, especially those most familiar with Python packaging and its challenges to join us in the effort. + +We have lots of ideas for how we'd like to improve the codebase, release process, everything. Like distribute, the post-merge setuptools will have its source hosted on bitbucket. (So if you're currently a distribute contributor, about the only thing that's going to change is the URL of the repository you follow.) Also like distribute, it'll support Python 3, and hopefully we'll soon merge Vinay Sajip's patches to make it run on Python 3 without needing 2to3 to be run on the code first. + +While we've worked privately to initiate this merge due to the potential sensitivity of the topic, no one is excluded from this effort. We invite all members of the community, especially those most familiar with Python packaging and its challenges to join us in the effort. + +Why Setuptools and not Distribute or another name? +======================================================== + +We do, however, understand that this announcement might be unsettling for some. The setuptools name has been subjected to a lot of deprecation in recent years, so the idea that it will now be the preferred name instead of distribute might be somewhat difficult or disorienting for some. We considered use of another name (Distribute or an entirely new name), but that would serve to only complicate matters further. Instead, our goal is to simplify the packaging landscape but without losing any hard-won advancements. We hope that the people who worked to spread the first message will be equally enthusiastic about spreading the new one, and we especially look forward to seeing the new posters and slogans celebrating setuptools. + +What is the timeframe of release? +======================================================== + +There are no hard timeframes for any of this effort, although progress is underway and a draft merge is underway and being tested privately. As an unfunded volunteer effort, our time to put in on it is limited, and we've both had some recent health and other challenges that have made working on this difficult, which in part explains why we haven't met our original deadline of a completed merge before PyCon. + +The final Setuptools 0.7 was cut on June 1, 2013 and will be released to PyPI shortly thereafter. + +What version number can I expect for the new release? +======================================================== + +The new release will roughly follow the previous trend for setuptools and release the new release as 0.7. This number is somewhat arbitrary, but we wanted something other than 0.6 to distinguish it from its ancestor forks but not 1.0 to avoid putting too much emphasis on the release itself and to focus on merging the functionality. In the future, the project will likely adopt a versioning scheme similar to semver to convey semantic meaning about the release in the version number. diff --git a/docs/merge.txt b/docs/merge.txt new file mode 100644 index 00000000..ba37d6e4 --- /dev/null +++ b/docs/merge.txt @@ -0,0 +1,122 @@ +Merge with Distribute +~~~~~~~~~~~~~~~~~~~~~ + +In 2013, the fork of Distribute was merged back into Setuptools. This +document describes some of the details of the merge. + +.. toctree:: + :maxdepth: 2 + + merge-faq + +Process +======= + +In order to try to accurately reflect the fork and then re-merge of the +projects, the merge process brought both code trees together into one +repository and grafted the Distribute fork onto the Setuptools development +line (as if it had been created as a branch in the first place). + +The rebase to get distribute onto setuptools went something like this:: + + hg phase -d -f -r 26b4c29b62db + hg rebase -s 26b4c29b62db -d 7a5cf59c78d7 + +The technique required a late version of mercurial (2.5) to work correctly. + +The only code that was included was the code that was ancestral to the public +releases of Distribute 0.6. Additionally, because Setuptools was not hosted +on Mercurial at the time of the fork and because the Distribute fork did not +include a complete conversion of the Setuptools history, the Distribute +changesets had to be re-applied to a new, different conversion of the +Setuptools SVN repository. As a result, all of the hashes have changed. + +Distribute was grafted in a 'distribute' branch and the 'setuptools-0.6' +branch was targeted for the merge. The 'setuptools' branch remains with +unreleased code and may be incorporated in the future. + +Reconciling Differences +======================= + +There were both technical and philosophical differences between Setuptools +and Distribute. To reconcile these differences in a manageable way, the +following technique was undertaken: + +Create a 'Setuptools-Distribute merge' branch, based on a late release of +Distribute (0.6.35). This was done with a00b441856c4. + +In that branch, first remove code that is no longer relevant to +Setuptools (such as the setuptools patching code). + +Next, in the the merge branch, create another base from at the point where the +fork occurred (such that the code is still essentially an older but pristine +setuptools). This base can be found as 955792b069d0. This creates two heads +in the merge branch, each with a basis in the fork. + +Then, repeatedly copy changes for a +single file or small group of files from a late revision of that file in the +'setuptools-0.6' branch (1aae1efe5733 was used) and commit those changes on +the setuptools-only head. That head is then merged with the head with +Distribute changes. It is in this Mercurial +merge operation that the fundamental differences between Distribute and +Setuptools are reconciled, but since only a single file or small set of files +are used, the scope is limited. + +Finally, once all the challenging files have been reconciled and merged, the +remaining changes from the setuptools-0.6 branch are merged, deferring to the +reconciled changes (a1fa855a5a62 and 160ccaa46be0). + +Originally, jaraco attempted all of this using anonymous heads in the +Distribute branch, but later realized this technique made for a somewhat +unclear merge process, so the changes were re-committed as described above +for clarity. In this way, the "distribute" and "setuptools" branches can +continue to track the official Distribute changesets. + +Concessions +=========== + +With the merge of Setuptools and Distribute, the following concessions were +made: + +Differences from setuptools 0.6c12: + +Major Changes +------------- + +* Python 3 support. +* Improved support for GAE. +* Support `PEP-370 <http://www.python.org/dev/peps/pep-0370/>`_ per-user site + packages. +* Sort order of Distributions in pkg_resources now prefers PyPI to external + links (Distribute issue 163). +* Python 2.4 or greater is required (drop support for Python 2.3). + +Minor Changes +------------- + +* Wording of some output has changed to replace contractions with their + canonical form (i.e. prefer "could not" to "couldn't"). +* Manifest files are only written for 32-bit .exe launchers. + +Differences from Distribute 0.6.36: + +Major Changes +------------- + +* The _distribute property of the setuptools module has been removed. +* Distributions are once again installed as zipped eggs by default, per the + rationale given in `the seminal bug report + <http://bugs.python.org/setuptools/issue33>`_ indicates that the feature + should remain and no substantial justification was given in the `Distribute + report <https://bitbucket.org/tarek/distribute/issue/19/>`_. + +Minor Changes +------------- + +* The patch for `#174 <https://bitbucket.org/tarek/distribute/issue/174>`_ + has been rolled-back, as the comment on the ticket indicates that the patch + addressed a symptom and not the fundamental issue. +* ``easy_install`` (the command) once again honors setup.cfg if found in the + current directory. The "mis-behavior" characterized in `#99 + <https://bitbucket.org/tarek/distribute/issue/99>`_ is actually intended + behavior, and no substantial rationale was given for the deviation. diff --git a/docs/python3.txt b/docs/python3.txt index 2f6cde4a..1e019951 100644 --- a/docs/python3.txt +++ b/docs/python3.txt @@ -1,18 +1,19 @@ ===================================================== -Supporting both Python 2 and Python 3 with Distribute +Supporting both Python 2 and Python 3 with Setuptools ===================================================== -Starting with version 0.6.2, Distribute supports Python 3. Installing and -using distribute for Python 3 code works exactly the same as for Python 2 -code, but Distribute also helps you to support Python 2 and Python 3 from +Starting with Distribute version 0.6.2 and Setuptools 0.7, the Setuptools +project supported Python 3. Installing and +using setuptools for Python 3 code works exactly the same as for Python 2 +code, but Setuptools also helps you to support Python 2 and Python 3 from the same source code by letting you run 2to3 on the code as a part of the build process, by setting the keyword parameter ``use_2to3`` to True. -Distribute as help during porting +Setuptools as help during porting ================================= -Distribute can make the porting process much easier by automatically running +Setuptools can make the porting process much easier by automatically running 2to3 as a part of the test running. To do this you need to configure the setup.py so that you can run the unit tests with ``python setup.py test``. @@ -24,10 +25,10 @@ The test command will now first run the build command during which the code will be converted with 2to3, and the tests will then be run from the build directory, as opposed from the source directory as is normally done. -Distribute will convert all Python files, and also all doctests in Python +Setuptools will convert all Python files, and also all doctests in Python files. However, if you have doctests located in separate text files, these will not automatically be converted. By adding them to the -``convert_2to3_doctests`` keyword parameter Distrubute will convert them as +``convert_2to3_doctests`` keyword parameter Setuptools will convert them as well. By default, the conversion uses all fixers in the ``lib2to3.fixers`` package. @@ -86,12 +87,14 @@ Advanced features If you don't want to run the 2to3 conversion on the doctests in Python files, you can turn that off by setting ``setuptools.use_2to3_on_doctests = False``. -Note on compatibility with setuptools -===================================== +Note on compatibility with older versions of setuptools +======================================================= -Setuptools do not know about the new keyword parameters to support Python 3. +Setuptools earlier than 0.7 does not know about the new keyword parameters to +support Python 3. As a result it will warn about the unknown keyword parameters if you use -setuptools instead of Distribute under Python 2. This is not an error, and +those versions of setuptools instead of Distribute under Python 2. This output +is not an error, and install process will continue as normal, but if you want to get rid of that error this is easy. Simply conditionally add the new parameters into an extra dict and pass that dict into setup():: @@ -117,5 +120,5 @@ dict and pass that dict into setup():: **extra ) -This way the parameters will only be used under Python 3, where you have to -use Distribute. +This way the parameters will only be used under Python 3, where Distribute or +Setuptools 0.7 or later is required. diff --git a/docs/roadmap.txt b/docs/roadmap.txt index ea5070ea..44bcdb0f 100644 --- a/docs/roadmap.txt +++ b/docs/roadmap.txt @@ -2,85 +2,13 @@ Roadmap ======= -Distribute has two branches: +Setuptools has merged with Distribute and to provide a unified codebase for +ongoing development. -- 0.6.x : provides a Setuptools-0.6cX compatible version -- 0.7.x : will provide a refactoring - -0.6.x -===== - -Not "much" is going to happen here, we want this branch to be helpful -to the community *today* by addressing the 40-or-so bugs -that were found in Setuptools and never fixed. This is eventually -happen soon because its development is -fast : there are up to 5 commiters that are working on it very often -(and the number grows weekly.) - -The biggest issue with this branch is that it is providing the same -packages and modules setuptools does, and this -requires some bootstrapping work where we make sure once Distribute is -installed, all Distribution that requires Setuptools -will continue to work. This is done by faking the metadata of -Setuptools 0.6c9. That's the only way we found to do this. - -There's one major thing though: thanks to the work of Lennart, Alex, -Martin, this branch supports Python 3, -which is great to have to speed up Py3 adoption. - -The goal of the 0.6.x is to remove as much bugs as we can, and try if -possible to remove the patches done -on Distutils. We will support 0.6.x maintenance for years and we will -promote its usage everywhere instead of -Setuptools. - -Some new commands are added there, when they are helpful and don't -interact with the rest. I am thinking -about "upload_docs" that let you upload documentation to PyPI. The -goal is to move it to Distutils -at some point, if the documentation feature of PyPI stays and starts to be used. - -0.7.x -===== - -We've started to refactor Distribute with this roadmap in mind (and -no, as someone said, it's not vaporware, -we've done a lot already) - -- 0.7.x can be installed and used with 0.6.x - -- easy_install is going to be deprecated ! use Pip ! - -- the version system will be deprecated, in favor of the one in Distutils - -- no more Distutils monkey-patch that happens once you use the code - (things like 'from distutils import cmd; cmd.Command = CustomCommand') - -- no more custom site.py (that is: if something misses in Python's - site.py we'll add it there instead of patching it) - -- no more namespaced packages system, if PEP 382 (namespaces package - support) makes it to 2.7 - -- The code is splitted in many packages and might be distributed under - several distributions. - - - distribute.resources: that's the old pkg_resources, but - reorganized in clean, pep-8 modules. This package will - only contain the query APIs and will focus on being PEP 376 - compatible. We will promote its usage and see if Pip wants - to use it as a basis. - It will probably shrink a lot though, once the stdlib provides PEP 376 support. - - - distribute.entrypoints: that's the old pkg_resources entry points - system, but on its own. it uses distribute.resources - - - distribute.index: that's package_index and a few other things. - everything required to interact with PyPI. We will promote - its usage and see if Pip wants to use it as a basis. - - - distribute.core (might be renamed to main): that's everything - else, and uses the other packages. - -Goal: A first release before (or when) Python 2.7 / 3.2 is out. +This new effort will draw from the resources of both projects to leverage +community contribution for ongoing advancement but also maintain stability +for the user base. +An initial release of Setuptools 0.7 will attempt to be compatible both with +Setuptools 0.6c11 and Distribute 0.6.36. Where compatibility cannot be +achieved, the changes should be well-documented. diff --git a/docs/setuptools.txt b/docs/setuptools.txt index fe8bb3f6..5d80b230 100644 --- a/docs/setuptools.txt +++ b/docs/setuptools.txt @@ -1,8 +1,8 @@ ================================================== -Building and Distributing Packages with Distribute +Building and Distributing Packages with Setuptools ================================================== -``Distribute`` is a collection of enhancements to the Python ``distutils`` +``Setuptools`` is a collection of enhancements to the Python ``distutils`` (for Python 2.3.5 and up on most platforms; 64-bit platforms require a minimum of Python 2.4) that allow you to more easily build and distribute Python packages, especially ones that have dependencies on other packages. @@ -15,7 +15,7 @@ including just a single `bootstrap module`_ (an 8K .py file), your package will automatically download and install ``setuptools`` if the user is building your package from source and doesn't have a suitable version already installed. -.. _bootstrap module: http://nightly.ziade.org/distribute_setup.py +.. _bootstrap module: https://bitbucket.org/pypa/setuptools/downloads/ez_setup.py Feature Highlights: @@ -2406,7 +2406,7 @@ The ``upload`` command has a few options worth noting: ``--repository=URL, -r URL`` The URL of the repository to upload to. Defaults to - http://pypi.python.org/pypi (i.e., the main PyPI installation). + https://pypi.python.org/pypi (i.e., the main PyPI installation). .. _upload_docs: @@ -2414,7 +2414,7 @@ The ``upload`` command has a few options worth noting: ====================================================== PyPI now supports uploading project documentation to the dedicated URL -http://packages.python.org/<project>/. +https://pythonhosted.org/<project>/. The ``upload_docs`` command will create the necessary zip file out of a documentation directory and will post to the repository. @@ -2468,7 +2468,7 @@ The ``upload_docs`` command has the following options: ``--repository=URL, -r URL`` The URL of the repository to upload to. Defaults to - http://pypi.python.org/pypi (i.e., the main PyPI installation). + https://pypi.python.org/pypi (i.e., the main PyPI installation). -------------------------------- diff --git a/docs/using.txt b/docs/using.txt index 192f1dc2..6f93c386 100644 --- a/docs/using.txt +++ b/docs/using.txt @@ -1,21 +1,10 @@ ================================ -Using Distribute in your project +Using Setuptools in your project ================================ -To use Distribute in your project, the recommended way is to ship -`distribute_setup.py` alongside your `setup.py` script and call +To use Setuptools in your project, the recommended way is to ship +`ez_setup.py` alongside your `setup.py` script and call it at the very begining of `setup.py` like this:: - from distribute_setup import use_setuptools + from ez_setup import use_setuptools use_setuptools() - -Another way is to add ``Distribute`` in the ``install_requires`` option:: - - from setuptools import setup - - setup(... - install_requires=['distribute'] - ) - - -XXX to be finished |