-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Add support for topic indices #2579
Conversation
The following commit authors need to sign the Contributor License Agreement: |
Odd the CLA bot pinged up again -- were CLA signing statuses not migrated from the 'old' model? That's the only thing I can think of that might be causing it to not like me. A |
@pradyunsg for feedback on the packaging side -- I'd appreciate views. Would a simpler page just with a numerical index suffice? Are the categorisations useful? A |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for working on this!
@@ -0,0 +1,50 @@ | |||
"""Utilities to support sub-indices for PEPs.""" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The filename is misspelled (subindicies -> subindices)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perils of typing past midnight! Thanks for noticing.
A
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also in function/variable names in this file.
And it would be clearer to use the same naming as the display URL, so topics
instead of subindices
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And it would be clearer to use the same naming as the display URL, so topics instead of subindices
The one issue with that, though, is that it can quite easily be extended to generate subindicies filtered on other headers than Topic
, e.g. Type
, Status
, a future such field or potentially something else; the code isn't topic-specific.
The preview is live at https://pep-previews--2579.org.readthedocs.build/topic/packaging/. It's missing links. |
Yep, I just realised the PEP 0 transforms add the links later. In principle there's no reason we can't add said links during the PEP 0 creation process, I'll make that change when I go through the next round of updates. A |
The same is true of the email address obfuscation, BTW, and the Page Source link. |
I figure you're also aware of the issue that the index by category is not being generated at all on the main PEP 0 (while it is on the Packaging sub-index)? Also, its currently impossible to find the topic-specific indices as nothing links to them. I assume you're already aware of this, but to address it, I suggest a "Index by topic" heading immediately below the introduction with a generated list of links to each topic, something like the following: Indices by TopicView sub-indices containing just PEPs belonging to specialized topic areas. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for doing this. A handful of comments on the code as it stands now; some minor and some more substantive.
I can add it to the linters and PEP 1/12/template in a separate PR, if desired.
if (len(file_path.stem) == 8 | ||
and file_path.stem.startswith("pep-") | ||
and file_path.suffix in {".txt", ".rst"}): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How come the matching logic was downgraded to be less precise and correct than before, yet longer/more complex? Previously, only actual PEPs following the prescribed pattern (pep-\d{4}\.(txt|rst)
) were matched, while this matches any 8-character txt
or rst
file that starts with pep-
.
out_dir = Path(app.outdir) / "api" | ||
out_dir.mkdir(exist_ok=True) | ||
Path(out_dir, "peps.json").write_text(pep0_json, encoding="utf-8") | ||
Path(app.outdir, "peps.json").write_text(create_pep_json(peps), encoding="utf-8") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The previous JSON API path logic was inexplicably removed here, and the peps.json
is now no longer generated at the correct path.
pep_sphinx_extensions/pep_zero_generator/pep_index_generator.py
Outdated
Show resolved
Hide resolved
Yes but now it's checking by email address. If you committed with a Can you do the CLA thing with that address too? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
https://pep-previews--2579.org.readthedocs.build/topic/packaging/ is the new index.
https://pep-previews--2579.org.readthedocs.build/topic/ is a 404, shall we generate a simple list of topics?
@@ -0,0 +1,50 @@ | |||
"""Utilities to support sub-indices for PEPs.""" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also in function/variable names in this file.
And it would be clearer to use the same naming as the display URL, so topics
instead of subindices
Thanks for picking this up and turning this around so quickly @AA-Turner! ^>^
I think a numerical index would be significantly less useful than the (as-currently-implemented) categorised index. :) The categorisation makes it much more obvious what the state of every PEP is, what's "in-flight" and what each status means has something that has been slightly frustrating to communicate -- this communicates that very clearly. Just looking at this index has flagged a few minor things, that I'll follow up on separately (like a few of the "old" Informational PEPs should really be Standards Track and Final + PEP 609's title is 50% acronym which isn't great). Beyond that, I have a few more bits of feedback/additional requests. We can defer these to separate follow ups, if any of these are along the lines of "we should discuss this in a broader context" or "this is complicated to implement". :)
/cc @pfmoore and @dstufft as the standing PEP delegates, in case they have inputs. |
Yeah, we could add a toctree directive in the generated source file (or do it in a transform, etc).
Somehow, I missed this, but I agree with @pradyunsg —currently, due to what I presume is a logic bug (with suggested fix above), this PR actually does the opposite, it no longer generates the categories at all for the main PEP 0 index, only the subindicies.
This might be helpful, but it requires some special-casing for the Packaging
That makes sense; currently, the ordering is perhaps a bit haphazard.
Yes, but how does this scale with additional topics? If it was only for PEP 0, or perhaps even a single topic page I'd agree, but single-sourcing the topic names (and descriptions, if necessary) in one data structure and then generating them all via one consistent code path seems a lot simpler, cleaner and DRYer than manually hardcoding a bunch of duplicative rst files with the same structure and boilerplate for the index and each subindex, not to mention harder to maintain. Adding a new topic would require creating a whole new file with the right structure, content and directives, plus manually adding it to the index, rather than just adding a name and description in a common data structure; updating something in the format/structure requires changing the same thing many different places, versus just a few lines of code. And meanwhile, we'd still have to draw the line somewhere in terms of generated versus baked-in content. |
That's the least disruptive way to implement this, I think. I'm gonna leave out my response to @CAM-Gerlach's comments on the directives suggestion I've made -- I'd prefer to not flood this PR with discussion in a not-critical-path refactoring suggestion. :) |
The CLA website is also reporting an internal server error with the link on this PR... A |
https://pep-previews--2579.org.readthedocs.build/topic/packaging/ @pradyunsg how's the additional description? On your other points:
I didn't have time today to update the PEP 0 transforms, though. A |
Actually, for the record, the solution he proposed was much more of a "native" reST approach and easier to discover, as it uses a reST directive and normal rst source files rather than generating the source files in arbitrary Python code and manually adding them to the files to be built, burying the source text within the code and spread between several different places. After looking over a more detailed version of his proposal, I think its actually pretty workable with only a small amount of static duplication, but can be left for a separate future PR. |
By this I mean directives as specified in the reStructuredText specification -- having custom unrecognised directives isn't very useful to e.g. the GitHub UI, which uses Docutils (or a reimplementation of it). I'll stop before I drift further off topic, though. A |
The stated purpose of directives are to be an extension mechanism for reST without having to go outside of it by using manual hacks like this. Quoting the first line of the official reST specification defining directives:
Yes, they aren't a first-party directive understood by the reference parser (docutils), but neither are Sphinx extensions, nor our custom
I'm a little confused how arbitrary custom Python code that generates files from scratch that don't even exist at all in the source is more compatible with GitHub and other consumers (never mind the same is true for any other Sphinx extension, not to mention all the other custom roles, transforms, output translations, theme HTML/CSS/JS, and everything else we have)? 🤣 |
https://pep-previews--2579.org.readthedocs.build/topic? A |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a link from pep-previews--2579.org.readthedocs.build to the topics?
Do we need one from https://pep-previews--2579.org.readthedocs.build/ to https://pep-previews--2579.org.readthedocs.build/topic/ ? I don't remember if this came up already :)
Not particularly important, can always add it later if needed.
Thank you all for this, approved!
Would be good for @pradyunsg to have a quick check too.
Hi there, I temporarily added DO-NOT-MERGE as I need this open to squash the CLA email problem. |
python/cpython#93736 passed the CLA check... |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me!
Thanks for waiting on my inputs and addressing my earlier feedback! :)
@ambv could you use a different PR by @AA-Turner to figure out the CLA issue? I'd like to get this PR in because it'll help the packaging people and it's been waiting for a long time already. |
This needs a closes #2572 in the PR description. :) |
@AA-Turner could you merge or rebase this, such that the changes in #2636 is included in the PR preview on this PR? |
Whee! Thanks everyone for helping get this implemented, polished and over the line! ✨ |
* main: (47 commits) PEP 668: Address feedback and mark as accepted (python#2673) PEP-0691 Gramatical changes + `meta` key description under Project List (python#2677) PEP691: Mark Accepted + Grammar Fixes + Small Fix (python#2674) PEP 691: touch up (python#2668) PEP 650: Withdraw and move to Standards Track (python#2665) PEP 561: Mark as final (python#2663) PEP 660: Mark as Final (python#2664) PEP 615: Fix incorrect RFC link (python#2662) Multiple PEPs: Move Packaging PEPs to Standards Track and mark as Final (python#2657) PEP 671: Since it keeps getting asked about, add a para on deferreds (python#2661) Infra: Tweak PEP references to work on topic sub-index pages (python#2658) PEP 632: Remove `Topic: Packaging` header (python#2656) Infra: Make colour theme cycler button accessible (python#2619) PEP 593: Fix citation references (python#2640) PEP 553: Fix citation references (python#2639) PEP 668: Add PEP-Delegate (python#2654) PEP 693: Python 3.12 Release Schedule (python#2648) Add support for topic indices (python#2579) PEP691: Switch to a List for Project, Address more Feedback (python#2653) PEP 671: Add section on evaluation order (python#2652) ...
Draft, as a proof of concept to show the rendered preview.
I'm going to seperate the PEP changes into a distinct PR from the rendering infastructure changes, but I included them here so as to trigger the sub-index generation.
I haven't updated the tests or anything so they'll likely fail.
Rendered packaging sub-index preview:
https://pep-previews--2579.org.readthedocs.build/topic/packaging/
A