Skip to content
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

Merged
merged 15 commits into from
Jun 18, 2022
Merged

Add support for topic indices #2579

merged 15 commits into from
Jun 18, 2022

Conversation

AA-Turner
Copy link
Member

@AA-Turner AA-Turner commented May 5, 2022

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

@cpython-cla-bot
Copy link

cpython-cla-bot bot commented May 5, 2022

The following commit authors need to sign the Contributor License Agreement:

Click the button to sign:
CLA not signed

@AA-Turner
Copy link
Member Author

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

@AA-Turner
Copy link
Member Author

@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

@AA-Turner AA-Turner self-assigned this May 6, 2022
Copy link
Member

@JelleZijlstra JelleZijlstra left a 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."""
Copy link
Member

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)

Copy link
Member Author

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

Copy link
Member

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

Copy link
Member

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.

@JelleZijlstra
Copy link
Member

JelleZijlstra commented May 6, 2022

The preview is live at https://pep-previews--2579.org.readthedocs.build/topic/packaging/. It's missing links.

@AA-Turner
Copy link
Member Author

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

@CAM-Gerlach
Copy link
Member

CAM-Gerlach commented May 6, 2022

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.

The same is true of the email address obfuscation, BTW, and the Page Source link.

@CAM-Gerlach
Copy link
Member

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 Topic

View sub-indices containing just PEPs belonging to specialized topic areas.


@CAM-Gerlach CAM-Gerlach linked an issue May 6, 2022 that may be closed by this pull request
Copy link
Member

@CAM-Gerlach CAM-Gerlach left a 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.

pep_sphinx_extensions/pep_zero_generator/parser.py Outdated Show resolved Hide resolved
pep_sphinx_extensions/pep_zero_generator/parser.py Outdated Show resolved Hide resolved
Comment on lines 43 to 45
if (len(file_path.stem) == 8
and file_path.stem.startswith("pep-")
and file_path.suffix in {".txt", ".rst"}):
Copy link
Member

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

pep_sphinx_extensions/pep_zero_generator/parser.py Outdated Show resolved Hide resolved
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")
Copy link
Member

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/subindicies.py Outdated Show resolved Hide resolved
pep_sphinx_extensions/pep_zero_generator/subindicies.py Outdated Show resolved Hide resolved
pep_sphinx_extensions/pep_zero_generator/writer.py Outdated Show resolved Hide resolved
@CAM-Gerlach CAM-Gerlach added the infra Core infrastructure for building and rendering PEPs label May 6, 2022
@hugovk
Copy link
Member

hugovk commented May 6, 2022

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

Yes but now it's checking by email address.

If you committed with a ID+username@users.noreply.github.com email, that also needs to be on the CLA list.

Can you do the CLA thing with that address too?

Copy link
Member

@hugovk hugovk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@@ -0,0 +1,50 @@
"""Utilities to support sub-indices for PEPs."""
Copy link
Member

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

@hugovk hugovk changed the title Add support for sub-indicies Infra: Add support for sub-indicies May 6, 2022
@pradyunsg
Copy link
Member

pradyunsg commented May 6, 2022

Thanks for picking this up and turning this around so quickly @AA-Turner! ^>^

Would a simpler page just with a numerical index suffice? Are the categorisations useful?

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

  1. I think the Packaging page would benefit significantly from having a more detailed/specific introduction, noting the following details about Packaging PEPs:

    Doing this in a scalable and maintainable manner was what motivated my suggestion to use a Sphinx directive for generating the index entries. :)

  2. Could Open PEPs be listed before Accepted PEPs? That way, a new PEP would basically only flow "down" the page which would be nice. :)

  3. Having a page on the subfolder root (i.e. topic/index.html) would be useful. It would only list packaging for now -- but that's better than a 404 IMO. To be a bit of a broken record: Instead of generating pages in-memory, having these pages be regular .rst files that we put directives into would make this nicer + more obvious.

/cc @pfmoore and @dstufft as the standing PEP delegates, in case they have inputs.

@CAM-Gerlach
Copy link
Member

https://pep-previews--2579.org.readthedocs.build/topic/ is a 404, shall we generate a simple list of topics?

Yeah, we could add a toctree directive in the generated source file (or do it in a transform, etc).

Would a simpler page just with a numerical index suffice? Are the categorisations useful?

I think a numerical index would be significantly less useful than the (as-currently-implemented) categorised index. :)

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.

I think the Packaging page would benefit significantly from having a more detailed/specific introduction, noting the following details about Packaging PEPs:

This might be helpful, but it requires some special-casing for the Packaging Topic, when at least the present approach seems to be treating Topic more as a sort filter rather than a special case (as more so did the original Track proposal). If that's the case, making the list of Topics into a lookup table dict mapping to custom descriptions would probably be the most extensible approach.

Could Open PEPs be listed before Accepted PEPs? That way, a new PEP would basically only flow "down" the page which would be nice. :)

That makes sense; currently, the ordering is perhaps a bit haphazard.

To be a bit of a broken record: Instead of generating pages in-memory, having these pages be regular .rst files that we put directives into would make this nicer + more obvious.

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.

@pradyunsg
Copy link
Member

pradyunsg commented May 6, 2022

If that's the case, making the list of Topics into a lookup table dict mapping to custom descriptions would probably be the most extensible approach.

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

@AA-Turner
Copy link
Member Author

The CLA website is also reporting an internal server error with the link on this PR...

A

@AA-Turner
Copy link
Member Author

https://pep-previews--2579.org.readthedocs.build/topic/packaging/

@pradyunsg how's the additional description?

On your other points:

  • I'm not going to change the category order in this PR.
  • I agree with Cam about not using a custom directive, for the reasons he mentioned and as I'm averse to "non-native" reST, as it makes things less discoverable.
  • I added a toctree directive for the topic page.

I didn't have time today to update the PEP 0 transforms, though.

A

@CAM-Gerlach
Copy link
Member

I agree with Cam about not using a custom directive, for the reasons he mentioned and as I'm averse to "non-native" reST, as it makes things less discoverable.

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.

@AA-Turner
Copy link
Member Author

"native" reST approach

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

@CAM-Gerlach
Copy link
Member

CAM-Gerlach commented May 8, 2022

By this I mean directives as specified in the reStructuredText specification

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:

Directives are an extension mechanism for reStructuredText, a way of adding support for new constructs without adding new primary syntax (directives may support additional syntax locally).

Yes, they aren't a first-party directive understood by the reference parser (docutils), but neither are Sphinx extensions, nor our custom :pep:, :rfc:, etc. roles, and certainly not arbitrary Python code, as it is currently implemented.

having custom unrecognised directives isn't very useful to e.g. the GitHub UI, which uses Docutils (or a reimplementation of it).

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)? 🤣

@AA-Turner
Copy link
Member Author

Copy link
Member

@hugovk hugovk left a 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?

pep-previews--2579.org.readthedocs.build/topic?

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.

@AA-Turner AA-Turner changed the title Infra: Add support for sub-indicies Add support for topic indices Jun 8, 2022
@AA-Turner AA-Turner closed this Jun 9, 2022
@AA-Turner AA-Turner reopened this Jun 9, 2022
@ambv
Copy link
Contributor

ambv commented Jun 9, 2022

Hi there, I temporarily added DO-NOT-MERGE as I need this open to squash the CLA email problem.

@AA-Turner AA-Turner closed this Jun 11, 2022
@AA-Turner AA-Turner reopened this Jun 11, 2022
@AA-Turner
Copy link
Member Author

python/cpython#93736 passed the CLA check...

Copy link
Member

@pradyunsg pradyunsg left a 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! :)

@JelleZijlstra
Copy link
Member

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

@AA-Turner
Copy link
Member Author

I made a new PR with an empty commit at #2650 that fails CLA checks -- @ambv does that one work for your testing?

A

@pradyunsg
Copy link
Member

This needs a closes #2572 in the PR description. :)

@pradyunsg
Copy link
Member

@AA-Turner could you merge or rebase this, such that the changes in #2636 is included in the PR preview on this PR?

@ambv ambv enabled auto-merge (squash) June 18, 2022 17:33
@ambv ambv removed the DO-NOT-MERGE label Jun 18, 2022
@ambv ambv disabled auto-merge June 18, 2022 18:04
@ambv ambv merged commit a2f2d6c into python:main Jun 18, 2022
@pradyunsg
Copy link
Member

Whee! Thanks everyone for helping get this implemented, polished and over the line! ✨

https://peps.python.org/topic/packaging/

carljm added a commit to carljm/peps that referenced this pull request Jun 27, 2022
* 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)
  ...
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
infra Core infrastructure for building and rendering PEPs
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Sub-index pages for specific categories of PEPs (Packaging, etc)
6 participants