ezknitr package

[daattali]

• 1. What does this package do? (explain in 50 words or less)

Allows you to use 'knitr' with complex directory structures and gives you more control over where inputs/outputs/figures/scripts live when knitting documents. Real research projects often don't have a flat directory structure, which can make using 'knitr' on such projects very cumbersome.

• 2. Paste the full DESCRIPTION file inside a code block below.

Package: ezknitr
Title: Avoid the Typical Working Directory Pain When Using 'knitr'
Version: 0.4
Authors@R: person("Dean", "Attali", email = "daattali@gmail.com",
    role = c("aut", "cre"))
Description: An extension of 'knitr' that adds flexibility in several
    ways. One common source of frustration with 'knitr' is that it assumes
    the directory where the source file lives should be the working directory,
    which is often not true. 'ezknitr' addresses this problem by giving you
    complete control over where all the inputs and outputs are, and adds several
    other convenient features to make rendering markdown/HTML documents easier.
URL: https://github.com/daattali/ezknitr
BugReports: https://github.com/daattali/ezknitr/issues
Depends: 
    R (>= 3.0.2)
Imports: 
    knitr (>= 1.7),
    markdown (>= 0.7),
    R.utils (>= 1.34.0)
Suggests: 
    testthat (>= 0.9.1),
    rmarkdown
License: MIT + file LICENSE
SystemRequirements: pandoc with https support
LazyData: true
VignetteBuilder: knitr
RoxygenNote: 5.0.1

• 3. URL for the package (the development repository, not a stylized html page)

https://github.com/daattali/ezknitr

• 4. What data source(s) does it work with (if applicable)?

N/A

• 5. Who is the target audience?

Any researcher or grad student who wants to better automate and organize their research using knitr but find it annoying/impossible to deal with directories in a sane way

• 6. Are there other R packages that accomplish the same thing? If so, what is different about yours?
  • rmarkdown has support for parameters in Rmd documents. One of the features that ezknitr offers is the ability to pass parameters to Rmd files. There is a difference between the two: rmarkdown assumes that the parameters are defined in the Rmd YAML, while ezknitr lets you change any arbitrary variable. This difference is not too significant, but the main reason ezknitr has this feature is to support older Rmd files that don't have YAML because the introduction of parameterized Rmd files is fairly new
  • rprojroot provides a very different solution to a related problem. rprojroot helps you find a specific file in relation to a project's root directory, while ezknitr is specifically for dealing with knitting documents in complex directory structures
• 7. Check the box next to each policy below, confirming that you agree. These are mandatory.
  • This package does not violate the Terms of Service of any service it interacts with.
  • The repository has continuous integration with Travis CI and/or another service
  • The package contains a vignette
  • The package contains a reasonably complete README with instructions for installing the development version.
  • The package contains unit tests
  • The package only exports functions to the NAMESPACE that are intended for end users
• 8. Do you agree to follow the rOpenSci packaging guidelines? These aren't mandatory, but we strongly suggest you follow them. If you disagree with anything, please explain.
  • Are there any package dependencies not on CRAN?
  • Do you intend for this package to go on CRAN?
  • Does the package have a CRAN accepted license?
  • Did R CMD check (or devtools::check()) produce any errors or warnings? If so paste them below.

Yes, I will follow those guidelines. The package is already on CRAN.

• 9. Please add explanations below for any exceptions to the above:

N/A

• 10. If this is a resubmission following rejection, please explain the change in circumstances.

N/A

• UPDATE 11. JOSS publication
• Do you wish to automatically submit to the Journal of Open Source Software? If so:

  • The package contains a paper.md with a high-level description.

    yes, I included paper.md under /inst/joss/

  • The package is deposited in a long-term repository with the DOI:

    figshare 10.6084/m9.figshare.3545363

[noamross]

Thanks for the submission, @daattali. I'll be your handling editor. I'll do editor's checks this week before assigning reviewers.

[karthik]

I'm happy to review.

[noamross]

Hi @daattali, could you comment on Question 6 above re: overlapping packages? As you note in the README, there's some feature overlap with rmarkdown. Also rprojroot provides an alternative solution for the working directory issue. Neither of these preclude acceptance of ezknitr, but we'd like your take on the advantages/disadvantages of your approach and which use-cases it is most appropriate for, which will help reviewers give feedback.

[daattali]

@noamross you're absolutely right, I edited Q6

[noamross]

Thanks @daattali. Seeking a second reviewer. Everyone is at UseR! So it may take slightly longer ;)

[noamross]

Reviewers: @karthik @ttimbers
Due date: 2016-07-21

[ttimbers]

Package Review and Comments

Overall this package looks really good. It solves an important limitation of the knitr package; managing knitting and spinning files located in different directories, as well as providing the flexibility and control over where the output files are saved to. Everything worked well on my machine, and my review and comments are mainly in respect to improving documentation and style to match what is expected of rOpenSci packages.

Please check off boxes as applicable, and elaborate in comments below. Your review is not limited to these topics, as described in the reviewer guide

• As the reviewer I confirm that there are no conflicts of interest for me to review this work (such as being a major contributor to the software).

Documentation

The package includes all the following forms of documentation:

• A statement of need clearly stating problems the software is designed to solve and its target audience in README
• Installation instructions: for the development version of package and any non-standard dependencies in README
• Vignette(s) demonstrating major functionality that runs successfully locally
• Function Documentation: for all exported functions in R help
• Examples for all exported functions in R Help that run successfully locally
• Community guidelines including contribution guidelines in the README or CONTRIBUTING, and URL, Maintainer and BugReports fields in DESCRIPTION

Documentation comments

• To make the README.md even more useful for all audiences (especially for those who are newer to R) it would be useful to have a 1-2 sentences in the first paragraph to describe the purpose/role of knitr in the README.md before ezknitr is defined as an extension of knitr. It would also be good to link to the knitr package documentation from your README.md file when you reference it.
• To access the setup_ezknit_test or setup_ezspin_test example or documentation within R you have to load the library via library(ezknitr) after installing to get setup_ezknit_test(), setup_ezspin_test(), or ?setup_ezknit_test to work. This should be clarified in the documentation.
• In general, the examples are really good, and clearly illustrate how you can use the package. They all ran locally, without error, on my machine.
• It would be nice to have a function or provide a command to the user to clean up after each of the examples in setup_ezknit_test() and setup_ezspin_test(). This would make it easier for the user to understand what the different commands do.
• There is a vignette associated with the package, located in the vignettes directory, but I could not access it locally within R using browseVignettes("ezknitr") or by using vignette(package = "ezknitr") within R. I can also access the vignette through this link on CRAN: https://cran.r-project.org/web/packages/ezknitr/vignettes/overview.html. If not too much work, it would be nice to have the vignette appear within R using both browseVignettes("ezknitr") and vignette(package = "ezknitr").
• rOpenSci footer image is not yet included (this is my first time reviewing a package, so maybe this need not be included until after acceptance?)
• There is no README.Rmd file, only a README.md file in the repository on Github, which leads me to believe the README.md was created directly, and not via rendering of an README.Rmd file. rOpenSci recommends creating a README.md from a README.Rmd file where possible because.
• Currently there is no documentation on contribution guidelines. These should be included in either the README or in a file called CONTRIBUTING. Additionally, although the URL and BugReports fields are present in DESCRIPTION, the Maintainer field is missing. There is also no Code of Conduct. rOpenSci recommends that you use a code of conduct such as the Contributor Covenant in developing your package.
• Although the package uses semantic versioning on CRAN, there are no release tags for these versions on Github. Please add these.

Functionality

• Installation: Installation succeeds as documented.
• Functionality: Any functional claims of the software been confirmed.
• Performance: Any performance claims of the software been confirmed.
• Automated tests: Unit tests cover essential functions of the package
  and a reasonable range of inputs and conditions. All tests pass on the local machine.
• Packaging guidelines: The package conforms to the rOpenSci packaging guidelines

Functionality comments

• The code appears to be efficient, and the usage of each function is clear. There is no code duplication in the package that should be reduced.
• I might be tempted to split the ezknitr_helper() function into at least two functions, one that figures out all the paths, and one that uses that information to call the knitr::spin() or knitr::knit() function. This is not essential, but it might make future development easier (e.g., if you decide in the future to set the paths some other way).
• In general, edge cases have been considered for most functions. In the function ezknitr_helper(), the edge case of someone passing out_suffix a value indexed outside of a list is not considered. For example, if you had a list called mylist of length 3, and you set out_suffix = mylist[4] then suffix would become NA. I wonder if this is a desired behaviour?
• There is a good coverage of tests (a reasonable range of inputs and conditions) using testthat for the two core functions (ezspin() and ezknit()) and the set_default_params() function.
• There are no tests for the open_output_dir() or set_default_params() functions. open_output_dir() is not an essential function, and so maybe it is OK that there are no tests for it?
• Although much of the code implements snake_case, there are some occurrences of variable names using lowerCamelCase. Examples from ezknitr_helper() include: fileName, fileRmdOrig, fileRmd, fileMd, fileHtml, oldOptsKnit, oldOptsChunk, and fullFigPath.

