Skip to content

lint_package() and find_package(".") does not work anymore if depth >= 2 #1759

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

Closed
BenoitLondon opened this issue Nov 4, 2022 · 5 comments · Fixed by #1765
Closed

lint_package() and find_package(".") does not work anymore if depth >= 2 #1759

BenoitLondon opened this issue Nov 4, 2022 · 5 comments · Fixed by #1765
Labels
bug an unexpected problem or unintended behavior

Comments

@BenoitLondon
Copy link

BenoitLondon commented Nov 4, 2022

In my package I have a code style test so it calls lint_package() from the tests/testthat folder.
The new logic in find_package fails at finding the root of the package ( I guess from this commit 3009505 )

so If I call lint_package from a deeper level than 2 it fails at finding the package actually...

test_that("check that package has code style", {
        skip_on_covr()
        lints <- lintr::lint_package()
        ....
        }

The above code warns/fails with:

Warning message:
In lintr::lint_package() :
  Didn't find any R package searching upwards from '.'.
@AshesITR
Copy link
Collaborator

AshesITR commented Nov 4, 2022

Hi, can you give us an MWE so we can see what is going on?

@AshesITR AshesITR added the reprex-needed needs a minimal reproducible example label Nov 4, 2022
@BenoitLondon
Copy link
Author

Sure here s a reprex but in any package if you call lintr::lint_package() two directories below the root folder of your package it will fail to find the package to lint...

usethis::create_package("~/testme", open = FALSE)
dir.create("~/testme/dir1/dir2", recursive = TRUE)
setwd("~/testme/dir1/dir2")
lintr::lint_package()
# NULL
# Warning message:
# In lintr::lint_package() :
#  Didn't find any R package searching upwards from '.'.

but this works as now it can find the package root:

str(lintr::lint_package("../.."))

 Named list()
 - attr(*, "class")= chr "lints"
 - attr(*, "path")= chr "~/testme2"

@AshesITR
Copy link
Collaborator

AshesITR commented Nov 9, 2022

Thanks for providing the MWE.
I can confirm this, the problem is actually not related to the nesting (2 is allowed):

str(lintr::lint_package("~/testme/dir1/dir2"))

 Named list()
 - attr(*, "class")= chr "lints"
 - attr(*, "path")= chr "/home/alex/testme"

So the problem is actually that the path needs to be normalized before starting the search.

@AshesITR AshesITR added bug an unexpected problem or unintended behavior and removed reprex-needed needs a minimal reproducible example labels Nov 9, 2022
AshesITR added a commit that referenced this issue Nov 9, 2022
@AshesITR AshesITR added this to the 3.0.3 milestone Nov 9, 2022
@IndrajeetPatil
Copy link
Collaborator

With #1765, no more warnings:

usethis::create_package("~/testme", open = FALSE)
#> ✔ Setting active project to '/Users/indrajeetpatil/testme'
#> Package: testme
#> Title: What the Package Does (One Line, Title Case)
#> Version: 0.0.0.9000
#> Authors@R (parsed):
#>     * First Last <first.last@example.com> [aut, cre] (YOUR-ORCID-ID)
#> Description: What the package does (one paragraph).
#> License: `use_mit_license()`, `use_gpl3_license()` or friends to pick a
#>     license
#> Encoding: UTF-8
#> Roxygen: list(markdown = TRUE)
#> RoxygenNote: 7.2.1
#> ✔ Setting active project to '<no active project>'
dir.create("~/testme/dir1/dir2", recursive = TRUE)
#> Warning in dir.create("~/testme/dir1/dir2", recursive = TRUE): '/Users/
#> indrajeetpatil/testme/dir1/dir2' already exists
setwd("~/testme/dir1/dir2")
lintr::lint_package()

Created on 2022-11-09 with reprex v2.0.2

IndrajeetPatil added a commit that referenced this issue Nov 9, 2022
* use normalizePath() in find_package()

fixes #1759

* allow undesirable_operator ::: in test-settings.R

* d'oh

* remove unnecessary testthat.R

* add back testthat.R without comments

Co-authored-by: Indrajeet Patil <patilindrajeet.science@gmail.com>
@BenoitLondon
Copy link
Author

thanks for the fix!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug an unexpected problem or unintended behavior
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants