use Zola for a prettier Awesome Bevy!

[mockersf]

you can view the result here: https://vleue.com/awesome-bevy/

before merging, don't hesitate to change the base_url to where you want it deployed!

[mockersf]

ok I swear I didn't see #70 before doing this, but seems related

[mockersf]

• updated the readme for the new contribution process
• improved search
• added a link to the repo to add something new
• improved images and added for section "2D" with images from the crate repos
• added colored license display and licences for section "2D"
  • colors are chosen by https://github.com/badges/shields/blob/master/services/licenses.js, green for permissive, slightly-different green for public domain, orange for copyleft, gray for the rest

https://vleue.com/awesome-bevy/#plugins-2d

[alyti]

Just a thought, maybe there should be a bevy version label? As I've noticed some stuff on this list is still 0.4 and it might be confusing to newcomers looking for plugins.

[Nilirad]

Also it would be awesome to show tracking badges shown in readme.md, like

EDIT: or just check Cargo.toml to check the bevy version it depends on and maybe run a CI daily to see if it builds (especially for plugins that track the main branch of Bevy)

[mockersf]

Getting those info is possible but significantly harder. This is a static site, so unless someone add a static file to it at build time, it won't be displayed. The usual way to have those infos would be to require users to add it and maintain it on every Bevy release or change on their side, which is not a good idea I think.

In theory we could hit GitHub in js every time someone display the page, but that would be ugly and slow.

The proper way to do that would be to add a preprocessor that would check the link provided in each plugin and extract info if it's a GitHub repo, a crates.io link, ..., and schedule redeploy of the site daily (also on demand maybe) to catch changes.

It's more work than I intended to do for a poc of the integration with Zola, but definitely something to keep in mind

[cart]

The proper way to do that would be to add a preprocessor that would check the link provided in each plugin and extract info if it's a GitHub repo, a crates.io link, ..., and schedule redeploy of the site daily (also on demand maybe) to catch changes.

We could consider spec-ing out a [package.metadata.bevy] section of cargo.toml. That would give us a standard way to extract info from repo links. But yeah as you mentioned, not something we can/should have for a POC. And yeah I agree that at least in the short term we definitely want this to be statically generated. Dynamism introduces a lot of complexity (javascript and potentially webservers and databases) and would naively make everything much slower. Eventually that complexity will be "worth it", but we're not there yet 😄

In general I dig this. I'll start a full review soon. Once we wrap up the review process here (and if we decide to roll with this impl), I think we'll want to move this to the bevy-website repo and add a way to pull the data from awesome-bevy during deployment.

[marko-lazic]

I like the card images. It would be nice to have them unique and mandatory for every card.

[cart]

I'm largely on board for this impl, but I'd like to make a couple of large-ish changes before merging (most of these won't come as a surprise given how much we've talked about them 😄 ):

1. I want everything but the user-submitted awesome-bevy entries to live in the bevy-website repo. I'd prefer to move this PR there asap because reviewing thousands of lines of stuff copied from there doesn't seem worth it
2. I'd like user-submitted entries to be defined as normal TOML instead of "Zola front matter syntax". That gives better syntax highlighting, feels more natural, and translates nicely to eventually letting people check in awesome-bevy metadata into their own repos.

I imagine the process would be something like this:

1. merge pull request in awesome-bevy repo (toml content validated by CI)
2. trigger bevy-website deployment upon merge (im fine with skipping this initially in favor of manual syncs)
3. bevy-website build process checks out awesome-bevy repo
4. a standalone tool processes awesome-bevy toml files, (in the future) joins on other data sources like crates.io, and outputs Zola templates into the appropriate place.
5. run zola build
6. deploy bevy-website

[cart]

Closing in favor of bevyengine/bevy-website#156