-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
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 by Bors] - Add readme as docs to relevant crates. #2575
Conversation
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.
Awesome, thank you!
bors try |
tryBuild failed: |
I tried to do the same on my #2365 PR, but the examples in |
@mockersf, any ideas on how to work around this CI issue? |
It's not only a CI issue though. Running a simple command like cargo test -p bevy_ecs --doc would fail. |
We could ignore the doc tests? Put " ```rust ignore " for the start of the blocks instead of " ```rust " |
Yeah, I think Github is likely to just show the extra lines of code :( Let's try ignoring them; it's no worse than the current situation where they're never compiled. |
I don't know if ignoring will retain the code highlighting on GitHub renders... |
Hmmm, yeah I don't know either. |
I'll go through and grab the rest then 😄 |
Ignore the doc tests in the readme, this allows "cargo test --doc -p *" to run without errors
Alrighty they should be ignored now, cargo test --doc -p * worked fine for me. |
I'm not a fan of ignoring the failing code examples as a big plus of including the README is to test those examples. Would it be hard to fix them? |
The issue wasn't that they would be hard to fix (I don't think so but I'd need to check again once I can) but that if we fixed them we'd either clutter up examples in the docs and GitHub, or we'd do the hide lines thing for docs.rs but it would show the lines still on GitHub. It's up a little bit in the conversation, we talked about it. |
Yup, but it depends: is allowing the code blocks to work just adding 2 lines of imports? I think that's worth it. Is it adding 20 lines of setup? Ok that can be ignored, or maybe the example can be reworked? |
I'm not entirely sure and I'm not in a position to check right now, but in the next day or two I should be able to see. (Maybe tonight, I don't know.) |
Alrighty, so I went through and made the examples work. bevy_reflect has all of the setup at the top example. I could go through and copy and paste it into every other example but that's the 20 lines of setup we wanted to avoid. Tasks and transform had no examples so that's easy enough. |
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.
Good call to include the Readmes, thanks!
Can we try to keep the Readme examples of bevy_ecs
free of other bevy crates? I think of this Readme as showing examples of how to use bevy_ecs
standalone in e.g. other engines or completely different contexts than gamedev.
crates/bevy_ecs/README.md
Outdated
@@ -68,11 +87,17 @@ fn print_position(query: Query<(Entity, &Position)>) { | |||
Apps often require unique resources, such as asset collections, renderers, audio servers, time, etc. Bevy ECS makes this pattern a first class citizen. `Resource` is a special kind of component that does not belong to any entity. Instead, it is identified uniquely by its type: | |||
|
|||
```rust | |||
use bevy_ecs::prelude::*; | |||
|
|||
// Bevy does provide its own more advanced Time as a resource, but we |
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.
Bevys' Time
is part of the core crate. I would prefer keeping this readme purely for bevy_ecs
, so I would remove this comment here.
crates/bevy_ecs/README.md
Outdated
@@ -174,6 +211,9 @@ fn system(query: Query<&Position, Added<Velocity>>) { | |||
Resources also expose change state: | |||
|
|||
```rust | |||
use bevy_core::Time; |
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.
See comment above. Can we get rid of the bevy_core
dependency?
@alice-i-cecile could we add this to 0.6? It would be nice to have the readmes in the official documentation of the next release. And the change is pretty uncontroversial I would say. |
Fixes #3005 (that is how you do that, right? Just put that here?) |
I think it needs to be in the commit message. So in this case in the PR description. |
#[derive(Default)] | ||
struct Time { | ||
seconds: f32, |
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 object to using a tuple struct here. The named field is way better at documenting intent. Tuple structs rarely have a place in public apis imo.
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.
Sounds good to me 👍
One small comment. Everything else looks good to me! |
bors r+ |
Fixes #2566 Fixes #3005 There are only READMEs in the 4 crates here (with the exception of bevy itself). Those 4 crates are ecs, reflect, tasks, and transform. These should each now include their respective README files. Co-authored-by: Hoidigan <57080125+Hoidigan@users.noreply.github.com> Co-authored-by: Daniel Nelsen <57080125+Hoidigan@users.noreply.github.com>
Fixes #2566
Fixes #3005
There are only READMEs in the 4 crates here (with the exception of bevy itself).
Those 4 crates are ecs, reflect, tasks, and transform.
These should each now include their respective README files.