517: Remove install_editable hook (Option 1c) (#141)

* 517: Remove install_editable hook (Option 1c)

This is the other option for --user editable installs: don't try to
standardise a mechanism. This could always be added back in a later PEP.

Alternative to gh-140

* Add note about removal of editable install

pep-0517.txt

@@ -212,31 +212,16 @@ including any unrecognized files it created.
 
 Mandatory.
 
-::
+.. note:: Editable installs
 
-  def install_editable(prefix, config_settings, metadata_directory=None):
-      ...
+   This PEP originally specified a fourth hook, ``install_editable``, to do an
+   editable install (as with ``pip install -e``). It was removed due to the
+   complexity of the topic, but may be specified in a later PEP.
 
-Must perform whatever actions are necessary to install the current
-project into the Python installation at ``install_prefix`` in an
-"editable" fashion. This is intentionally underspecified, because it's
-included as a stopgap to avoid regressing compared to the current
-equally underspecified setuptools ``develop`` command; hopefully a
-future PEP will replace this hook with something that works better and
-is better specified. (Unfortunately, cleaning up editable installs to
-actually work well and be well-specified turns out to be a large and
-difficult job, so we prefer not to do a half-way job here.)
-
-For the meaning and requirements of the ``metadata_directory``
-argument, see ``build_wheel`` above.
-
-[XX UNRESOLVED: it isn't entirely clear whether ``prefix`` alone is
-enough to support all needed configurations -- in particular,
-@takluyver has suggested that contra to the distutils docs, ``--user``
-on Windows is not expressible in terms of a regular prefix install.]
-
-Optional. If not defined, then this build backend does not support
-editable builds.
+   Briefly, the questions to be answered include: what reasonable ways existing
+   of implementing an 'editable install'? Should the backend or the frontend
+   pick how to make an editable install? And if the frontend does, what does it
+   need from the backend to do so.
 
 ::
 
@@ -560,11 +545,12 @@ across the ecosystem.
 more powerful options for evolving this specification in the future.
 
 For concreteness, imagine that next year we add a new
-``install_editable2`` hook, which replaces the current
-``install_editable`` hook with something better specified. In order to
+``get_wheel_metadata2`` hook, which replaces the current
+``get_wheel_metadata`` hook with something that produces more data, or a
+different metadata format. In order to
 manage the transition, we want it to be possible for build frontends
-to transparently use ``install_editable2`` when available and fall
-back onto ``install_editable`` otherwise; and we want it to be
+to transparently use ``get_wheel_metadata2`` when available and fall
+back onto ``get_wheel_metadata`` otherwise; and we want it to be
 possible for build backends to define both methods, for compatibility
 with both old and new build frontends.
 
@@ -582,11 +568,11 @@ achieve. Because ``pip`` controls the code that runs inside the child
 process, it can easily write it to do something like::
 
     command, backend, args = parse_command_line_args(...)
-    if command == "do_editable_install":
-       if hasattr(backend, "install_editable2"):
-           backend.install_editable2(...)
-       elif hasattr(backend, "install_editable"):
-           backend.install_editable(...)
+    if command == "get_wheel_metadata":
+       if hasattr(backend, "get_wheel_metadata2"):
+           backend.get_wheel_metadata2(...)
+       elif hasattr(backend, "get_wheel_metadata"):
+           backend.get_wheel_metadata(...)
        else:
            # error handling