Update userguide on `miscellaneous` and `extension`

This is a continuation of the update effort to de-emphasize `distutils`
and make the documentation more consistent.

The main targets of the changes are the files
`docs/userguide/miscellaneous` and `docs/userguide/extension`.

Changes:

- Extracted text about automatic resource extraction and the zip-safe flag
  from `userguide/miscellaneous` to `deprecated/resource_extraction` and
  `deprecated/zip_safe`.
  - These configuration parameters are commonly associated with
    ``eggs``/``easy_install``/``pkg_resources``, and therefore are
    obsolete. Leaving them around in the main parts of the documentation
    just confuses users.
  - The text in the new files were updated.
- Extracted text about additional metadata from
  `userguide/miscellaneous` into the existing `userguide/extension`
  document.
- Updated `userguide/extension` to better reflect the status of the
  setuptools project.
  The text was also changed to explain a little bit more what is the
  relationship between ``setuptools`` and ``distutils``.
- Removed `userguide/functionalities_rewrite`.
  This file was virtually empty and not bringing any extra value to the
  docs.

1 files changed, 54 insertions, 0 deletions

diff --git a/docs/deprecated/resource_extraction.rst b/docs/deprecated/resource_extraction.rst
new file mode 100644
index 00000000..19190baf
--- /dev/null
+++ b/docs/deprecated/resource_extraction.rst
@@ -0,0 +1,54 @@
+.. _Automatic Resource Extraction:
+
+Automatic Resource Extraction
+=============================
+
+In a modern setup, Python packages are usually installed as directories,
+and all the files can be found on deterministic locations on the disk.
+This means that most of the tools expect package resources to be "real" files.
+
+There are a few occasions however that packages are loaded in a different way
+(e.g. from a zip file), which is incompatible with the assumptions mentioned above.
+Moreover, a package developer may also include non-extension native libraries or other files that
+C extensions may expect to be able to access.
+
+In these scenarios, the use of :mod:`importlib.resources` is recommended.
+
+Old implementations (prior to the advent of :mod:`importlib.resources`) and
+long-living projects, however, may still rely on the library ``pkg_resources``
+to access these files.
+
+If you have to support such systems, or want to provide backward compatibility
+for ``pkg_resources``, you may need to add an special configuration
+to ``setuptools`` when packaging a project.
+This can be done by listing as ``eager_resources`` (argument to ``setup()``
+in ``setup.py`` or field in ``setup.cfg``) all the files that need to be
+extracted together, whenever a C extension in the project is imported.
+
+This is especially important if your project includes shared libraries *other*
+than ``distutils``/``setuptools``-built C extensions, and those shared libraries use file
+extensions other than ``.dll``, ``.so``, or ``.dylib``, which are the
+extensions that setuptools 0.6a8 and higher automatically detects as shared
+libraries and adds to the ``native_libs.txt`` file for you.  Any shared
+libraries whose names do not end with one of those extensions should be listed
+as ``eager_resources``, because they need to be present in the filesystem when
+he C extensions that link to them are used.
+
+The ``pkg_resources`` runtime for compressed packages will automatically
+extract *all* C extensions and ``eager_resources`` at the same time, whenever
+*any* C extension or eager resource is requested via the ``resource_filename()``
+API.  (C extensions are imported using ``resource_filename()`` internally.)
+This ensures that C extensions will see all of the "real" files that they
+expect to see.
+
+Note also that you can list directory resource names in ``eager_resources`` as
+well, in which case the directory's contents (including subdirectories) will be
+extracted whenever any C extension or eager resource is requested.
+
+Please note that if you're not sure whether you need to use this argument, you
+don't!  It's really intended to support projects with lots of non-Python
+dependencies and as a last resort for crufty projects that can't otherwise
+handle being compressed.  If your package is pure Python, Python plus data
+files, or Python plus C, you really don't need this.  You've got to be using
+either C or an external program that needs "real" files in your project before
+there's any possibility of ``eager_resources`` being relevant to your project.