New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve IDLE news handling #61708
Comments
Idle news items should be collected together in one place and released both in an IDLE section of each Misc/NEWS and in each idlelib/NEWS.txt. Once a decision is made where to collect them originally, a script should be written to make appropriate copies. If someone volunteers, scattered entries in current Misc/NEWS could be collected together. |
I think it would be better to keep everything in an IDLE section in Misc/NEWS, and have something/someone extract the section(s) before the release. In Lib/idlelib/NEWS.txt we probably don't need to have separate sections for alphas/betas/rcs like we do in Misc/NEWS. |
This is related to bpo-17221. I agree that news items need to be consolidated in both Misc/NEWS and Lib/idlelib/NEWS.txt. |
Setting bpo-17221 as a dependency. Once that is fixed it would be good to keep IDLE entries in Misc/NEWS, and copy them in Lib/idlelib/NEWS.txt before the release. |
I put 1 or 2 items in idlelib/NEWS, but it does not really matter which way they go. I guess the greater separation in Misc/NEWS says they should go there first, as moving to idlelib would delete reliease info. I will move the one item over sometime, maybe after the big patch. |
New changeset aa059a8fb55a by Terry Jan Reedy in branch '2.7': |
The items in Misc/NEWS and idlelib/NEWS.text were mostly disjoint. |
To minimize news merge headaches, I have been pushing news items separately from IDLE patches, usually in batches of at least two. It has not been too much bother to copy from NEWS.txt to NEWS. If and when news handling is automated, I will request that items directed at the IDLE section also go to NEWS.txt. |
Separate news items are now consolidated during the release process. But two issue with copying them. 1. They are not line wrapped, whereas news.txt is. 2. I don't always make (or keep) entries identical. |
A suggestion: rather than trying to maintain a separate IDLE news file ("don't repeat yourself), it might be much easier to link to the IDLE section in each releases's formatted CHANGELOG now included in Python 3 docsets. For example: https://docs.python.org/3/whatsnew/changelog.html#idle Yes, users would have to scroll down to each release's IDLE section but I suspect that wouldn't be a huge burden considering how infrequently change files are consulted. To be even more useful, IDLE could first attempt to find the changelog in the Python installer's bundled copy of the docset like the F1 key does. For example, with the macOS installer, the corresponding file URL is: file:///Library/Frameworks/Python.framework/Versions/3.8/Resources/English.lproj/Documentation/whatsnew/changelog.html#idle |
On Windows, the .chm help file is no longer bundled by default. For me, F1 opens the python.org page. The changelog has a section for each release, including alpha, beta, and candidate releases. Trying to find everything new in 3.11, say, will require looking for an IDLE subsection in over 10 sections. What I would like is to prepend IDLE items for each new release to NEWS.txt as the changelog is rebuild. If and when I care enough, I may try to write a script. File whatsnew/changlog.rst has this line: |
|
Thank you. The function release loops through new blurb files, calling load_next on each. That parses the metadata and adds to list. At that point, it should be possible to call that add blurbs of type 'idle' to a separate list. Sometime after that, call another function that adds IDLE to idlelib/NEWS.txt. An issue is that this is a checked-in file so it has to be done 'right'. Also protect against files being scanned twice, if that is possible. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: