But I’m trying to describe a situation where the user is reporting a bug. We can’t assume in that situation that the bug isn’t in the backend providing incorrect data. And the frontend can’t as you suggest validate that data, because it has no way of knowing what needs to be exposed for an editable install, that’s what the backend tells it, and the frontend simply has to trust the backend.
So my question remains - who should we direct the user to report the bug to? We don’t have the resources to have every bug triaged by the frontend before being passed to the backend, or vice versa. That’s why (in my view) having all of the code in one component is more maintainable.
I’d still stay more often than not; the frontend is the best place to report. The front-end triage member might then say, what’s the error and what data the backend provides. The front end might offer a command to expose the backend-provided data easily. Then, by looking at the data, the backend provides the frontend triager can tell that given this data provided by the backend should the error happen or not. If yes, then it’s the backends issue (bad data provided). If no, then it’s the frontends issue (the backend provided good data, but the frontend failed to expose it as expected).
This is no different than building and installing a wheel. If module x fails the import, it’s either the backends fault for not including the file into the wheel or the front-end fault for not extracting the wheel correctly. So there’s precedent on how to handle it. If this happens, users now report the bug to the frontend pip, not? And then you might need to conclude that their backend config is bad, so the issue is not with the frontend.
OK, I don’t think there’s much more we can usefully say here. As a pip maintainer, I feel that this PEP leaves me with more questions than answers, but if you can’t give me anything further I guess I have to accept that’s how the PEP intends things to be.
If a user complains that a non-editable installation is incomplete, how do you know whether it was the backend that failed to include the files in the wheel or the frontend which failed to install them? If the answer is, since the wheel format is established and the pip installer is battle-tested, we can assume the issue is with the backend, then no frontend-backed solution will be able to compete for editable-ness.
IMHO the same thing can be said about PEP-660 for backend writers. editables offers some answers but not the PEP itself, and my proposed frotend_editables would be the counterpart equivalent complement of this, currently, this lives right in my POC branch linked above. Granted, this PEP would put more emphasis on pip, so as a pip maintainer, you would likely not be thrilled by that.
This might be accurate with pip, but I don’t think it’s universally true for other frontends. But yeah, that being said give it a year or two and the frontend_editables will also be battle-tested… so fewer such issues will happen.
Finally, I’d like to comment that you can make this argument also between editables and the backend. If a backend adopts editables (as PEP-660 seems to encourage it, as a response to why should every backend implement editable on its own), and an editable install is not working, how do we know it’s the problem of the backend parametrizing editable or the editables library. Where should the user complain to? The editables library or the backend? The backend might just say, look I don’t do editables I just parameterized it, it’s not my problem; the same way the virtual wheel parametrizes the frontend.
With all that being said I’m not sure if there’s anything actionable here from the POV of PEP-662… This PEP shifts responsibilities to different locations than PEP-660, and seems some people are more comfortable with the responsibility being on the editables/backend/frontend part; depending on whether you’re maintaining a backend or frontend. So I think the PEP can be marked ready for judgment.
OK. I might not have time to review all of the discussion this weekend, but I’ll start the process of coming to a decision.
If anyone has any final comments on either of the two PEPs, please do speak up. I doubt that any decision here is going to satisfy everyone, so I’d like at least to be sure that everyone has had the opportunity for their voice to be heard.
I’m not arguing that prepare_metadata_for_build_wheel should not be invoked prior to building an editable wheel - what I’ve said is that passing its metadata to build_editable is very unlikely to matter. Though, on second thought, it is probably a good idea to keep the workflow between build_wheel and build_editable near-identical… Reusing prepare_metadata_for_build_wheel also more or less ensures that the backend will not be able to customise its metadata, including its dependencies, based on whether the wheel is editable. Therefore, it is even more surprising that there exists a separate get_requires_for_build_editable hook. Consider, for example, that @pf_moore’s editables functions both as a build and a runtime dependency.
Yeah, you’re right. I’ll extend the PEP to introduce prepare_metadata_for_build_editable as I’ve suggested on the PEP-660 topic too; and keep a symmetric design with how build wheel works.
Well, it certainly closes a gap - it doesn’t address the repeated concerns of how PEP 662 blurs the line between backend and frontend. It looks like that’s not going to change, so I’ll stop trying to argue that it should
Thanks to both the PEPs authors for their work - looking forward to a decision on editable installs finally being made.
As I said that’s on purpose, we don’t want in this PEP to tie the hands of the frontend too much; though the backend’s sole responsibility is to provide files for the frontend to expose. Everything else is up to the frontend.
