-
Notifications
You must be signed in to change notification settings - Fork 289
new use_tidy_style()
#197
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
new use_tidy_style()
#197
Conversation
Just took a quick look. One thing I already know it needs is a check re: clean git status. See the source for |
thanks, I will do so. |
Can you also take a look at the AppVeyor failure? |
Yes, I try to understand what's going on because locally, with |
Yep, agree.
It doesn't smell like a path problem FWIW. Also we're getting same failure on Travis and AppVeyor now. I think it's legit. |
For the uncommitted changes- test: I wondered whether I should create a function |
That's a good idea. I suggest you define it in R/git-utils.R. |
Ok, I took a look at |
Also re-installed relevant dependencies from CRAN to make sure they match the CI configuration. |
Once the tests work I am happy to test case for a project that is not a package. |
It's not clear to me what the problem is. Suggest you remove the |
NAMESPACE
Outdated
export(use_tidy_support) | ||
export(use_tidy_versions) | ||
export(use_travis) | ||
export(use_usethis) | ||
export(use_vignette) | ||
importFrom(styler,style_pkg) | ||
importFrom(styler,tidyverse_style) |
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.
We generally don't do this.
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.
So should I just use ::
whenever I need an external function?
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.
Yes.
R/styler.R
Outdated
check_is_package("use_tidy_style()") | ||
check_uncommitted_changes() | ||
styled <- do.call( | ||
ifelse(is_package(), "style_pkg", "style_dir"), |
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 wouldn't use ifelse()
this way.
In fact, I'd unwrap this into a more conventional if() ... else()
construct.
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.
Ok.
Sorry I did not realize earlier but maybe we should move |
For some reason the styling throws an error. Unfortunately, the transformation of the code within |
tests/testthat/helper.R
Outdated
package = capture_output(create_package(dir, rstudio = rstudio, open = FALSE)), | ||
project = capture_output(create_project(dir, rstudio = rstudio, open = FALSE)) | ||
package = testthat::capture_output(create_package(dir, rstudio = rstudio, open = FALSE)), | ||
project = testthat::capture_output(create_project(dir, rstudio = rstudio, open = FALSE)) |
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.
These aren't necessary and aren't used elsewhere in the tests. Can you remove?
In terms of test development, I load testthat in all interactive sessions in .Rprofile
FWIW.
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.
Yes they are not necessary if testthat is loaded. I thought it might be good practice to not assume this is the case so I added them. But I will remove them in that case. As it stands if now, the PR is anyways not intended to be merged, the primary goal was to make the unit tests passing, which was not possible.
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.
ok, removed.
I'm about to run the tests locally on Windows and see if I learn anything. |
Thanks. Also, once we get them running, we can squash all the commits we needed to get there to keep a clean history I suggest. |
I can replicate but not explain the failure on Windows. But only via If I replace |
You might need to make a debugging branch of styler that emits more info from Alternatively, you could try to avoid the use of Update: re avoiding |
Ok. Thanks for helping me out with that. As you said, it seems really strange. I hope I can find time soon to look at it more in depth and follow some of the suggestions you outlined above to find the root of the problem. It would be nice if we could continue to use some of the existing infrastructure eventually though. I did also not think of withr as a potential cause, thanks for that hint. |
If it is a bad interaction between these two, nested uses of withr, that would be interesting to know. At this point, I suspect |
The failures are because you have an implicit dependency on dplyr since you are using And purrr has a dependency on dplyr for IMHO you need to remove the |
Thanks so much @jimhester, I would never have considered that. I assumed we have removed the dplyr dependency completely with r-lib/styler#182 but it was apparently only after that (as you linked above) where I introduced it again without taking notice. I'll try to fix it. |
@jennybc might that also affect the upcoming |
I opened r-lib/styler#323 to discuss the implicit dplyr dependency and implications in general. |
I now regard this as completely a styler problem 😁 Realistically, the vast vast majority of usethis and reprex users will have dplyr. So I won't let this block a CRAN update to usethis or reprex. Nothing has gotten worse, now we just know about a pre-existing problem. But it would be good to straighten things out over in styler! And get rid of the dplyr dependency. I propose that you change the test here to something that doesn't exercise the dplyr-calling code in styler, so we can move forward. If you're really fast, it can happen before we submit usethis -- TODAY. |
Any test that will make git commits needs to have this in it: usethis/tests/testthat/test-use-readme.R Lines 12 to 14 in da1a8c2
|
remove capture_output for now as suggested by reviewer to see what happens.
because git2r::discover_repository() not working on R 3.1.
d09db1c
to
c94dbb1
Compare
28fa060
to
cb186db
Compare
cb186db
to
9b7230a
Compare
Ok, I think that's it. In particular, I reverted the |
This will be a squash and merge regardless. Let me just look it all over again. |
Ok, sure. |
R/dev-version.R
Outdated
call. = FALSE | ||
) | ||
} | ||
check_uncommitted_changes(proj_get()) |
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.
Pretty sure this can just be check_uncommitted_changes()
, right?
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.
Yes, I was not sure because it appeared to me that in some places the path was set while in other places it was not, so I thought I go the safe way and add it. Will remove it then.
R/styler.R
Outdated
) | ||
} | ||
cat_line() | ||
done("Styled package according to the tidyverse style guide") |
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.
Propose: "Project has been styled according to ..." to be less package specific.
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.
Oh yes.
Green checks on travis! Just change those two things. I'm editing NEWS right now so will anticipate this for you. |
Done. On a related note, I think there are quite help files that are not up-to-date with the package source code at that stage but I have not committed anything because it's not related to this PR. |
I've been documenting a lot, so if you have concrete examples, please pass along. I'm not aware of a problem. |
Thanks! |
Thanks 😊. Ok, I think the reason for that was simply different roxygen versions (I don't use the dev version) and my changes had made things worse, so I think it's all good. |
Closes #72. I am not very familiar with the
usethis
source code, so let me know if there were some conventions I did not follow. Also, I am not sure if the warning (which I just copied from styler) in the documentation of the function is needed.cc: @krlmlr.