Relative dependencies closer to root than an output html

[jrounds]

This when generating html this yaml errors when the lib_dir line is included (but not when the css line is included, so is it not checked in the same way?) Which leads to the question is there an rmarkdown idiomatic way to include a lib directory closer to root than the output? Is there someway to disable the check that errors? Thanks.

---
output:
  html_document:
    theme: readable
    self_contained: false
    css: ../../style.css
    lib_dir: ../../lib
    toc: true
    toc_depth: 2
    date: "`r format(Sys.time(), '%d %B, %Y')`"

---

Error message and call stack

> debugger()
Message:  Error in relativeTo(basepath, dir) : 
  The path /media/sf_work/15spring/lib/jquery-1.11.0 does not appear to be a descendant of /media/sf_work/15spring/weake_aging/04_03_edgeR/go_html_reports/GO_0006310/
Available environments had calls:
1: render("11_go_template.Rmd", output_dir = out_dir, output_file = out_file)
2: output_format$pre_processor(yaml_front_matter, utf8_input, runtime, knit_me
3: base(...)
4: pandoc_html_extras_args(extras, self_contained, lib_dir, output_dir)
5: as_tmpfile(html_dependencies_as_string(dependencies, lib_dir, output_dir))
6: html_dependencies_as_string(dependencies, lib_dir, output_dir)
7: lapply(dependencies, makeDependencyRelative, output_dir)
8: FUN(X[[1]], ...)
9: relativeTo(basepath, dir)
10: stop("The path ", file, " does not appear to be a descendant of ", dir)

[jrounds]

#146

Did this use-case sit for a year with no viable workaround except spamming symbolic links after the fact, or did you push something in the mean time to address it? That closed thread claimed the lib_dir would be relative to the .Rmd and that is not the case, it would be relative to the html being generated. I suppose it is easy enough to do a " find .html -exec ". Plus while writing this I made the sub-directories flatter, so I would need only one symbolic link, so I guess closing, but still interested in if there is a better way to do this yet?

If you want to know the business use-case it is this:

Suppose you are generating 100s of reports each of which is a detail link in a master top level report, and each of which needs style files. If you put self-contained false you get 300mb of style files for 100 reports. Needless. The actual use case in the example I am working on is a top level report on all gene-ontologies in an RNA-seq experiment, and the sub-reports are specific gene-ontologies with specific gene details. The top report and the sub-report should ideally share a lib directory, and there are 100s of gene-ontologies so it makes no sense to duplicate lib directories for each report.

Such a file organization is

top_level_report.html
lib_dir/
style.css
sub_level/
     sub_report1.html
     sub_report2.html

created with 2 .Rmd

top_level_report.Rmd
sub_report.Rmd

sub_report.Rmd can handle multiple repeated outputs through an R global environment variable, and output_dir and output_file arguments of render support placing sub_report1.html and sub_report2.html in the appropriate output directory, but is there no way to have a yaml reference the lib_dir above them?

Right now the work around is just put sub_level/symbol_link. Which is viable. Closing.

[jjallaire]

I think the workaround you have is the right one. There are a lot of different codepaths that hit lib_dir so any change we make has some regression risk. Not saying we can't/won't change the behavior but it has to be done carefully and ideally with some more tests in place.

[rubenarslan]

Would love to see this reopened, along with the possibility of setting output_dir in the YAML front matter. The workarounds are tedious and symbolic links don't fix the issue of duplication on the web.

[github-actions]

This old thread has been automatically locked. If you think you have found something related to this, please open a new issue by following the issue guide (https://yihui.org/issue/), and link to this old issue if necessary.