Remove netlify redirect for flexdashboard, use github pages

[gadenbuie]

Removes the redirect to the Netlify-hosted flexdashboard package site. The general /* -> rstudio.github.io/:splat should still work.

It also turns our previous distill-based page into a Quarto static page and adds the setup needed to make the package listing dynamic: add packages to packages.yml to have them included on the page. This makes the listing customizable in ordering and allows us to list packages that aren't in the _redirects file (which is no longer used as the source of truth).

[gadenbuie]

@cderv Do you have any idea why Quarto's CSS files aren't being found in the Netlify preview? This whole thing works for me locally, but in the preview it seems that Quarto's rules aren't being applied (things like setting the base font, title styles, etc.). I'm baffled (as you can see from the last dozen commits).

[cderv]

@gadenbuie I can have a look into this. But maybe we can split the PR to get your initial change in live version ?

FWIU it was just updating so that flexdashboard is no more netlify but github.io. But I see this PR is also switching to Quarto page instead of distill.

For the time being I did not update (improve) the page because:

• The future of this page depends on some decision / work by @tracykteal - the source of truth was supposed to be a google sheet at some point.
• This means the global design and how this site should work it still TBD
• It is working as is and changing is always prone to friction (which we have here)

So I am ok to make some updates if we all agree, and happy to make the change myself. I was just "on pause" with since following last discussion with Tracy.

Anyhow, I'll see if I can debug you try on this - quite some changes at it seems you did not like renv and went back to DESCRIPTION 😉 Probably have some question about the changes too (_redirect was source of truth because we needed it anyway, so if we don't use as SOT, we still need to update it dynamically).

@tracykteal are we ready to update pkgs.rstudio.com or still some thoughts to have about the future of this page ?

[cderv]

Quarto's rules aren't being applied (things like setting the base font, title styles, etc.).

BTW which rules are you talking about ? I don't see any SCSS in the PR 🤔

[tracykteal]

Thanks @gadenbuie and @cderv! Yes, we have a google spreadsheet with all the R packages we maintain, and we're thinking to use that as the source of truth to put all of those packages on this page. We're ready to go with that plan! So @gadenbuie how about we combine that work with this work to update the page? We can work on that now.

[cderv]

Awesome!

Initial plan was

• Read from the googlesheet
• Generate the _redirect file for Netlify to work with other netlify site
• update the index page
• improve by deploying the pkgs.rstudio.com page on gh-pages instead of committing directly in main.

We could indeed do that with quarto. Using reactable still seemed to be a good idea. I think we wanted to add some fields to the table too.

[tracykteal]

That all still seems like a good plan! @gadenbuie does that align with what you're thinking?

[gadenbuie]

@gadenbuie I can have a look into this. But maybe we can split the PR to get your initial change in live version ?

Well... I know this has a bit of scope creep, but I started down this path because removing flexdashboard from _redirects would also remove it from the listing. So I started working on rewriting the listing.

quite some changes at it seems you did not like renv and went back to DESCRIPTION 😉

renv is way too slow in GitHub actions 😢 I've also noticed that we've tended to update the renv every time we touch the page. I think we could go back to renv once the page is stable.

---

Quarto's rules aren't being applied (things like setting the base font, title styles, etc.).

BTW which rules are you talking about ? I don't see any SCSS in the PR 🤔

When I render the page locally, I see the following.

But the deploy preview looks like this for me. What's missing is Quarto's version of Bootstrap and extra baseline rules.

---

In general, I think we can take these changes, once we work out the Quarto problem. They essentially keep the directory as-is while adding a few more packages.

It doesn't have to stay this way for long, and we can use the Google sheet in the future. I will say I'd rather the data live in the repo unless we're okay with the sheet being public. Otherwise we have to set up a Google service account and a bunch of other shenanigans.

[gadenbuie]

Thanks @gadenbuie and @cderv! Yes, we have a google spreadsheet with all the R packages we maintain, and we're thinking to use that as the source of truth to put all of those packages on this page. We're ready to go with that plan! So @gadenbuie how about we combine that work with this work to update the page? We can work on that now.

Yeah this all sounds great to me! I would like to merge this PR and start that work in a new branch, but other than that I'm on board.

I think this PR just moves us away from some of the previous constraints and gets us a little more used to using Quarto. Beyond that, we may or may not want to use One Big Table (I'm leaning toward not). So I don't think we should worry about the changes in this PR being perfect or even that close to what we're going to do with the new site. (I have ideas 😄 💡)

[cderv]

because removing flexdashboard from _redirects would also remove it from the listing. So I started working on rewriting the listing.

Oh yeah I see. Thanks for the context.

renv is way too slow in GitHub actions 😢 I've also noticed that we've tended to update the renv every time we touch the page.

ok I am surprised by that. I don't have that experience. I'll have a look later on then.

What's missing is Quarto's version of Bootstrap and extra baseline rules.

Indeed odd. Thanks for detailing. I'll have a look to that.

I will say I'd rather the data live in the repo unless we're okay with the sheet being public. Otherwise we have to set up a Google service account and a bunch of other shenanigans.

My understanding was that the gsheets already existed for other purposes and it was better to use that existing db. @tracykteal I think you need to tell us what should be the expected source of truth for this project. I took the gsheet as an input and a constraint here but maybe I was wrong. there is indeed other solution.

I would like to merge this PR and start that work in a new branch, but other than that I'm on board.

Let's solve this resource issue then and merge. I still think it would be a good idea to switch to using gh-pages and benefit from quarto publish feature. It would we cleaner than CI committing to same branch.