Future functionality ideas:

• It would be great if reports were also generated in PDF. One reason that this would be is useful is that although html renders LaTex, html does not render on Github. Markdown, renders nicely on Github, but it does not render the embedded LaTeX. PDFs are great because they do both. Additionally, PDFs are great documents to share with non-coding collaborators.
• How might this interface with the new R Notebooks? Apologies for the open-ended question in a review, but I am curious and can't help asking.

---

Estimated hours spent reviewing: 4 hrs

---

[daattali]

Thanks @ttimbers , great and thorough review! I'll wait until @karthik submits his review to respond and take action

[sckott]

@karthik
Due date: 2016-07-21 - hey there, it's been 27 days, please get your review in soon, thanks 😺 (ropensci-bot)

[daattali]

@sckott cool bot! What service are you using?

[sckott]

@daattali some bespoke ruby https://github.com/ropenscilabs/heythere/

[ropenscibot]

@karthik
Due date: 2016-07-21 - hey there, it's been 32 days, please get your review in soon, thanks 😺 (ropensci-bot)

[daattali]

Can I retroactively add the "automatic publishing to JOSS" info?

[sckott]

I think so, sound okay @noamross

[daattali]

I have updated the initial post in this thread and added an 11th bullet point mentioning that I want to submit to JOSS. Perhaps @ttimbers and @karthik can take a quick look at that and give their opinion on that as well? I believe it should take no longer than a few minutes. Thanks!

[ttimbers]

Just getting back from vacation, will attend to this in the next few days.

[daattali]

No rush, still waiting for Karthik for his review till I respond to yours:)
On Aug 10, 2016 7:56 AM, "Tiffany Timbers" notifications@github.com wrote:

Just getting back from vacation, will attend to this in the next few days.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#56 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA6IFNGuAhldOt8LXlYfjF2crb_GMPOSks5qeeaagaJpZM4I-UOm
.

[karthik]

The package includes all the following forms of documentation:

• A statement of need clearly stating problems the software is designed to solve and its target audience in README
• Installation instructions: for the development version of package and any non-standard dependencies in README
• Vignette(s) demonstrating major functionality that runs successfully locally
• Function Documentation: for all exported functions in R help
• Examples for all exported functions in R Help that run successfully locally
• Community guidelines including contribution guidelines in the README or CONTRIBUTING, and URL, Maintainer and BugReports fields in DESCRIPTION

Paper (for packages co-submitting to JOSS)

The package contains a paper.md with:

• A short summary describing the high-level functionality of the software
• Authors: A list of authors with their affiliations
• A statement of need clearly staing problems the software is designed to solve and its target audience.
• References: with DOIs for all those that have one (e.g. papers, datasets, software).

Functionality

• Installation: Installation succeeds as documented.
• Functionality: Any functional claims of the software been confirmed.
• Performance: Any performance claims of the software been confirmed.
• Automated tests: Unit tests cover essential functions of the package
  and a reasonable range of inputs and conditions. All tests pass on the local machine.
• Packaging guidelines: The package conforms to the rOpenSci packaging guidelines

Final approval (post-review)

• The author has responded to my review and made changes to my satisfaction. I recommend approving this package.

Estimated hours spent reviewing: 2.1

Review of ezknitr

This is an extremely useful addition to the knitr reproducible research workflow and addresses many frustrations that people have when working with projects where all assets are not self-contained.
The package installs with no issues and all tests pass correctly when I reviewed at bd92bcb. Also not duplicating any comments from @ttimbers above.

Comments

• setup_ezspin_test , setup_test_helper

I was going to suggest having a few example use cases, such as a simple report with one level nesting, a complex report (or multiple reports) with data in various places. But the setup_ezknit_test() is a nice addition. Perhaps the function could take two options (one for simple and one for complex) and spit out two workflows? Take or leave this suggestion (i.e. I would not impose it as a requirement to acceptance) but including this as a suggestion.

