517: Remove install_editable hook (Option 1c) #141
Conversation
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 pythongh-140
|
Let's go with this one for now... |
|
I'm inclined to agree. We've currently specified that the frontend asks the backend to do an editable install to a target location. But from the discussion on the mailing list, some people see the backend just producing metadata, and the frontend responsible for putting the package on |
|
It might make sense to take this pr + add a short rationale for why it's
being deferred (basically what you just wrote) + links to the relevant
discussion, to provide some reference for whoever writes this hypothetical
future PEP.
…On Nov 25, 2016 3:36 AM, "Thomas Kluyver" ***@***.***> wrote:
I'm inclined to agree.
We've currently specified that the frontend asks the backend to do an
editable install to a target location. But from the discussion on the
mailing list, some people see the backend just producing metadata, and the
frontend responsible for putting the package on sys.path. Then there are
questions over the best way to do an editable install. There's a lot to be
discussed about editable installs, and that discussion isn't necessary for
the main part of this PEP.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#141 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAlOaCDlBZ4AHDfODqn6VnQOYECVCv7Xks5rBsgqgaJpZM4K7_gj>
.
|
|
Good idea. I've added a note. I didn't link to the discussion, as we didn't really get into editable installs much (so far), so I'm not sure it's that useful when we come back to the topic. I've tried to summarise what I see as the questions in the note instead. |
This is the other option for
--usereditable installs: don't try to standardise a mechanism. This could always be added back in a later PEP.Alternative to gh-140