Support redirects from non-padded PEP numbers #2421
Conversation
|
@ezio-melotti -- JS works for now. The auto-linker will need to be set up with no prefix to the domain & then just passing the number. A |
Co-authored-by: Ezio Melotti <ezio.melotti@gmail.com>
|
https://pep-previews--2421.org.readthedocs.build/pep-8/ seems to work fine. I this we should add a check on the length of the number. I'll leave a suggestion in the code. |
| <meta name="description" content="Python Enhancement Proposals (PEPs)"/> | ||
| <script> | ||
| const pepNumMatch = window.location.pathname.match(/^\d+$/) | ||
| if (pepNumMatch !== null) { |
There was a problem hiding this comment.
| if (pepNumMatch !== null) { | |
| if (pepNumMatch !== null && match[0].length < 4) { |
There was a problem hiding this comment.
Our comments crossed over, sorry!
We could check the number but if invalid the only harm of not checking would be an extra redirect from one invalid URL to another.
A
| <link href="https://fonts.googleapis.com/css2?family=Source+Sans+Pro:ital,wght@0,400;0,700;1,400&display=swap" rel="stylesheet"> | ||
| <meta name="description" content="Python Enhancement Proposals (PEPs)"/> | ||
| <script> | ||
| const pepNumMatch = window.location.pathname.match(/^\d+$/) |
There was a problem hiding this comment.
With ^ and $ in the regex, it won't match pep-NNN. Did you just change this temporarily to test?
Note that in the suggestion below I used match[0] because of this change, but if my previous suggestion is restored it should be match[1].
There was a problem hiding this comment.
it won't match
pep-NNN
From above, "I don't want to include the pep- prefix for the auto-redirects"
A
There was a problem hiding this comment.
Why not?
If we set the autolinking to https://peps.python.org/pep-<num>/ and <num> is a valid 4-digits number (e.g. pep-0008), then it will go straight to the right page. If we omit the pep- prefix, then it will have to go through an extra redirect if JS is enabled, or end up at the 404 page if JS is disabled.
In case of a valid PEP with a <4 digits number (e.g. pep-8) it will go to /pep-8/ and get redirected to /pep-0008.
In case of an invalid PEP with a <4 digits number (e.g. pep-123) it will go to /pep-123/, get redirected to /pep-0123, and then stop at the 404 page since the PEP doesn't exist and the id is already 4 digits long.
Am I missing something?
There was a problem hiding this comment.
The autolinking on this repo is currently set to link to https://python.org/dev/peps/pep-<num>. My suggestion that simply matched pep-(\d+) works even with this type of URL, but fails with /^\d+$/.
The latest change matches We could check the number but if invalid the only harm of not checking would be an extra redirect from one invalid URL to another. A |
|
As mentioned on #2420 , you could do this all in HTML with no JS needed by just using Instead of this approach, that could be used here as a post-build step in the CI/makefile (I would be willing to relicense it CC0), as we do, with only slight modifications (since almost everything is done via CLI arguments rather than hardcoded), and would avoid the need for JS as the redirects are statically generated on site build, like the rest of the site. |
|
I don't know if the preview site has a part to play in this, but the A |
|
@AA-Turner Good catch; I can replicate the behavior you described. However, the redirects generated by my script I linked are essentially instant (≈100 ms; see, for example, this page) and nothing renders in the viewport except the final page, with no visible artifacts (and the host is GitHub Pages, just like the production site here). I suspect the issue is due to your redirect pages including a I suggest simply eliminating all those elements, which should result in identical behavior (at least in production) to the examples I shared. |
|
|
||
|
|
||
| def prepare_redirect_pages(app: Sphinx) -> Iterator[tuple[str, dict, str]]: | ||
| for path in Path(app.srcdir).glob("pep-????.???"): |
There was a problem hiding this comment.
| for path in Path(app.srcdir).glob("pep-????.???"): | |
| for path in Path(app.srcdir).glob("pep-[0-9][0-9][0-9][0-9].???"): |
Use the correct glob to ensure this is actually a PEP with a valid number. Otherwise, it can match any arbitrary txt or rst file that starts with pep with a four-character suffix, which will cause an error on line 18 (we don't have any right now, but it will suddenly cause a build failure if we ever do, so we may as well just do this properly now.
There was a problem hiding this comment.
if we ever do
This is I suppose my reluctance to put [0-9] rather than ? -- I seriously think this is very unlikely to happen, and [0-9] is five times as many characters as ?. (The thought applies in all cases that this has been suggested).
A
There was a problem hiding this comment.
I hope you didn't stay up all night...or just up really early?
A few more characters perhaps, but in terms of what actually matters, does that make it that much less clear to the reader? And is it really worth sacrificing precision and correctness, and risking a potential future hard build failure just to skimp on a few characters? I realize there is some tradeoff to be made, but it seems the rest of us who have weighed in so far have considered it a worthwhile one.
There was a problem hiding this comment.
Done. I still disagree though!
A
|
It does seem quicker now, although there may be bias in that I want it to be quicker! A |
|
I'd like to hear about Nginx redirects #2420 (comment) before reviewing this. Thanks! |
Unless I'm misunderstanding something, that approach only works for people who type in the old no longer canonical URL, i.e.
aren't so much of a factor here with the optimized HTML-based approach. I certainly think the redirect rules could be adjusted to also do this, but that could supplement, not replace the approach in this PR, no? |
|
Ah right, yes, Nginx redirects don't apply to this: #2420 (comment). Will review this, thanks! |
There was a problem hiding this comment.
Testing:
- https://pep-previews--2421.org.readthedocs.build/pep-8
- https://pep-previews--2421.org.readthedocs.build/pep-12
- https://pep-previews--2421.org.readthedocs.build/pep-101
- https://pep-previews--2421.org.readthedocs.build/pep-foo
- https://pep-previews--2421.org.readthedocs.build/pep-0123
These all redirect to https://pep-previews--2421.org.readthedocs.build/pep-0404/
For example, https://pep-previews--2421.org.readthedocs.build/pep-8 has status code 404 and then the next loaded page is https://pep-previews--2421.org.readthedocs.build/pep-0404/ with status code 200.
|
Although none of those URLs are valid (the supported scheme is https://peps.python.org/pep-8 redirects to the standard 404 page -- I wonder if the JS experiment's 404 has been cached or something? A |
The intended redirect pattern that @AA-Turner implemented is The reason this happens is that this attempts to load |
The law of unintended consequences... I suppose we could do A |
|
Would https://pypi.org/project/sphinx-reredirects/ help? |
|
We looked into it, but I don't think 0.0.1 was released yet when we implemented it, and we weren't sure if the wildcard support would fully handle our current and future use cases, so we ended up implementing our own solution. For this case, that doesn't look like that would be a huge issue, but it doesn't support the sort of rewriting we need here, so unfortunately it doesn't look like it'd work (at least at present). |
|
I won't have time to resolve this before mid April -- feel free to push to this branch on my repo or close this PR as you see fit. My views are strongly in favour of the simple A |
I really would like to not rely on such hacks, and would prefer not to go with the JS approach if possible for the reasons @hugovk mentioned, so I'd strongly lean toward the two less complicated and costly alternatives here—either reverting to the |
|
Closing, this has been implemented in #2420. Thanks! |
fixes #2420
A