• set_default_params

' Sometimes it may be useful to define a variable only it hasn't been defined yet.
' One example where this can be useful is when you have an Rmd script that
' uses some variables and you want to be able to use custom values for these
' variables, but also give them a default value in the script in case they are
' not set beforehand.

The function itself does not check to see if these variables have been defined in a document. If I understand correctly, you are asking the user to use exists to first check, then set these as defaults (which could be overwritten by passing new args, right?). If so, couldn't the function itself check to see if those variable s exist and throw a warning/error if not (which could be overridden)?

set_default_params <- function(params) {
  params <- as.list(params)
  env <- parent.frame(1)

  invisible(
    lapply(names(params), function(key) {
      if (!exists(key, envir = env, inherits = FALSE)) {
      # ^ Is this not supposed to work outside of ezknit?
        assign(key, params[[key]], envir = env, inherits = FALSE)
      }
    })
  )
}

Also, rather than point out that rmarkdown has solved this issue with yml further down, perhaps you could move that up here?

All other functionality looks as expected.

Other suggestions for improvement

Now if you want knitr to work, you'd have to ensure the path to input.csv is relative to the analysis/ directory. This is counter-intuitive because most people expect to create paths relative to the working directory (project/ in this case), but knitr will use the analysis/ folder as the working directory. Any code reading the input file needs to use ../data/input.csv instead of data/input.csv.

This came off as a bit confusing to me at first. Perhaps you could say project root to keep it more general?

We didn't explicitly have to set the working direcory, but you can use the wd argument if you do require a different directory.

Perhaps you can say why this might be useful to do. E.g. if someone is doing this from a makefile or another build script, this could be the way to not worry about where that file resides (and wd will be set explicitly.)

Let's assume that each analysis script expects there to be a variable named DATASET_NAME that tells the script what data to operate on.

When reading the README, it is not clear if the variable DATASET_NAME would be set in the yml or the knitr document itself. It is the latter, but it would be good to spell out and perhaps even include a little code snippet.

knit() is the most popular and well-known function from knitr. It lets you create a markdown document from an Rmarkdown file. I assume if you are on this page, you are familiar with knit() and Rmarkdown, so I won't explain it any further.

Suggest linking out to Yihui's page in case such a person is reading.

Review of the JOSS paper

Could you switch the first two sentences with a bit of a rewrite? Start of with why knitr has been so useful in the R community and what it has enabled? Then point out shortcomings and what ezknitr enables?

typo: adresses

Once this is fixed, I will check off the last approval box.

Overall comments

I think this is a nice addition to the rOpenSci suite and recommend acceptance. 💯🚀

[noamross]

Thanks @karthik! Could you prepend the reviewer checklist to
your review, and also comment on paper.md? This will likely be our first
test of the JOSS pass-through.

On Fri, Aug 12, 2016, 5:12 PM Karthik Ram notifications@github.com wrote:

Review of ezknitr

This is an extremely useful addition to the knitr reproducible research
workflow and addresses many frustrations that people have when working with
projects where all assets are not self-contained.
The package installs with no issues and all tests pass correctly when I
reviewed at bd92bcb. Also not duplicating any comments from @ttimbers
https://github.com/ttimbers above.

Comments

• setup_ezspin_test , setup_test_helper

I was going to suggest having a few example use cases, such as a simple
report with one level nesting, a complex report (or multiple reports) with
data in various places. But the setup_ezknit_test() is a nice addition.
Perhaps the function could take two options (one for simple and one for
complex) and spit out two workflows? Take or leave this suggestion (i.e. I
would not impose it as a requirement to acceptance) but including this as a
suggestion.

• set_default_params

' Sometimes it may be useful to define a variable only it hasn't been
defined yet.
' One example where this can be useful is when you have an Rmd script that
' uses some variables and you want to be able to use custom values for
these
' variables, but also give them a default value in the script in case they
are
' not set beforehand.

The function itself does not check to see if these variables have been
defined in a document. If I understand correctly, you are asking the user
to use exists to first check, then set these as defaults (which could be
overwritten by passing new args, right?). If so, couldn't the function
itself check to see if those variable s exist and throw a warning/error if
not (which could be overridden)?

set_default_params <- function(params) {
params <- as.list(params)
env <- parent.frame(1)

invisible(
lapply(names(params), function(key) {
if (!exists(key, envir = env, inherits = FALSE)) {
# ^ Is this not supposed to work outside of ezknit?
assign(key, params[[key]], envir = env, inherits = FALSE)
}
})
)
}

