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

ARROW-17084: [R] Install the package before linting #13620

Merged
merged 5 commits into from
Aug 2, 2022

Conversation

dragosmg
Copy link
Contributor

@dragosmg dragosmg commented Jul 15, 2022

The package should be installed before running lintr::ling_package() or lintr::expect_lint_free() (our case), otherwise we could encounter some false positives.

See r-lib/lintr#352 (comment) and r-lib/lintr#406 (comment)

@dragosmg dragosmg marked this pull request as ready for review July 15, 2022 12:22
@github-actions
Copy link

@dragosmg dragosmg marked this pull request as draft July 15, 2022 14:41
@dragosmg dragosmg marked this pull request as ready for review July 18, 2022 16:10
Copy link
Member

@paleolimbot paleolimbot left a comment

Choose a reason for hiding this comment

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

I can speak to the fact that pak::pak("local::.") does what the PR title says but everything else is over my head!

@dragosmg
Copy link
Contributor Author

dragosmg commented Jul 26, 2022

@jonkeane & @nealrichardson would you mind having a look? (when you get a chance)

.github/workflows/r.yml Outdated Show resolved Hide resolved
@dragosmg dragosmg requested a review from jonkeane August 1, 2022 08:44
Copy link
Member

@jonkeane jonkeane left a comment

Choose a reason for hiding this comment

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

I'm fine to merge this as-is, though is there a CI job we expect will fail or should now pass with these changes?

We don't absolutely have to do the dance of introducing a linting error, demonstrating it fails, and then demonstrating it works but it might be nice to confirm (since presumably we were failing or accidentally not linting at all before? Apologies if this is discussed elsewhere, I looked through the description here + ticket and couldn't find a precipitating cause of finding this bug(?))

@dragosmg
Copy link
Contributor Author

dragosmg commented Aug 2, 2022

@jonkeane Thanks for your review. Hopefully this gives more details (and answers the questions):

  • we do not currently have a CI job to test this. It's also a bit trickier to reproduce (I haven't figured out how to reliably reproduce it).
  • I noticed the failure (false-positive) during work on PR ARROW-14575: [R] Allow functions with pkg:: prefixes #13160 when the CI was picking up a lint in a file that did not exist in my branch - the CI run can still be seen here, although the history of the branch was later re-written due to a rebase. At the moment of the CI run, test-dplyr-glimpse.R did not exist in my branch, but it did exist in the master branch.
  • another odd aspect (a false-negative?) is that the lint in test-dplyr-glimpse.R was not picked up as part of CI run for the PR (ARROW-16776: [R] dplyr::glimpse method for arrow table and datasets #13563) which added it.

@jonkeane
Copy link
Member

jonkeane commented Aug 2, 2022

Interesting, thanks for that additional context. We should merge this fix regardless (since it's the recommended way of running lintr!), but I suspect that something else might have happened with the seemingly off files here.

I was curios, so went looking and turns out, the offending whitespace line was introduced in #13610 which did get properly flagged: https://github.com/apache/arrow/runs/7349390401?check_suite_focus=true so at least that did work at the time.

Anyway, like I said, I'll merge this since it's the right way to be running lintr according to the developers

@jonkeane jonkeane merged commit 51eb3c8 into apache:master Aug 2, 2022
@dragosmg
Copy link
Contributor Author

dragosmg commented Aug 2, 2022

I see what you mean. I guess it depends on the point of view. If you look at it as the state of the package pre-merge (my branch) then the lint is a false-positive (which is AFAICT should be the case). If you look at it as the state of the package post-merge (the master) then the picked-up lint was not a false-positive.

As you say, regardless of the POV, the authors' recommended workflow is to install the package before linting.
Installing the package, AFAIU, will lint the branch version of the package and not the master one.

If my understanding is correct, it points to a way we could test this. Introduce a lint in a new file in master. With the old workflow any subsequent PR should pick-up this lint (even if the affected file is not touched), while with the new CI workflow, the lint in master should not be picked-up (if the file isn't present in the branch).

@ursabot
Copy link

ursabot commented Aug 2, 2022

Benchmark runs are scheduled for baseline = 48e2780 and contender = 51eb3c8. 51eb3c8 is a master commit associated with this PR. Results will be available as each benchmark for each run completes.
Conbench compare runs links:
[Failed ⬇️0.0% ⬆️0.0%] ec2-t3-xlarge-us-east-2
[Failed ⬇️0.37% ⬆️0.0%] test-mac-arm
[Failed ⬇️0.27% ⬆️0.0%] ursa-i9-9960x
[Finished ⬇️0.14% ⬆️0.04%] ursa-thinkcentre-m75q
Buildkite builds:
[Failed] 51eb3c8a ec2-t3-xlarge-us-east-2
[Failed] 51eb3c8a test-mac-arm
[Finished] 51eb3c8a ursa-i9-9960x
[Finished] 51eb3c8a ursa-thinkcentre-m75q
[Failed] 48e27804 ec2-t3-xlarge-us-east-2
[Finished] 48e27804 test-mac-arm
[Failed] 48e27804 ursa-i9-9960x
[Finished] 48e27804 ursa-thinkcentre-m75q
Supported benchmarks:
ec2-t3-xlarge-us-east-2: Supported benchmark langs: Python, R. Runs only benchmarks with cloud = True
test-mac-arm: Supported benchmark langs: C++, Python, R
ursa-i9-9960x: Supported benchmark langs: Python, R, JavaScript
ursa-thinkcentre-m75q: Supported benchmark langs: C++, Java

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants