https://discuss.python.org/t/pep-660-editable-installs-for-pep-517-style-build-backends/8510/271?u=bernatgabor
Stéphane Bidoul raised the question of whether we should mark PEP-660 (editable installs) final now or not. Me and Paul Moore have differing opinions on this so we're calling a vote of the members.
- Reasons to mark it final as Stéphane said: PEP 660 has now been implemented in pip, flit, enscons, hatchling, pdm, poetry (merged by not released).
- Reasons why I think we should not mark it final: You’ll only find out what gaps the standard has once it’s widely used. IMHO enough is not a few backends that are overall not that often used adopts it. But enough should be when the majority of the projects using it adopt it (e.g. 80% of projects). Now I can see this by either setuptools implementing it or people moving away from using setuptools in time. Most projects that currently implement the standard don’t provide a generic build framework, as setuptools does, but instead only a subset so they don’t necessarily expose the current standards potential issues (think e.g. flit is restricting itself currently to purely toml configuration driven and avoids having a build step).
I'll start the voting, from my side it's -1, aka keep it provisional for now.
I’m not sure this is a thing that fits a PyPA committer vote, at least, as our governance currently defines things.
> PyPA has its own variant of the standard library’s provisional modules, which is provisional interoperability specifications.
> These are specifications which have been accepted for implementation in the core packaging tools (PyPI, pip, etc), but are still considered subject to potentially backwards incompatible amendments if real world experience indicates that there are critical problems in the interface design that make it hard to implement and/or use correctly.
> When a PEP has only been provisionally accepted, this will be noted using the Provisional status in the PEP header - it will then be marked as Final after successful rollout and initial adoption of the reference implementation.
PEP 411 (which was referenced in the discussions) is about the standard library modules, not the provisional state in general. What provisional means in the context of Python packaging is somewhat different because we don’t have a single blessed backend.
Best,
Pradyun