PDF and EPUB links in dev build point to main site instead of dev version

[profvjreddi]

I realized that when the dev build is built, the links for the PDF and EPUB are actually pointing to the main site and not the dev version. This could lead to mistaken assumptions that everything is working correctly on the dev build, when in fact the links are not valid for the development environment.

Dev

Steps to reproduce:

1. Build the dev version of the site.
2. Check the links for PDF and EPUB.
3. Notice that they point to the main site, not the dev build output.

Expected behavior:
Links in the dev build should point to the dev version of the PDF and EPUB, not the main site.

Impact:
This makes it easy to miss issues with the dev build's PDF/EPUB output.

Suggested fix:
Update the build logic so that links in the dev environment point to dev artifacts.

[siddu1324]

Hi @profvjreddi 👋

I went through all three Quarto configuration files (_quarto-html.yml, _quarto-epub.yml, and _quarto-pdf.yml), and I didn’t find a site-url key being defined anywhere. Instead, the links in the HTML navbar are hardcoded to production URLs — for example:

- icon: file-pdf
  text: "PDF"
  href: https://mlsysbook.ai/pdf
  target: _blank
- icon: book
  text: "EPUB"
  href: https://mlsysbook.ai/epub
  target: _blank

This means the dev and preview builds always point to mlsysbook.ai, regardless of environment.

To fix this, I can:

• Introduce an environment variable (like SITE_URL or BASE_URL) in the Makefile or CI workflow,
• Reference it in _quarto-html.yml dynamically (via templating or a small pre-build script),
• So that local previews link to relative paths (/pdf, /epub) and production builds use the public URLs.

Would it be okay if I implement that and open a PR for review?

[profvjreddi]

Hi @siddu1324, that would be great! However, the issue goes beyond just fixing the relative paths, which I agree we need to do. We also need to update the validate-dev GitHub workflow to properly package the build artifacts, and then the deploy preview workflow must take those artifacts and push them up. That's the real challenge.

If you examine the GitHub workflows I have set up, you'll see that they are quite complex. 😓 Once I get that working, it will definitely be helpful. I was planning to do this over the Christmas break because most people don't typically look at the dev branch outside of me.

Feel free to take a look and see if you think you can handle it, but don’t worry if it seems too messy; I know it can be difficult to understand what I've got going on.

[siddu1324]

Got it, thanks for the context @profvjreddi ! That makes total sense, I had a feeling the workflows might be the tricky part 😅

Sure, Prof! I’ll start by looking into the CI/CD setup and see how the validate-dev and deploy preview workflows are structured. I’ll also try tackling the path logic first to get that part working cleanly, and then I’ll let you know if I feel comfortable handling the rest.

Appreciate the heads-up — I’ll take a look and keep you posted!

[profvjreddi]

Thanks a bunch @siddu1324 🙏

[profvjreddi]

@siddu1324 I fixed it. Could you please take a look, just so that I have a different set of eyes on it?