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
This commit is contained in:
Thomas Kluyver 2016-11-28 18:27:07 +00:00 committed by Brett Cannon
parent c6fbead696
commit 024a7d586f
1 changed files with 18 additions and 32 deletions

View File

@ -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