-
Notifications
You must be signed in to change notification settings - Fork 19
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
Fix/quarto identify source files #200
Merged
wlandau
merged 17 commits into
ropensci:main
from
mutlusun:fix/quarto-identify-source-files
Nov 11, 2024
Merged
Changes from all commits
Commits
Show all changes
17 commits
Select commit
Hold shift + click to select a range
a02baac
fix(quarto-files): correctly detect source files
mutlusun f3491ce
refactor(quarto-files): deduplicate code
mutlusun e5fb3bf
fix(quarto-files): simplify input file detection
mutlusun bbf96f6
test(quarto-files): fix failing test on windows
mutlusun 2379445
test(quarto): extend tests for quarto
mutlusun 153e9ff
docs(quarto): extend comments in quarto files
mutlusun c750cc4
fix(quarto/files): try to identify duplicates in files
mutlusun 0d0fe30
test(quarto): fix ci running on windows
mutlusun 79de6eb
fix(quarto/files): remove native pipe usage
mutlusun 0dd9568
format(tests/quarto): fix lintr lints regarding line length
mutlusun 6108ec0
fix(quarto/files): correctly detect source files
mutlusun 154b86f
fix(quarto/files): detect input files correctly
mutlusun f1fdf0a
test(quarto/files): remove redundant test
mutlusun 7f918f4
versions
wlandau-lilly 4d069e4
news, docs, and fixes
wlandau f923954
add Rd file
wlandau 95d4c9e
document function
wlandau File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Oops, something went wrong.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Oops, something went wrong.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Oops, something went wrong.
Oops, something went wrong.
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As currently written, this function is based on detecting calls to
tar_read()
andtar_load()
.tar_render()
source files do not necessarily call these functions. Is there a more reliable way to detect source files? If we know they're all qmd files that will be run/rendered, can we just include all of them?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure whether I do understand your comment correctly. Is your question whether files that do not use
tar_read()
ortar_load()
are still somehow detected and used as a dependency?The doc says the following:
I followed this documentation and collected only files that have
tar_read
or atar_load
in them insources
. All other included files that do not calltar_read/load
are ininput
. See this test.To be honest, I'm not sure whether the differentiation between these three list items is necessary for targets as all of them are simply treated as file dependencies (at least this way I understand the code). In addition, it would be really easy for
tar_quarto_files
to detect which targets are loaded becausefileInformation
contains the code cells. This way, the call toknitr_deps
intar_quarto_raw
could be eliminated. But I didn't change that to not alter the interface of these functions.Did I understand your question correctly?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If your question is whether also files are detected that are included by the traditional knitr (
tar_render
) way (```{r child="file1"
): this is the case.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sources can have
tar_read()
/tar_load()
, but they don't have to, and they don't need to be distinguished from source files that don't havetar_read()
/tar_load()
.tarchetypes
just needs to know which files to scan fortar_read()
/tar_load()
using static code analysis, and it needs to know the inputs toquarto_render()
.The sources are the files scanned with
knitr_deps()
. The other input files do not necessarily even have code chunks that can beparse()
'd as valid R code.That part could be useful for just extracting the code chunks, but we already can use
knits::knit(tangle = TRUE)
, and it is a unified approach that also works with R Markdown andknitr
.Regardless of where we get the text of the code chunks,
knitr_deps()
is still needed because it runs static code analysis to robustly detecttar_load()
/tar_read()
calls and the targets that they load/read. It is much more reliable to walk the AST than manipulate text.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for your feedback and the clarifications!
Thanks for clarifying this. I did not understand the documentation in such a way. I changed the documentation to make this point clearer. Additionally, I reworked the code and the tests to reflect this. Things are much simpler now.
Regarding
knitr_deps()
: Sorry for not being clear here. My intention was not to completely remove the logic behindknitr_deps()
but to not read the files once again asquarto::quarto_inspect
has already done this. For example, one could create an AST from the code snippets provided by quarto inspect. However, in all my reports, report generation takes much longer than tarchetypes to decide whether to rerun the report or not. Thus, it probably doesn't matter and it is the easiest solution to keep everything as is.