process.entry() could be quite useful to the user if it was more self contained. Currently the functionality is spread through three functions. Suggest moving the following code into process.entry() to allow the user to have a more flexible experience when developing, i.e.
# selectively process data source entries
entries <- bibtex::read.bib("bootstrap/DATA.bib") # could be e.g. taf.sources(type = "data")
process.entry(entries[2])
# use key to access entry
process.entry(entries$datras)
if (inherits(bib, "bibentry")) {
# strip outer bibentry class container
bib <- unclass(bib)[[1]]
}
this will mean the process.bibfile will simply be a loop over the entries with some checks in place for duplicates, and maybe some cleaning (see below).
This also raises the idea that process.entry() may have some clean and force arguments to allow selective forcing and cleaning of sections. This would be useful for example, if a user had written a rentrant data script where files are only downloaded if it is not already present.
entries <- taf.datasources()
# re-process datras.R to download missed data files
process.entry(entries$datras, clean = FALSE, force = TRUE)
colinpmillar
commented
4 years ago
process.entry()could be quite useful to the user if it was more self contained. Currently the functionality is spread through three functions. Suggest moving the following code intoprocess.entry()to allow the user to have a more flexible experience when developing, i.e.lines to move:
will also need to add to head of
process.entry(),this will mean the
process.bibfilewill simply be a loop over the entries with some checks in place for duplicates, and maybe some cleaning (see below).This also raises the idea that
process.entry()may have some clean and force arguments to allow selective forcing and cleaning of sections. This would be useful for example, if a user had written a rentrant data script where files are only downloaded if it is not already present.