baumer-lab / fertile Goto Github PK

• Input functions from tidyverse (read_csv(), etc.) and read.csv()
• Output functions (write_csv(), write.csv(), etc.)
• library() and require() (@hadley)
• source()

Do a handful of these manually, and then consider a function factory or some kind of tidy evaluation.

Log the paths and calls to a CSV file (i.e., .fertile.csv)

In interactive mode, throw an error if the path is bad.

Have a sliding scale of strictness

when generating install scripts for called packages, check to see which ones come from CRAN and which are from GitHub (only CRAN packages should be generated into the script)

• a tibble
• with columns file, line?, problem, solution
• methods: print()

This is happening everywhere. I think it's because we expect the path variable in the log file to be character, but sometimes we set it to fs_path. Need to fix.

• when you call a library, but don't use it
• when you have data files that you don't load
• when you have script files that you don't execute

Suppose I am in a subdirectory of the project. Then ../data.csv could be a relative path to a file that exists within the project. Should this generate an error?

Warning: Topic 'has_tidy_media': no parameters to inherit with @inheritParams
* Topic 'has_tidy_images': no parameters to inherit with @inheritParams
* Topic 'has_tidy_code': no parameters to inherit with @inheritParams
* Topic 'has_tidy_raw_data': no parameters to inherit with @inheritParams
* Topic 'has_tidy_data': no parameters to inherit with @inheritParams
* Topic 'has_tidy_scripts': no parameters to inherit with @inheritParams
* Topic 'has_readme': no parameters to inherit with @inheritParams
* Topic 'has_proj_root': no parameters to inherit with @inheritParams
* Topic 'has_no_nested_proj_root': no parameters to inherit with @inheritParams
* Topic 'has_only_used_files': no parameters to inherit with @inheritParams
* Topic 'has_no_absolute_paths': no parameters to inherit with @inheritParams
* Topic 'has_only_portable_paths': no parameters to inherit with @inheritParams
* Topic 'has_no_randomness': no parameters to inherit with @inheritParams
* Topic 'has_no_lint': no parameters to inherit [... truncated]
Warning: Topic 'proj_test': no parameters to inherit with @inheritParams
* Topic 'proj_analyze': no parameters to inherit with @inheritParams
* Topic 'proj_analyze_files': no parameters to inherit with @inheritParams
* Topic 'proj_suggest_moves': no parameters to inherit with @inheritParams
* Topic 'proj_move_files': no parameters to inherit with @inheritParams
* Topic 'proj_analyze_pkgs': no parameters to inherit with @inheritParams
* Topic 'proj_analyze_paths': no parameters to inherit with @inheritParams

It must be related to the way that multiple function are documented on the same help page. Maybe is has something to do with the sections?

> library(fertile)
> assets <- read_csv(here::here("assets.csv"))
Checking for absolute paths...
Error: Detected absolute paths
Run `rlang::last_error()` to see where the error occurred.

This seems bad, because the user is following best practices by using here(), but fertile doesn't see that -- it just gets the absolute path.

What can we do about this @ambertin ?

## ● Checking for README file(s) at root level
##    Problem: No README found in project directory
##    Solution: Create README
##    See for help: ?fs::file_create
## # A tibble: 1 x 2
##   culprit   expr                        
##   <chr>     <glue>                      
## 1 README.md fs::file_create('README.md')

The advice should probably be usethis::use_readme(), right?

https://www.practicereproducibleresearch.org/

At the 2017 rOpenSci unconf, a group of us worked on the checkers project, which had some overlapping goals. It hasn't been worked on actively in awhile, but might be interesting to check out as you work on this project!

(thanks @hfrick and @jennybc for making the connection!)

• Maybe have a YAML file with sensible defaults
• Provide an rticles/usethis-style set of templates for certain projects
  • maybe a journal would have their own layout
  • or Project TIER might have their own
  • or a company might have their
  • or an instructor might have their own

Or, better, use rlang::abort() — this avoids repeating the function name in the error message.

Things that are ok:

• Single file
• Prefixes are numbers
• Uses drake or make

To avoid messages