Also, rather than point out that rmarkdown has solved this issue with yml
further down, perhaps you could move that up here?

All other functionality looks as expected.

Other suggestions for improvement

Now if you want knitr to work, you'd have to ensure the path to input.csv
is relative to the analysis/ directory. This is counter-intuitive because
most people expect to create paths relative to the working directory
(project/ in this case), but knitr will use the analysis/ folder as the
working directory. Any code reading the input file needs to use
../data/input.csv instead of data/input.csv.

This came off as a bit confusing to me at first. Perhaps you could say project
root to keep it more general?

We didn't explicitly have to set the working direcory, but you can use the
wd argument if you do require a different directory.

Perhaps you can say why this might be useful to do. E.g. if someone is
doing this from a makefile or another build script, this could be the way
to not worry about where that file resides (and wd will be set
explicitly.)

Let's assume that each analysis script expects there to be a variable
named DATASET_NAME that tells the script what data to operate on.

When reading the README, it is not clear if the variable DATASET_NAME
would be set in the yml or the knitr document itself. It is the latter, but
it would be good to spell out and perhaps even include a little code
snippet.

knit() is the most popular and well-known function from knitr. It lets you
create a markdown document from an Rmarkdown file. I assume if you are on
this page, you are familiar with knit() and Rmarkdown, so I won't explain
it any further.

Suggest linking out to Yihui's page in case such a person is reading.
Overall comments

I think this is a fantastic addition to the rOpenSci suite and recommend
acceptance. 💯🚀

https://camo.githubusercontent.com/8a74cf50d69735fd3ffc9af05f6351e1e11f3614/68747470733a2f2f646c2e64726f70626f7875736572636f6e74656e742e636f6d2f752f323232333431312f676966732f686f7769646f696e7465726e65742e676966

—
You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
#56 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAi5aLCD0dLdASP7DBEcfBnsN-vOhYTiks5qfOGzgaJpZM4I-UOm
.

[daattali]

Thanks for taking your time to review this @karthik and @ttimbers

I've updated ezknitr based on all your comments, let me know if you have any further comments

[karthik]

Thank you @daattali
LGTM @noamross 👍 💯

[daattali]

