-1 i share the sentiment, until its in wide use (and say for me personally im using it for pytest or work) -- Ronny Am 27.12.21 um 12:20 schrieb Bernat Gabor:

https://discuss.python.org/t/pep-660-editable-installs-for-pep-517-style-bui...

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.

All the best,

Bernat

_______________________________________________ PyPA-Committers mailing list --pypa-committers@python.org To unsubscribe send an email topypa-committers-leave@python.org https://mail.python.org/mailman3/lists/pypa-committers.python.org/ Member address:opensource@ronnypfannschmidt.de

+1 from me. My intention when marking the PEP as provisional was never to block on its inclusion in setuptools, but to ensure that some *other* build backends had implemented the PEP successfully, and this has now happened. Paul On Mon, 27 Dec 2021 at 11:20, Bernat Gabor wrote:

https://discuss.python.org/t/pep-660-editable-installs-for-pep-517-style-bui...

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.

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: p.f.moore@gmail.com

-1 from me. I hope it gets there, but it seems unrealistic to call it 'final' when the most widely used and de-facto standard backend hasn't implemented it yet. On Mon, 27 Dec 2021, at 13:50, Paul Ganssle wrote:

-1 from me. I don't think it should have been accepted in the first place.

On December 27, 2021 12:01:17 PM UTC, Paul Moore wrote:

...

+1 from me. My intention when marking the PEP as provisional was never to block on its inclusion in setuptools, but to ensure that some *other* build backends had implemented the PEP successfully, and this has now happened.

Paul

On Mon, 27 Dec 2021 at 11:20, Bernat Gabor wrote:

...

https://discuss.python.org/t/pep-660-editable-installs-for-pep-517-style-bui...

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.

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: p.f.moore@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: python@ml.ganssle.io

---

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: thomas@kluyver.me.uk

I'm +1 because of Bernat's own reasoning: "*But enough should be...*" either "enough" isn't defined already or it's defined in a way that some folks disagree with. PEPs have never had their acceptance conditioned on wide-spread adoption of the PEP before it's Finalized. Yes, packaging PEPs could work differently, but then that begs the question "Why must they be different?" or "Why can't we write a new PEP that better explains the reasoning for the changes necessary once we know they're necessary?" The other half here is that these other implementations have already done significant work against this PEP. To then shift it under their feet is going to suck. Just because one juggernaut/de facto implementation hasn't mobilized the way the smaller projects did doesn't mean we should penalize people for providing their users areas to experiment. Does setuptools have enough metrics for us to know when "enough" time has passed that we feel people *might* have used this once released? When will enough be enough? The current argument against finalizing this and special-snowflaking PEPs here is a slope which leads to stagnation, a lack of action, and confusion. "What is the status of that thing we implemented 5 years ago? Is it still not final? Can we just rip it out? It's causing us headaches and no one seems to use it and it's not a real pep anyway." On Mon, Dec 27, 2021 at 8:38 AM Jason R. Coombs wrote:

-1

I’d very much like to see the Setuptools implementation land and get some feedback from the community to identify and crucial gaps.

Sent from my comm

On Dec 27, 2021, at 08:57, Thomas Kluyver wrote:

 -1 from me. I hope it gets there, but it seems unrealistic to call it 'final' when the most widely used and de-facto standard backend hasn't implemented it yet.

On Mon, 27 Dec 2021, at 13:50, Paul Ganssle wrote:

-1 from me. I don't think it should have been accepted in the first place.

On December 27, 2021 12:01:17 PM UTC, Paul Moore wrote:

+1 from me. My intention when marking the PEP as provisional was never to block on its inclusion in setuptools, but to ensure that some *other* build backends had implemented the PEP successfully, and this has now happened.

Paul

On Mon, 27 Dec 2021 at 11:20, Bernat Gabor wrote:

https://discuss.python.org/t/pep-660-editable-installs-for-pep-517-style-bui...

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.

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: p.f.moore@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: python@ml.ganssle.io

_______________________________________________ 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: thomas@kluyver.me.uk

_______________________________________________ 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: jaraco@jaraco.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: graffatcolmingov@gmail.com

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. 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 wrote:

On Mon, 27 Dec 2021 at 16:50, Bernat Gabor wrote:

...

https://discuss.python.org/t/pep-660-editable-installs-for-pep-517-style-bui...

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.

https://www.python.org/dev/peps/pep-0609/#pypa-committer-votes

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

