This I can totally do. For all of the context and motivation can I refer to 639 or should I copy some stuff over?
Personally, Iâm fine if PEP 639 gets referenced if you think what it currently says makes sense. Otherwise Iâm also fine with copying with attribution back to PEP 639.
Sorry for the delay in replying; I meant to respond two weeks ago, but right around the time this was posted my poor cat got very sick and Iâve had to constantly care for him, and I had a number of urgent projects to complete for Spyder.
To update everyone, after several rounds of detailed discussion getting @sethmlarson and @ksurma on board, familiarizing them with the PEP and drafting a work plan to get this done, Karolina took the first month to read and get familiar with the PEP in detail, while Seth later ended up stepping back to an advisory role due to other commitments and Karolina seeming to have things well under control.
After some back and forth questions and discussions, she developed a solid plan for revising, cutting down and greatly simplifying the PEP, and then begun drafting PRs in separate branches to pull out/remove non-essential sections from the PEP as well as the previous migration guidance from the spec [1], and greatly simplify and clarify the remaining language, respectively, after which we went back and forth at a regular pace with several rounds of questions and reviews of her drafts to get them ready to merge. As she merged my latest changes into her own branch, I was going to propose that she just submit that directly as part of her PR to avoid any further blockage and my end, and we could iterate from there.
However, after answering her latest questions and making some additional suggestions, I havenât heard back for about a month, so Iâm not sure what the status is on her endâhopefully everythingâs all right; Iâve reached out again to check.
See my most recent post just above for a list of the main items; we have a more detailed work plans in our PEP 639 working group, which I can also share here (or just add you there). Iâd be more than happy to add you as a PEP author and help spin you up and drive this forward; it would be extremely valuable to have a tool author whoâs implemented this in practice on board, particularly since one of the two main action items listed there is simplifying, updating and refining the specification to reflect what is practical for tools to implement in practice:
The second main work item, cutting down and simplifying the PEP text and moving out all the non-essential sections, is what Karolinaâs been focusing on and made a lot of progress with; hopefully she can pick that up and finish it, or if not either you or I can at least finish tackling the low-hanging fruit, polishing that up and submitting it as-is for now.
Finally, the third item is just a handful of relatively minor, atomic updates that I (or you, or others) can easily make as small PRs.
Particularly if Karolinaâs still up for it, ISTM that gives us a workable plan with clear division of responsibilities to each of our strengths while also having a fallback plan for each if any one of us (particularly myself or Karolina) should prove unable to follow through.
The latest plans and drafts for PEP 639 seem to be converging on basically what you are looking for, with either a dramatically simplified or else mostly untouched Motivation, Rationale, etc., all the non-essential sections moved out of the PEP, and simplifying the specification based on whatâs actually practical for implementations, and thereâs been quite a bit of existing discussion, planning and work toward that end already.
Therefore, ISTM it makes more sense to just invite Ofek as an author and have him apply his specification updates, simplifications and revisions directly to the PEP. Additionally, together we would finish/merge the nearly-complete PR moving the various non-essential sections and appendices out of the PEP entirely, and either finish or merge as-is (if Karolina is unavailable) the branch that substantially simplifies and cuts down the motivation, rationale, etc. required sections. Combined with a handful of other minor updates, that gets us to the desired end state without having to hack something new together from scratch or abandoning all the existing years of work on the PEP and that already done to take it in the direction youâre looking for.
If youâre okay with it, @ofek I can add you to the PEP 639 working group right now and you can start getting up to speed, going through the specification and figuring out what needs simplifying, and reviewing the status of the other remaining bits. Just lmk!
it was something I inherited, and kept wanting to move to an informational appendix instead of clogging the spec with it âŠď¸
1 Like
That sounds like it would take more time than I have unfortunately. I wouldnât be able to thoroughly read the current version to know how to simplify (and simplifying often takes more time than the main writing).
What I can do is more or less reiterate the current technical specification and show that Hatchling does it completely and setuptools has a partial implementation.
Let me know how you and Brett want me to proceed.
Okay, gotcha. Just to be clear, I wasnât expecting you to need to help simplify anything but the actual technical specification [1], and that can be as simple as just taking the existing spec and deleting the parts you didnât actually implement or that are overly complicated, and making any other updates/changes based on implementation experience. Or, if youâd rather just clean-sheet rewrite a spec from scratch based on your implementation, we could just integrate that (or worst comes to worst, just stick it directly in the PEP, merge the rest and call it a day). The rest is mostly either already simplified/removed from the PEP in the latest drafts (cutting it down to only a third its prior length), or not essential to change.
Just to note, PEP 639 covers this near the top:
While dramatically simplifying and improving the present Python license metadata story, this specification standardizes and builds upon existing practice in the Setuptools and Wheel projects. Furthermore, an up-to-date version of the current draft of this PEP is already successfully implemented in the popular PyPA Hatch packaging tool, and an earlier draft of the license files portion is implemented in Setuptools.
minus the whole âconversionâ section, which the latest drafts (linked above) completely removes from the PEP, along with the other non-essential sections which together comprise around 2/3rds of its total length âŠď¸
Oh thatâs fine then, sure add me to whatever.
1 Like
So quick update with good newsâ@ksurma got back to me to let us know sheâd been busy preparing for and going on a major international trip, and should be back and working again on the PEP next Monday, and plans to have her section by section rewrite to simplify and cut down the PEP finished by the end of the month.
In the meantime, this week to (finallyâŚ) finish the most important glossary changes (or worst comes to worst, move ahead with it as is), and as time allows help complete and merge Karolinaâs branch removing non-essential sections from the PEP (and referencing them instead where relevant for interested readers) so she can focus on finishing the rewrite once she gets back.
Thanks; sent you a friend request so I can add you 
4 Likes