Sorry, I just noticed that I forgot to add all my comments (I had them sitting in a text file -- it 'd be awesome if GitHub supported "saving drafts" of comments). I added/improved everything that was suggested, but here are some comments about things that I didn't change:

@ttimbers

I thought about adding a cleanup function but decided against it because depending on what function the user runs, files and folders will get generated in different places and they can run any arbitrary command so I can't know what exactly to clean without making a lot of assumptions

browseVignette: I think if you install the package from CRAN or GitHub then you will see the vignettes, it's only when you install using devtools that the vignettes don't get built/linked r-lib/devtools#931

README.Rmd - I chose to stick with just a direct README.md because I don't have code chunks. If in the future I'll have R code chunks that will benefit from Rmd -> md then I'll change it

out_suffix: if you try to assign it an NA value , then the function will fail with an informative error message ("Error: out_suffix is not a valid string"). I believe this is the correct behaviour. Maybe you meant something else?

open_output_dir has no test because all it does is a side effect that is (impossible? super extremely hard?) to test. I don't know of any way to test that a function caused the OS file explorer to open. set_default_params() does have tests https://github.com/daattali/ezknitr/blob/master/tests/testthat/test-set_default_params.R

compiling to PDF: as far as I know, there isn't any special function to do that, right? You just need to use pandoc? I'm open to a pull request or an issue being opened but I don't have any experience making PDF so I prefer to leave it as a future improvement.

I haven't actually played around with notebooks too much, but I don't think it will be able to interact with notebooks because notebooks seem like they use knitr under the hood (I think - I don't actually know its internals) which means they'll still have the usual work directory problems

@karthik

set_default_params: the user does not need to make any checks themselves. All the user does is pass in a named list, and every key in the list will be treated as a variable name. Every variable name that currently doesn't exist will get created and assigned the value from the list. The function doesn't need to explicitly check for existence using "exists()" because I do use exists() inside the loop structure to see if an incoming variable exists or not.

set_default_params WILL work in any context, not just in ezknitr. you can try it yourself: assign 'x <- 5', then call 'set_default_params(list(x=10, y=20))'. Hopefully x will remain untouched but y will be 20

PS. SO COOL that you can have a little Details bar that collapses/expands on click!

[ttimbers]

@daattali, my comments to your comments:

1. Fair enough justification for not adding a clean-up function.
2. You are correct (and thanks for informing me!) that vignette and browseVignette work only when packages are installed from CRAN. When I install ezknitr from CRAN, and then run browseVignettes("ezknitr") I get directed to a useful webpage where I can access a link ("HTML") to the vignetter (although it might be better to just be taken to the HTML version of the vignette as the other links are not very useful - if this is possible). On the other hand, vignette(package = "ezknitr") doesn't seem very helpful in its current implementation. When run is outputs what is pasted below to the editor.

I know that these calls are using an older version of the ezknitr package (the one on CRAN), but presumably you will put this reviewed version of the package on CRAN and it would be great to have vignette(package = "ezknitr") functional.

Vignettes in package ‘ezknitr’:

overview                     Package ezknitr (source, html)

1. As long as ROpenSci is OK with you using a direct README.md, that is fine with me. I commented on it, as they recommend the use of README.Rmd knit to README.md over a direct README.md. @noamross maybe you can comment on how strict ROpenSci is with this?
2. OK that out_suffix is giving you the desired output. I just wanted to check.
3. Fair enough that open_output_dir has no test because it is too difficult to do. Also, apologies that I missed the tests for set_default_params, I now see that they exist.
4. I do still think that because users are used to being able to knit to PDF with knitr, that users might want and expect this functionality from ezknitr. Especially users who are used to only working in R, and have never run command line programs, such as pandoc. I also appreciate that this may be beyond the scope of the current development stage of the ezknitr package and can be left for future development.
5. Again, I appreciate integrating ezknitr with RStudio notebooks might be beyond the current scope of the ezknitr package, but thought I would mention it, as I could envision how they might function well together.

[ttimbers]

Review of the JOSS paper

Looks good to me! I recommend ROpenSci accept the paper and the package. 😃

[noamross]

Using a plain README.md is fine if there are no code chunks. I've just clarified the language in the packaging guide

[noamross]

Approved! This will be our first JOSS pass-through package to reach this stage of the process. Allow me to pre-apologize for any snafus along the way. Here are the remaining steps, @daattali:

• Close any other outstanding issues if you'd like. (I'll do a final editor's check if you choose to include markdown or PDF output in this release.)
• Add the rOpenSci footer to the README
• Transfer to the repo to rOpenSci
• Update the figshare repo to match the ropensci-accepted version.
• Fill out the form at http://joss.theoj.org/papers/new to submit to JOSS. We will flag the package to let the editor know they may accept based on this review history.

[daattali]

@ttimbers

I think the behaviour you're seeing from both browseVignettes("ezknitr") and vignette(package = "ezknitr") is unfortunately the correct behaviour of those functions, even if it doesn't seem super useful. I tried replacing "ezknitr" with "tidyr" to verify, and I get the same results

Re: knitting to PDF: I would happily add support for ezknit to pdf, but does knitr::knit have support for that in the first place? I never do PDF myself so I don't know how people do it. I tried googling it a bit and as far as I can tell, knitr does not have a way to convert to PDF, only rmarkdown::render does, which is independent from knitr.

Can you let me know if you do know of a way to convert to PDF using knitr? If not, then I'll treat this package as done for now and will go through with the next steps

[ttimbers]

Re: browseVignettes and Vignettes

tidyr is not a great example, as it does not work with vignette, I am guessing because the developers didn't implement it? Both stringr and broom work well with vignette.

Re: knitting to PDF

I guess RStudio had fooled me into thinking the "Knit PDF" button uses a function from the knitr package as opposed to the rmarkdown package...

[ttimbers]

Re: Re: knitting to PDF

It looks like in theory, you could use knitr to do this via knitr::knit to convert .Rmd to .Rrst or .Rnw, and then knitr::knit2pdf to convert the .Rrst or .Rnw to .pdf.

Although I must say, I tried this strategy and it didn't work as I ran into an error with rst2pdf (a required dependency for knitr::knit2pdf?).

Anyways, its a bit frustrating that it is not obvious to if this is what the "Knit PDF" button is doing, and if not why its says "Knit" if it is not using knitr...

[daattali]

Ohh I see what you mean about vignettes! I was under the impression you were trying to call vignette(package = "tidyr") , which lists its vignettes. You mean just calling vignette("stringr"), which shows the actual vignette. That just means that stringr has a vignette named stringr. To see the ezknitr vignette like that you would use vignette("overview", package = "ezknitr"), is that what you were trying to get at? Anyway, you're right, I never thought much about the name I was giving vignettes. I will change the vignette name to ezknitr so that it will work as you expected, and I'll also start doing it for my other packages :)

Yes the button is a bit misleading, I'm pretty sure it uses rmarkdown::render...

[daattali]

@noamross I can't transfer the repo to rOpenSci, it tells me I need admin right

Should I update all links referring to daattali/ezknitr to use ropensci/ezknitr? Will this package now and forever live under ropensci user?

[noamross]

Oh, it should be ropenscilabs you transfer to.

On Tue, Sep 13, 2016, 9:14 PM Dean Attali notifications@github.com wrote:

@noamross https://github.com/noamross I can't transfer the repo to
rOpenSci, it tells me I need admin right

—
You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
#56 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAi5aJQC-2uCHMXzW-AaaoP5KWCfSOZ7ks5qp0pjgaJpZM4I-UOm
.

[daattali]

I was just invited to ropenscilabs. Am I supposed to transfer ownership to ropenscilabs or to ropensci?

If it's the former, then will it eventually move to ropensci? Does that mean I should update all the links now to point to github.com/ropenscilabs/ezknitr and later on I'll have to update again to point to ropensci?

[sckott]

yes, but everything autoforwards

[daattali]

Sorry if this info is available elsewhere, I couldn't find it anywhere. Do packages move from ropenscilabs to ropensci in a matter of hours/days, or do they remain in labs for a long time? (So that I can maybe just skip the ropensci labs URL if it's only temporary)

[noamross]

They remain for a long time. Honestly there's little difference between the two orgs. We anticipated at one point there being a distinction based on age/stability of packages but that process hasn't really evolved and so we haven't documented it properly ([adds to todo list]). Thankfully all the URLs do forward so when it's transfered (or we re-consolidate) the links will work.

On Tue, Sep 13, 2016, 10:21 PM Dean Attali notifications@github.com wrote:

Sorry if this info is available elsewhere, I couldn't find it anywhere. Do
packages move from ropenscilabs to ropensci in a matter of hours/days, or
do they remain in labs for a long time? (So that I can maybe just skip the
ropensci labs URL if it's only temporary)

—
You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
#56 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAi5aDqp1YATMry5pzc0e1OMikVu7EfYks5qp1oigaJpZM4I-UOm
.

[daattali]

I'll do a CRAN submission and when the new version gets on CRAN I'll continue with the transfer process

[karthik]

Do packages move from ropenscilabs to ropensci in a matter of hours/days

Not a matter of hours. After the project grew and the main account was getting cluttered with mature projects and various new/half-finished/non-software repos, we started ropenscilabs. All new projects started by the rOpenSci team begin there, and all accepted projects from the community (like yours) get transferred from a personal account to there.

Like @noamross said, GitHub does a great job forwarding repos as they move around. We'll update the BugReports link when it moves later but for now it will reside in labs. We will clarify the policy.

[daattali]

I just transferred the repo and have a few comments and a question:

• It wasn't clear to me that when transferring I should see all the teams that exist in the org and choose the ezknitr team only (I assume that was the correct thing to do?)
• I'm not sure why nobody else ran into this problem before, but my travis build failed once I transferred ownership because the travis badge URL and the travis build URL had to be updated to replace daattali with ropenscilabs. So even though github does an awesome job of redirecting, it seems like other services do not
• in the JOSS submission, in the field that asks for "Repository address", should I use the GitHub repo URL or the figshare URL?

[daattali]

@noamross in the JOSS submission, for the field of "Repository address", do I enter the github repo or the figshare url?

[noamross]

1. This was the correct thing to do, thanks!
2. I'm not sure how often this happens. We need to turn on @sckott?
3. It should be the github URL.

Thanks! We're collecting the notes from these little confusions for our first few JOSS submissions.

[daattali]

Submitted to JOSS. I think I'm all done on my part, or is there anything else to do?

[noamross]

Nope! All done. I'll close this issue and keep you appraised. Expect some notifications from the JOSS side.

[sckott]

I'm not sure how often this happens. We need to turn on?

yeah, I think we need to manually turn on builds