Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: child.path #141

Closed
pank opened this issue Feb 18, 2012 · 9 comments
Closed

Feature request: child.path #141

pank opened this issue Feb 18, 2012 · 9 comments
Labels
feature Feature requests
Milestone

Comments

@pank
Copy link

pank commented Feb 18, 2012

When doing larger R project I might have a project structure like this:

figures  [dir]
sections [dir]
main.Rnw
data.dta 

I can put pictures in figures with fig.path and cache is sorted into cache.dir. It would be natural to also have a child.dir where knitr automatically looks for children.

@yihui
Copy link
Owner

yihui commented Feb 18, 2012

Currently paths of child documents are assumed to be relative to the path of parent documents, so we probably do not need an extra argument to set the path. For example,

<<set-child, child=a.Rnw;b/c.Rnw>>=
@ 

This will include two child documents a.Rnw and b/c.Rnw into the parent document, and both are under the path of the parent.

@pank
Copy link
Author

pank commented Feb 19, 2012

The point would be that you would not have to type b. In other words, b would be a search path and I would not have to write it every time. In theory, I would also be able to do

mv b c # In my terminal

and only correct it one place in my main Rnw file.

@yihui
Copy link
Owner

yihui commented Feb 19, 2012

Then you will have to write child=../a.Rnw;c.Rnw in my above case if you set the search path to be ./b/, which may not save you a lot of typing efforts. Anyway, I see your point now. The implementation should be trivial, and I will consider it. Thanks!

@yihui yihui closed this as completed in f2f682d Feb 19, 2012
@yihui
Copy link
Owner

yihui commented Feb 19, 2012

You can set opts_knit$set(child.path = 'b') now.

yihui added a commit that referenced this issue Feb 20, 2012
yihui added a commit that referenced this issue Oct 12, 2016
@stla
Copy link

stla commented Mar 12, 2017

I don't manage to use this option.

<<setup>>=
r <- system.file("rsb", "catalog", "sweave_files", package="RSBpackage00")
knitr::opts_knit$set(
  root.dir = r,
  child.path = r
)
@

Then this does not work:

<<child="child.Rnw">>=
@

But this obviously works:

<<child=paste0(r, "/child.Rnw")>>=
@

@stla
Copy link

stla commented Mar 12, 2017

I see two problems:

In readLines(if (is.character(input2)) { :
  cannot open file './C:/PortableApps/R-portable_3.3.1/App/R-Portable/library/RSBpackage00/rsb/catalog/sweave_fileschild.Rnw': Invalid argument

The first one is easy to fix: child="/child.Rnw" (the slash)

The second one is the dot here: ./C:/....

@stla
Copy link

stla commented Mar 12, 2017

A solution thanks to http://stackoverflow.com/a/36728257/1100107:

<<setup>>=
make.path.relative = function(base, target) {
  common <- sub('^([^|]*)[^|]*(?:\\|\\1[^|]*)$', '^\\1/?', paste0(base, '|', target))
  paste0(gsub('[^/]+/?', '../', sub(common, '', base)),
         sub(common, '', target))
}
r <- system.file("rsb", "catalog", "sweave_files", package="RSBpackage00")
c <- make.path.relative(getwd(), r)
knitr::opts_knit$set(
  root.dir = r,
  child.path = c
)
@

<<child="/child.Rnw">>=
@

@stla
Copy link

stla commented Mar 14, 2017

@yihui ,
This relative path causes a problem: it's not possible on Windows (I think) to do a relative path from a hard drive to another one.

@github-actions
Copy link

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.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Nov 10, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
feature Feature requests
Projects
None yet
Development

No branches or pull requests

3 participants