Closed cardi closed 2 years ago
I'm not aware that jekyll scholar changes the _config.yaml
file? We certainly use the configuration a lot and we add certain defaults, but I don't think we're writing them back to site.config
in memory (certainly not to the file).
Each of the scholar 'plugins' defines a local config
based on our own defaults (for example, here is the bibliography
tag) then calls set_context_to
on each render which merges in the site.config
. Since we use our local config for everything it may just be a bug somewhere that the defaults end up in site.config
.
jekyll-scholar doesn't modify _config.yaml
on disk, but does seem to modify site.config
in memory, which is ultimately what gets stored in the cache.
When jekyll is re-run, jekyll will compare the config on disk (_config.yaml
) with the cached config: since the two aren't the same, all caches are deleted.
This is what a typical config might look like: https://github.com/cardi/website/blob/master/_config.yml
This is the config that was pulled from memory and copied on to disk: https://github.com/cardi/website/blob/master/_config-bibtex.yml. When using this _config-bibtex.yml
, caches work as expected. (Many thanks to @zenkalia for helping me with this).
I think that explicitly defining all the key/values in the config is an OK workaround for now, given that I'd like to prototype caching the details/references, but it might be worth looking if and how some of the plugins modify site.config
directly.
(This could also be a bug in jekyll or the new Cache API -- I haven't explored it completely, but perhaps there's some hook that is aggressively checking and caching site.config
.)
I created a debugging repository here: https://github.com/cardi/website/ -- running bundle install
will use some of my debugging branches of jekyll and jekyll-scholar.
Running make build
will use _config.yml
, and you'll be able to see the config mismatches and caches being deleted each run.
Running make hydrated
will use _config-bibtex.yml
, and caches now work as expected because the config on disk is equal to the config in cache.
Thanks for your work on this!
I'm a bit removed from all of this, but I don't think we would need to alter site.config
; grepping through the repo code quickly, it does not look as if we do that explicitly. With the Cache API coming, you're absolutely right that we should make sure this does not happen.
I'm working on a prototype to fix https://github.com/inukshuk/jekyll-scholar/issues/256 using the Cache API that will be in Jekyll 4 (which is currently alpha).
(There are some nice optimizations that will be enabled by default in Jekyll 4, like rendering Markdown once and reusing it from the cache.)
problem
jekyll-scholar always makes changes to the configuration yaml at build time, which results in cache deletion each time the site is built.
details
Jekyll will delete all the caches if the configuration file (default to
_config.yml
) is different from the configuration that is stored in the cache.It looks like jekyll-scholar is modifying the configuration directly at runtime, perhaps to store some global variables?
The following is the output of
diff -y config-before config-after
. On the left is the internal configuration seen at the start of the build process, and on the right is the modified configuration, presumably after some hooks that jekyll-scholar or its dependencies have triggered:The issue is, during the build process, the configuration on the left gets changed, and the resulting changed configuration on the right is the one that ultimately gets stored in the cache.
Then, when running
jekyll build
subsequently (regardless whether--incremental
is passed or not), the initial configuration that's loaded from file will always have a mismatch with the cached configuration, resulting in cache deletion and rebuilding.resolution?
I'm not quite sure how to solve this issue, given my unfamiliarity with Ruby.
Could the defaults for jekyll-scholar or bibtex be referred to elsewhere besides storing it in
site.config
? (jekyll-scholar/bibtex could then check whether the key exists in site.config, otherwise use the default class variable.)