(https://github.com/dreamRs/prefixer)

Not sure how we would use this...

set option in ui_code_block()

SQLite seems like the "right" tool, but is the overhead worth it?

incorporate lintr and stylr functionality

Good test projects:

• range in complexity
• do good and bad things
• are small in terms of file sizes
• don't take a long time to execute
• mimic real world projects

Check the logs here:

https://travis-ci.org/baumer-lab/fertile/jobs/595604288

Remember that this is running on a plain vanilla machine with no packages or files installed other than the ones we specify in the package.

If not present, should warn that code might not be reproducible.

proj_report() returns a fertile, tibble. Think about the best way to make print.fertile() return something readable, understandable, and helpful.

There should be only one, and located in project root.

Installed the package and ran library(fertile). Received this error.

Improve proj_analyze() to make more (helpful) suggestions about where you should move your files.

• Is requirements headed to CRAN?
• Can the code we need be lifted (with attribution) and placed in fertile?
• Could we add an if (!require(requirements)) clause to the place where we use it?

report(): read from the hidden CSV and tell you what is in there.

@jennybc says:

I do a casual install_github("this/that") and find that the bleeding edge version of something I inadvertently updated is a bit broken and I want to roll it back. I wish it were easy to see a log of recent upgrade events with “X.Y.Z -> “X*.Y*.Z*” or “SHA_before --> SHA_after” type of info.

See also #3

• takes a path
• checks to see if the file path actually exists within the project tree
• return logical

Rough guess of what you need to do:

1. Use rlang::call_stack() to get list of all calls leading to logging function
2. Figure out how many levels you need to go back (maybe can do that by looking at a srcrefs so should actually happen after next step)
3. Extract srcrefs somehow

Also look at rlang::trace_back() which should be capturing the srcrefs

In various discussion around safe path practices, many people insist that they simply must refer to paths outside the project. I bet a lot of this can be eliminated but I also accept you can't completely design this problem away.

This solution presented by @HenrikBengtsson makes a 💡 go on for lots of people and I think you should have it on your radar here. Either helping people to implement it or providing it as a suggested remedy.

https://community.rstudio.com/t/project-oriented-workflow-setwd-rm-list-ls-and-computer-fires/3549/35?u=jennybryan

@jennybc says:

The name collision between fertile::check() and devtools::check() gives me pause. I guess it could be seen as a positive? But I think it's more negative.

How about fertile::proj_check()?

How do we keep track of where the log file goes? At @jennybc 's suggestion I am using rprojroot to find the project directory, but to return the working directory if find_root() fails.

But if somebody just tries to use read_csv(), we can't control whether they are in a project or what the working directory is at the time of the call. So to which log file should that event be written?

Symptom: devtools::test() currently returns 0 errors, but devtools::check() returns 3.

How about the various build alternatives jive with Travis?

When running the following lines of code, devtools::test() fails with this error:

dir <- test_path() # "tests/testthat"
temp <- sandbox(dir)

Why is test_path() an invalid directory to delete? Is there a function that dir_delete can be replaced with in sandbox that will allow us to delete test_path()?

Allows any dangerous code to run without warnings:

danger({
  x <- read.csv("~/a/path/that/only/exists/on/hadleys/computer.csv")
})

Using https://github.com/hadley/requirements

Should we shim tbl() and then warn if the src argument is a DBIConnection?

When running the "danger works" test line by line, each line passes successfully. However, when running devtools::test(), the following error occurs:

It appears to possibly a problem where we are unable to detach fertile while running test()

Reference code is given below:

danger <- function(expr) {
detach("package:fertile", unload = TRUE)
on.exit(require("fertile"), add = TRUE)
invisible(expr)
}

test_that("danger works", {
wd <- getwd()
expect_error(setwd(tempdir()), "setwd")
expect_message(danger(setwd(path_real(tempdir()))), "fertile")
expect_equal(path_real(getwd()), path_real(tempdir()))
base::setwd(wd)
})

If a has_*() function, for example, has_only_portable_paths() requires compilation, then what is the best way to check if the project needs to be re-compiled?

In check(), we are going to run a bunch of these, so we compile once first, then do the checks. But if you just want to run one of these functions as a one-off, how is it supposed to know whether the log file accurately captures what happens during compilation? If we allow each function to trigger proj_render(), then this will be horribly inefficient.

by doing things in order, and in isolated sesssions.

Like this: https://github.com/beanumber/fertile/blob/84e85ea4f648f6faf124d0dd56f13576a70a5f5b/R/shims.R#L17

?? @hadley @jennybc