-
Notifications
You must be signed in to change notification settings - Fork 647
Record readme filename; use to determine whether to render as Markdown or not #1134
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
Merged
bors-voyager
merged 8 commits into
rust-lang:master
from
kivikakk:record-readme-filename
Oct 25, 2017
Merged
Changes from all commits
Commits
Show all changes
8 commits
Select commit
Hold shift + click to select a range
dca3299
Record readme filename from cargo transmit
kivikakk 12c4762
Render non-Markdown READMEs as plain text
kivikakk 633a214
Don't let this exit the container
kivikakk 0b87650
clippy!
kivikakk c00faea
Cleanup based on @kureuil's comments
kivikakk 0dde304
No extension = assume Markdown.
kivikakk 80129d1
Merge remote-tracking branch 'upstream/master' into record-readme-fil…
kivikakk 931427f
Merge remote-tracking branch 'upstream/master' into record-readme-fil…
carols10cents File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Oops, something went wrong.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -305,6 +305,7 @@ | |
} | ||
.crate-readme { | ||
line-height: 1.5; | ||
overflow-wrap: break-word; | ||
|
||
img { | ||
max-width: 100%; | ||
|
1 change: 1 addition & 0 deletions
1
migrations/2017-10-17-052814_add_readme_file_to_crates/down.sql
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1 @@ | ||
ALTER TABLE crates DROP COLUMN readme_file; |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1 @@ | ||
ALTER TABLE crates ADD COLUMN readme_file VARCHAR; |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.
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 see that we're now storing the README filename alongside its content, though it doesn't seem to be used anywhere ? I'm not opposed to storing it but I'm not sure to see how useful it is to store it in the database.
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.
You're right, we don't strictly need to store it. I was thinking we might need it in
render-readmes
, but that pulls the README filename from the manifest directly. However, I feel like storing this as well might be important for things like #1025/#1019?A more general argument is that, if there's no need to store the README filename in the database, then there's no need to store the README content in the database, because we can't properly make sense of the latter without the former.
That's moreorless the motivation of this PR in a nutshell: we don't know how to interpret the README contents without knowing its filename. So if we store the content, we should store the filename 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.
Yeah, you're totally right about needing to store the filename alongside the README content, my bad.
However, maybe we can improve a little here and instead of storing the README filename as transmitted, how about storing the normalized README type ? i.e only
markdown
for now. This would also allow us to use anENUM
instead of aVARCHAR
field in the database and simplify its usage.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 like the idea of doing this, but I'm worried about the loss of fidelity. e.g. say we do so, and currently store
'markdown'
orNULL
for everything. Later we add AsciiDoc or org-mode support — it'd be great to go back and rerender the newly supported readmes, but to do so we'd have to reach back inside each crate and retrieve the readme filename from the manifest again.I think storing the filename directly allows us more flexibility later on in how we want to treat certain things, especially in the face of changing/new standards and formats; this is how we approach file classification at GitHub, for example, and it works well for us.
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.
In any case, we probably will have to do it. The
crates
table only stores the README of the last published version of a given crate, so if we add org-mode or AsciiDoc support to crates.io we'd still have to reach back inside each crate in order to render it. Anyway, you're right about your approach being more flexible so let's keep it this way :)