External Links in Quarto Front Matter

[LarryVincent]

I am trying to DRY up my code. I use the same custom stylesheet and header include on every Quarto presentation. I'd like to store them in the cloud and reference in my front matter. But every attempt has failed. For my theme, I tried:

theme: [default, "https://link.to.my.custom.scss"]

That didn't work. Same for this code:

include-in-header: file: "https://link.to.my.cloud.insert.file"

How might I accomplish this? I hate how fat my GitHub repository is becoming with the same files.

[mcanouil]

You can't, what you have to do is regular html linking:

include-in-header:
  - text: |
      <link rel="stylesheet" href="style.css" type="text/css">

[cscheid]

That doesn't accomplish the same thing, because we process scss files through SASS.

@LarryVincent For the same reason (we process scss files locally), quarto needs a local copy of the file, so the feature you're suggesting (to grab files from WWW mid-processing) isn't supported.

[mcanouil]

Meaning what I suggested would only work for css but not for scss? Or for both? 🤔

[cscheid]

That's right. What you're suggesting works because that gets included directly in the HTML file, and webpages are naturally allowed to have links to external CSS files. But in the case of SCSS files (which we do allow in the theme field), quarto needs to be able to access those files to resolve variables, etc, and compile the SCSS down to CSS.

[baptiste]

Not sure if it's a good idea but I think you can make symlinks to a single centrally-stored scss (on your machine) in each project, to keep them "dry" (assuming you're running quarto locally and not on the cloud via CI).

[cscheid]

To expand a little on this answer:

(Since the OP mentioned a git repository) It's worth noting that git doesn't do anything special with symlinks. As far as git is concerned, a symlink is just a weird text file. So you'll need to manage that relationship explicitly.

It's also worth noting that since the OP mentioned:

I hate how fat my GitHub repository is becoming with the same files.

There are two ways in which I think you might not like where your repo is going. Let me try to address them.

potential concern 1: overall storage usage

Git is a "content addressable store", and it actually stores deduplicated files under their SHA1 signatures. So files that exist across versions are not repeated. Here's a shell session with a minimal example:

$ mkdir git-tests
$ cd git-tests
$ git init
$ echo "A file" >> file1
$ echo "A file" >> file2
$ git commit -am"first commit"
[main (root-commit) 3b5f029] first commit
 2 files changed, 2 insertions(+)
 create mode 100644 file1
 create mode 100644 file2
$ git ls-files -s file1 file2
100644 51f466f2e446ade0b0b2e5778ce3e0fa95e380e8 0	file1
100644 51f466f2e446ade0b0b2e5778ce3e0fa95e380e8 0	file2

Note the same hash here. It means that in the "object store" (the git "database"), there's only one A file file. So as you add more commits, your git repository won't create new entries for those files. Because they all refer to the same content

It is still the case that in your working directory (the stuff you get with git clone), those file1 and file2 will still be represented as separate entries in the filesystem. SCSS files tend to be relatively small, so I don't think it's a problem that they'll be repeated many times in your working directory. As commits accumulate, the storage will still be efficient.

potential concern 2: Don't Repeat Yourself (DRY)

If you're looking to reduce the DRY issue for engineering reasons (that is, you have a single file that you want to edit and affect all of the projects), then as @baptiste suggested, you can use a symlink. I would recommend that you keep symlinks internal to your repository, so that the content file is versioned and you maintain reproducibility in git clones.

[baptiste]

Another DRY idea, if you wanted to reuse many common files, might be to store and import them as a git submodule; that said, submodules seem to receive a fair bit of criticism.

[LarryVincent]

These were great suggestions and I appreciate the quick response. I was able to use @mcanouil 's suggestion and it worked perfectly. I also just learned about Quarto Projects and how to merge YAML, which is a game-changer for me. I'm really impressed by Quarto. The deeper I get into it the more I realize how powerful it is. Thanks again to the R community for the quick response.

[mcanouil]

If it worked, it means your scss file is actually a css file and does not have any variables to be processed I guess.

[cderv]

Other idea with shared online file to sync up locally with a Quarto Project at each render : Do a download and update of the files in a pre-render step ?