As the project matures, it would be wise to fully automate the core scripts in /bin so that a user can run them without any intervention. This would ideally include pulling of the data, not just processing. This will likely require the addition of some non-R layer.
As of now, one simple issue that cannot be fully resolved is the setting of a valid working directory for the user. Attempts at using the package here fall short because it locks itself onto the working directory set when the library is first loaded (meaning if a user is warned they need to change their working directory and they comply, later uses of the here() function will not behave as they might expect, since it will still be holding on to whatever the original working directory was). Other options such as relying on .Rproj files would introduce a RStudio dependency.
All of this can be resolved nicely by adding a simple non-R layer atop the final codebase.
As the project matures, it would be wise to fully automate the core scripts in /bin so that a user can run them without any intervention. This would ideally include pulling of the data, not just processing. This will likely require the addition of some non-R layer.
As of now, one simple issue that cannot be fully resolved is the setting of a valid working directory for the user. Attempts at using the package
here
fall short because it locks itself onto the working directory set when the library is first loaded (meaning if a user is warned they need to change their working directory and they comply, later uses of thehere()
function will not behave as they might expect, since it will still be holding on to whatever the original working directory was). Other options such as relying on .Rproj files would introduce a RStudio dependency.All of this can be resolved nicely by adding a simple non-R layer atop the final codebase.
For an example of the issue: https://hrdag.org/tech-notes/harmful.html#the-working-directory-thing