Skip to content
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

WIP: Move thisfile() to this package #12

Merged
merged 17 commits into from Dec 17, 2017
Merged

WIP: Move thisfile() to this package #12

merged 17 commits into from Dec 17, 2017

Conversation

krlmlr
Copy link
Member

@krlmlr krlmlr commented May 12, 2016

Fixes #8.

@bcipolli
Copy link

@bcipolli bcipolli commented Oct 15, 2017

Any chance we could help push this forward? This is an essential function for our workflow, and would love to have it available at a public package in CRAN.

@krlmlr
Copy link
Member Author

@krlmlr krlmlr commented Oct 15, 2017

Oh, kimisc is on CRAN, but I'm thinking about retiring it, because most of the functionality is available elsewhere.

@krlmlr
Copy link
Member Author

@krlmlr krlmlr commented Oct 15, 2017

Thanks. Do you have more feedback for this functionality? Happy to merge once the tests go green.

@bcipolli
Copy link

@bcipolli bcipolli commented Oct 15, 2017

This is similar (but better) to what we've been building out. so, no, looks good to me!

R/thisfile.R Outdated
#' script. This is an attempt to circumvent this limitation by applying
#' heuristics (such as call stack and argument inspection) that work in many
#' cases.
#' @details This functions currently work only if the script was \code{source}d,
Copy link
Member

@hadley hadley Oct 16, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel like this needs a stronger caveat - i.e. typically this function is not actually want. Instead you should re-think your approach.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@hadley Would love to hear instances where re-thinking the approach provides a better solution. This has seemingly come up a few times (setting up devops for automated build of R reports, as well as a robust team approach with R), where it's challenging / impossible to robustly guarantee the working directory stays as we wish.

If we can avoid it, that'd be great.. but I'm probably too new with R to rethink well myself. Any examples of rethinking the approach might help shed some light (and be helpful to end-users if added to the docs above). Thanks!

Copy link
Member

@hadley hadley Oct 16, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have no idea what you're doing, so I think it would be easier for you to describe what you're attempting to do. I'd say 90% of the cases I've seen where people are attempting to get the path of the running it script were ill-advised. Instead, it's usually better to set it outside the context of the script.

@krlmlr
Copy link
Member Author

@krlmlr krlmlr commented Dec 17, 2017

I added the caveat, and the vignette got two new examples thanks to @BarkleyBG. Merging and preparing for release.

@krlmlr krlmlr merged commit 37c9360 into master Dec 17, 2017
0 of 4 checks passed
@krlmlr krlmlr deleted the feature/8-thisfile branch Dec 17, 2017
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Dec 8, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants