I'm still less concerned with this specific PEP and more concerned about the idea of taking a process that used to take years, was able to be condensed and improved and now slowing it back down to taking years again. We have no usage metrics for these kinds of experimental implementations and there doesn't seem to be a good way to get users to opt-in early and report on their experiences that would make some people on this list comfortable "finalizing". I think there's also a fundamental misunderstanding of how PEPs work in general and a desire to create something wholly different for Packaging which is becoming less and less of a PEP but still wanting to retain that "official" title.

On Wed, Jan 5, 2022 at 5:56 PM Bernat Gabor <gaborjbernat@gmail.com> wrote:
> based at least on the initial phrasing as it feels like it comes down to "either setuptools agrees or it doesn't happen for build backends" and that doesn't seem like the right way to go about standards, especially when so many other backends have implemented this and seem happy with the results

You are drawing conclusions I did not state.  Yes, that would be one way to get there, however not the only one. Another of the paths would be that people would start not using setuptools because they want PEP-660 and they would change to these many other backends, and themselves be happy about it. Or setuptools would add it to core, or setuptools-pep660 would be widely used by the community. We could get there in many ways. To draw a parallel with US laws, just because a few countries adopted something and they are happy with it it doesn't yet become a law everywhere; I believe for it to become a common-law it needs to be ratified and adopted by the majority of states first.

In my personal opinion, all packaging PEPs should start their life as provisional, and only be marked final once the majority of the users have used (e.g. 80% of packaging frontend/backend downloads have implemented that standard). There is precedent for this, as I see it, PEP-517 wasn't adopted once flit and scons implemented it. We waited until setuptools, poetry and a few new tools were implemented. And then observed in the wild for a year before we moved it to final. At that point, the majority of users had some interaction with it and they could voice their opinion and concern, and we did have a few PRs that made clarification as consequence. I think that was a good approach and I'd like to continue that. 

Things were clarified or were they changed fundamentally? I didn't follow 517's life-cycle and don't have a good way of finding the information you're referencing. If we're waiting on clarifications that seems to be quite inefficient. If we're looking for feedback that makes more fundamental impacts then that's a different topic altogether.

Correct me if I'm wrong, but PEPs once "final" can still be updated (look at the horrific history of PEP-0008 and the flip-flops in fundamental directions as well as clarifications). The "finality" of a PEP isn't quite as immutable as I think people are assuming it is. If we're worried about "this part is unclear and we want everyone implementing it on the same page" that's something that can be done after it's Final. If we're worried "This whole approach will have to change" then we can supersede this PEP with another or it should never have been provisional to start with.
 
As far as the vote goes per the voting goes, at the moment we are six for it and six against it. No one came back to say they changed their mind in either direction, so I personally don't think the topic hasn't been debated. 

I'll leave it to someone else to draw a conclusion on what's next for this topic. All the best,

Bernat


On Wed, Jan 5, 2022 at 10:59 PM Brett Cannon <brett@python.org> wrote:


On Tue, Dec 28, 2021 at 12:40 AM Pradyun Gedam <pradyunsg@gmail.com> wrote:
Bah, that got sent prematurely. I guess I shouldn’t type emails on an iPad.

At best, I feel putting this up for a “vote” either way is ridiculously premature — given that folks are elaborating their reasoning in long form in addition to their “vote”, and the fact that there seems to be a lack of discussion on this overall (and that this is being done during a holiday period).

I’d really we rather not make PyPA votes a “what proposal gathers more people behind it” tool. Do polls on discuss.python.org for that.

If that's the way to go we can discuss having a PyPA category or something where write access is restricted to members of this list It would be a manual process, but everyone could be added to a team on discuss.python.org for access control (and membership of this list doesn't change often enough to be a burden to keep it up).

-Brett

P.S. I'm +1 based at least on the initial phrasing as it feels like it comes down to "either setuptools agrees or it doesn't happen for build backends" and that doesn't seem like the right way to go about standards, especially when so many other backends have implemented this and seem happy with the results.
 

Of course, if this is what people want to use PyPA votes for, let’s have a discussion on discuss.python.org about it and then update our governance to reflect that.

I’m not happy that I’m being that guy who shouts “process” to stop things but we explicitly decided to have a discussion + delegate-decides for technical things and discussion + vote model for governance things. Let’s follow that.



On Tue, 28 Dec 2021 at 13:54, Pradyun Gedam <pradyunsg@gmail.com> wrote:


On Mon, 27 Dec 2021 at 16:50, Bernat Gabor <gaborjbernat@gmail.com> wrote:
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.


And, there’s an important missing reference that is very relevant here: https://www.pypa.io/en/latest/specifications/#provisional-acceptance

> 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


All the best,

Bernat
_______________________________________________
PyPA-Committers mailing list -- pypa-committers@python.org
To unsubscribe send an email to pypa-committers-leave@python.org
https://mail.python.org/mailman3/lists/pypa-committers.python.org/
Member address: pradyunsg@gmail.com
_______________________________________________
PyPA-Committers mailing list -- pypa-committers@python.org
To unsubscribe send an email to pypa-committers-leave@python.org
https://mail.python.org/mailman3/lists/pypa-committers.python.org/
Member address: brett@python.org
_______________________________________________
PyPA-Committers mailing list -- pypa-committers@python.org
To unsubscribe send an email to pypa-committers-leave@python.org
https://mail.python.org/mailman3/lists/pypa-committers.python.org/
Member address: graffatcolmingov@gmail.com