Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Design doc: Better handling of docs URLs #9425
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
Design doc: Better handling of docs URLs #9425
Changes from 1 commit
cb100a8
8d50412
24e9fef
3055c6c
30bbcca
ed29129
0b21391
2658ec6
015dd31
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
I'm confused with this line and the goal just added: "Removing reserved paths and ambiguities from URLs". I understand that we are not removing the reserved path
/projects/
. Am I misunderstanding the meaning of reserved path? Can you expand on the specifics of that goal?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.
projects
isn't reserved with this implementation, single version projects can use that path to serve files, see the last two examples from https://dev--9425.org.readthedocs.build/en/9425/design/better-doc-urls-handling.html#single-version-project-with-subprojects.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.
Considering the "Single version with subproject" example.
something
something
subproject is also single versionNow, let's say that we receive the URL
/projects/something/
:/projects/something/index.html
exists in the parent projectsomething
also has anindex.html
file at its rootWhat file will we serve? Whatever the answer be, these are the cases why I'm saying that we are not removing the "reserved path" and the design has these restrictions. It does not seem we can remove this ambiguity while keep using a "reserved path" to give URLs a different meaning. No matter the implementation.
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.
Yea, I am a little confused here too. I thought the goal of this project was to improve our handling to allow us to be smarter about these cases. It seemed in the design doc that custom prefixes were supported, is that not shown in this code example?
@humitos to your point, if we're serving subprojects there will always be some kind of overlap. You can't serve 2 different directories from the same path and not have an order that they are evaluated. I think that's fine, as long as we let users decide that the prefix is, instead of hard-coding
projects
.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.
Exactly. That's what I'm saying.
The proposed implementation in this document is hard-coding
/projects/
and that's why I raised this here.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.
I thought that was part of the custom URLs part that we wanted to not support yet, I can update the code example to integrate the suffix.
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.
So this does only serve subprojects from matching directory if there is a matching subproject. That seems 💯
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 this calling itself in a recursive way or it's calling the current
resolve
function we have now?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.
this is recursive, yes, guess this mimics more what we currently call
unresolve
, and what we callresolve
is more like areverse
(from django.urls.reverse).