Hi, I get that this seems to be a controversial topic, but IMHO the fact that it is (and the current vote count shows that) tells me that it's probably not time to mark it final just yet. For reference, both the flit and the setuptools maintainers object against it. That being said I'm done discussing this any further. I get that we have differing opinions and I'm willing to accept that. I've called the vote because I've agreed with Paul that we will not reach an agreement, and instead of bikeshedding our arguments any further let democracy do its job (and the arguments people tried to raise after did not change my mind either). Happy new year to everyone, Bernat On Tue, Dec 28, 2021 at 9:53 AM Paul Moore wrote:

On Tue, 28 Dec 2021 at 08:40, Pradyun Gedam wrote:

...

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).

To be honest, I agree. My comment on Discourse was "A PyPA vote is probably the nearest equivalent for packaging, so if we can’t reach consensus, I suggest someone puts it to a PyPA vote". We certainly made no attempt to get consensus on Discourse before Bernát started the vote here. If I felt that the decision mattered that much, I'd have objected myself - but to be honest, I think moving to Final is little more than a formality at this stage, it's not as if we're going to approve incompatible changes which would break all of the projects Stéphane mentioned on Discourse.

Frankly, I'm now convinced that Provisional status for packaging PEPs (at least the interoperability ones) is unworkable, for basically the reasons stated by Ian, and personally, I will definitely *not* be approving any new PEPs as Provisional. If they don't make the case to be Final from the start, they can be rejected or sent back for revision before acceptance. (Obviously, other PEP delegates can take whatever view they prefer).

...

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.

Thanks for being that person, nevertheless. I'm sick of being the one who refers to process all the time myself, so it's good to have someone else help out :-)

Paul.

+1 On Tue, Dec 28, 2021, at 9:06 AM, Daniel Holth wrote:

This pep has been implemented for setuptools and can be used as a plugin, like wheel. It just hasn't been merged into setuptools. If the maintainer isn't happier about the pep then I don't see how it could be merged. _______________________________________________ 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: dholth@fastmail.fm

On Mon, Dec 27, 2021 at 11:20:23AM +0000, Bernat Gabor wrote:

https://discuss.python.org/t/pep-660-editable-installs-for-pep-517-style-bui... [snip]

I'll start the voting, from my side it's -1, aka keep it provisional for now.

I (explicitly) abstain from this vote. - e

Hmm, I certainly never intended to come across that way. Personally, I've voted on this issue, and I don't want my vote to be taken as anything more than one of many. When we're conducting a PyPA vote, that's how it works, and is how things should work. It is a democratic process. I do think the vote was premature. That's a purely personal feeling, and I didn't mention it until someone else (Pradyun) said the same. At which point I agreed. But it's still a personal expression of an opinion. Maybe out of place on a voting thread, but so is a lot of what's getting said here (which is *why* I think more discussion should have taken place on Discourse before the vote). But whatever, you can ignore my opinion, I have no special authority in PyPA governance matters. The point I made about provisional status was a comment on how I'd act when I'm acting as PEP delegate. And that's *not* a democratic process. Quite the opposite, it's a case of one person having final authority (as in the original term, BDFL). It's completely democratic who gets to *be* PEP delegate (any PyPA committer can volunteer) but I am the choice if no-one does (by appointment of the SC, for what it's worth). So I feel that my view on the usefulness of provisional status for PEPs (as informed by what happened here) might be helpful for people to know. Even if only to encourage people who disagree with my view to be more willing to volunteer for the role themselves. Again, off topic, and so I won't say any more on the matter here. If there's anything else I've said that implies I feel that I have more power than other PyPA members in a vote, then please point it out. I'll either explain what I meant, or if I was in the wrong, I'll retract what I said, apologise, and correct my behaviour in future. The whole PEP 660 business was extremely stressful for me at the time. My apologies if I'm now failing to be sufficiently objective as a result of the fallout from it. Paul PS My comment about referring to process was intended completely seriously. The PyPA does have agreed and documented processes, but a lot of the time, we don't seem to follow them very closely, preferring to keep things informal. I seem to have ended up frequently pointing people at the process docs, which is not a role I like or want. That may be my own fault, and maybe I should just stop. But I would be *extremely* happy if someone took on the role of making sure we follow our own processes correctly. I really don't want to be that person, though. On Tue, 28 Dec 2021 at 20:18, Ian Stapleton Cordasco wrote:

Just to be clear, this sounds like "two people have more powerful votes than the rest of the democracy".

Sent from my phone with my typo-happy thumbs. Please excuse my brevity

On Tue, Dec 28, 2021, 04:02 Bernat Gabor wrote:

...

Hi,

I get that this seems to be a controversial topic, but IMHO the fact that it is (and the current vote count shows that) tells me that it's probably not time to mark it final just yet. For reference, both the flit and the setuptools maintainers object against it. That being said I'm done discussing this any further. I get that we have differing opinions and I'm willing to accept that. I've called the vote because I've agreed with Paul that we will not reach an agreement, and instead of bikeshedding our arguments any further let democracy do its job (and the arguments people tried to raise after did not change my mind either). Happy new year to everyone,

Bernat

On Tue, Dec 28, 2021 at 9:53 AM Paul Moore wrote:

...

On Tue, 28 Dec 2021 at 08:40, Pradyun Gedam wrote:

...

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).

To be honest, I agree. My comment on Discourse was "A PyPA vote is probably the nearest equivalent for packaging, so if we can’t reach consensus, I suggest someone puts it to a PyPA vote". We certainly made no attempt to get consensus on Discourse before Bernát started the vote here. If I felt that the decision mattered that much, I'd have objected myself - but to be honest, I think moving to Final is little more than a formality at this stage, it's not as if we're going to approve incompatible changes which would break all of the projects Stéphane mentioned on Discourse.

Frankly, I'm now convinced that Provisional status for packaging PEPs (at least the interoperability ones) is unworkable, for basically the reasons stated by Ian, and personally, I will definitely *not* be approving any new PEPs as Provisional. If they don't make the case to be Final from the start, they can be rejected or sent back for revision before acceptance. (Obviously, other PEP delegates can take whatever view they prefer).

...

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.

Thanks for being that person, nevertheless. I'm sick of being the one who refers to process all the time myself, so it's good to have someone else help out :-)

Paul.

_______________________________________________ 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

Hi Ian, I think you've jumped the gun making that conclusion. I never implied that the voice of two is more important. I just said that some people who are probably the most heavier impacted by this PEP do still have some reservations. That being I did finish with let democracy do its magic, which I'll reiterate. IMHO whatever the outcome of the vote is, I'll accept it, just as I always did in the past.

That was a response to Bernat about Bernat's response, not to you Paul. I agree with the discussions and categorizations of the proper process and procedure though.

Adding this comment here because people wanting to see setuptools support may not be aware. The blocker on setuptools support is not actually any difficulty in implementing PEP 660, but rather because setuptools want to find a new means of implementing editable installs, which would remove some of the flaws of the `.pth` based approach. While that's a fair thing to attempt, it's unrelated to PEP 660 - they would have just as much problem implementing a better scheme for `setup.py develop`. So if people want to wait for setuptools, and that's the way the vote goes, then we won't be waiting on anything directly related to whether PEP 660 is able to handle current techniques for editable installs, but rather for an as-yet unknown "better editable mode". Again, that's fine, and if that's the way the vote goes, I have no problem with it. But I think the background is important here (and I for one hadn't realised what the blocker was). See https://github.com/pypa/setuptools/pull/2872#issuecomment-1002393711 for the context. Paul On Wed, 29 Dec 2021 at 09:06, Alex Grönholm via PyPA-Committers wrote:

-1; I would also like to see the setuptools implementation in action first.

Jason R. Coombs kirjoitti 27.12.2021 klo 16.37:

-1

I’d very much like to see the Setuptools implementation land and get some feedback from the community to identify and crucial gaps.

Sent from my comm

On Dec 27, 2021, at 08:57, Thomas Kluyver wrote:

 -1 from me. I hope it gets there, but it seems unrealistic to call it 'final' when the most widely used and de-facto standard backend hasn't implemented it yet.

On Mon, 27 Dec 2021, at 13:50, Paul Ganssle wrote:

-1 from me. I don't think it should have been accepted in the first place.

On December 27, 2021 12:01:17 PM UTC, Paul Moore wrote:

+1 from me. My intention when marking the PEP as provisional was never to block on its inclusion in setuptools, but to ensure that some *other* build backends had implemented the PEP successfully, and this has now happened.

Paul

On Mon, 27 Dec 2021 at 11:20, Bernat Gabor wrote:

https://discuss.python.org/t/pep-660-editable-installs-for-pep-517-style-bui...

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.

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: p.f.moore@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: python@ml.ganssle.io

_______________________________________________ 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: thomas@kluyver.me.uk

_______________________________________________ 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: jaraco@jaraco.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: alex.gronholm@nextday.fi

_______________________________________________ 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: p.f.moore@gmail.com

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. 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 wrote:

On Tue, Dec 28, 2021 at 12:40 AM Pradyun Gedam 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 wrote:

...

On Mon, 27 Dec 2021 at 16:50, Bernat Gabor wrote:

...

https://discuss.python.org/t/pep-660-editable-installs-for-pep-517-style-bui...

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.

https://www.python.org/dev/peps/pep-0609/#pypa-committer-votes

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

On Thu, 6 Jan 2022 at 13:29, Ian Stapleton Cordasco wrote:

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.

See https://www.pypa.io/en/latest/specifications/ for the documented and agreed process which PyPA specifications follow. It uses the PEP process, but has some differences from the core Python process. But yes, this debate does seem to be mostly moving towards making standardisation take longer, which is not something I personally want. I don't know about other projects (although I'm pretty sure this applies to setuptools as well) but pip is struggling under the need to endlessly support legacy mechanisms. A faster standardisation cycle is a major benefit to pip, and not one I want to give up lightly. It causes us initial pain as we have to implement the various new standards, but shorter timescales lets us drop older approaches sooner, which offsets the short term pain.

On Wed, Jan 5, 2022 at 5:56 PM Bernat Gabor wrote:

...

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.

There were *three* changes made to PEP 517. See https://www.python.org/dev/peps/pep-0517/#summary-of-changes-to-pep-517. Two were essentially clarifications[^1], one was adding support for in-tree backends. The in-tree backend change could just as easily have been done as a follow-up PEP extending PEP 517. None of them needed PEP 517 to be provisional, IMO. Whether things would have been different if PEP 517 *had* been found deficient, I don't know. But it wasn't, so it's a stretch to draw the conclusion that leaving it provisional for so long added any real value.

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.

If you're talking about core Python PEPs, they shouldn't be (informational PEPs may be somewhat different). But according to the PyPA process, packaging standards PEPs should actually be definitions of a specification which then gets documented at https://packaging.python.org/en/latest/specifications/. It's then that document which is the "living spec", and it can be modified by follow-up PEPs as needed. The original PEP itself should no longer be the reference spec. Although we aren't very good at following that process - in particular, PEP 660 hasn't been transferred to there yet. (And before anyone asks, no the process doesn't say that this should only happen when a PEP is marked final). Here's the documentation of the PyPA specification process: https://www.pypa.io/en/latest/specifications/ But your key point is correct - provisional status isn't needed for most of the common things we'd need to do with a spec after it's been approved. The only value I can see in provisional status is to allow us to deliberately change an interoperability standard that is currently in use "in the wild", **without bothering to maintain backward compatibility**. That seems to me like an extremely user-hostile thing to do, and I'd be strongly against it even for a provisional PEP where it's technically allowed. I'd always push for such a change to be made in a backward compatible manner, and honestly I don't see why that wouldn't be possible.

...

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,

You can read the process in PEP 609, at https://www.python.org/dev/peps/pep-0609/#pypa-committer-votes, "If at least two thirds of recorded votes are +1, then the vote succeeds". The vote has now been open for (more than) 7 days, so it's failed. I'm assuming that at this point we have formally closed the vote, although I don't think you've actually done that yet. As the stated vote was "+1 to mark PEP 660 Final", I have to conclude that the result is that we *don't* mark PEP 660 as final at this point. For what that's worth - unlike you, I view provisional status as relatively meaningless for packaging PEPs. Note that the voting process is purely "yes/no", so this vote doesn't establish any criteria for when PEP 660 should be made final. In fact, it appears that we don't actually have a workable process to determine how a provisional PEP gets marked as final (at least not one that works in this case). From the process document:

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.

But what's the "reference implementation" in this case? There isn't a single one - there's one for pip (implemented), one for flit (implemented), one for setuptools (setuptools-pep660 - implemented), etc. And the process only says "initial adoption" anyway, not "the majority of users have used it". But clearly people differ in their opinions on what counts as "the reference implementation" and/or what "successful rollout and initial adoption" of that implementation means. So I don't see how we mark the PEP as final, other than either (1) the PEP delegate for the PEP (me) making an executive decision, or (2) we keep having votes until one passes. I'm not comfortable with the first option, as it'll only fuel complaints that I have some sort of agenda here. But endless voting doesn't seem either reasonable or fair, either. To be honest, I'm willing to accept some of the blame for this whole mess. I thought once the PEP was approved, we'd just leave it to projects to get on with rolling it out, and move onto other things. I should have thought things through a bit further and simply accepted PEP 660 as final in the first place. I'll know better in future :-( Personally I intend to ignore the issue for now. Let's just leave the PEP as provisional and carry on as we were. Paul [^1]: Ironically, one of those clarifications (the "no cycles" one) is now causing some debates and may have been better left as it originally was :-(