Closed justinmillar closed 2 years ago
Could you please provide a reprex, or a traceback from the error?
9: filelock::lock(path, timeout = getOption("pins.lock.timeout",
Inf))
8: local_registry_lock(board)
7: pin_registry_update(board, name, metadata)
6: pin_download_one(p, ...)
5: pin_download_files(base_url, name, board, headers = github_headers(board),
subpath = subpath)
4: board_pin_get.pins_board_github(board, name, extract = extract,
version = version, ...)
3: board_pin_get(board, name, extract = extract, version = version,
...)
2: pins::pin_get(name = pin_name, board = "PATHtoolsZambia-data")
1: retrieve("cars_test")
Here's the traceback, I'm not really sure how to make a reprex for this situation since I don't really understand the error. The pins have been stored on a separate branch in a private github repo that houses a R package.
And this is pins 1.0.0, right?
The reprex doesn't need to be runnable for me; it's just useful to see the exact sequence of calls that lead to this error.
Yes, this is pins 1.0.0, but I am using the old API. Here's a reprex:
> library(pins)
> board_register_github(name = "PATHtoolsZambia-data",
+ repo = "PATH-Global-Health/PATHtoolsZambia",
+ branch = "datasets")
> pin_find(board = "PATHtoolsZambia-data")[1,]
name description type board
10 cars_test mt_cars dataset as test table PATHtoolsZambia-data
> pin_get("cars_test", board = "PATHtoolsZambia-data")
Error in filelock::lock(path, timeout = getOption("pins.lock.timeout", :
Filelock error (5), Opening file: Access is denied.
> traceback()
8: filelock::lock(path, timeout = getOption("pins.lock.timeout",
Inf))
7: local_registry_lock(board)
6: pin_registry_update(board, name, metadata)
5: pin_download_one(p, ...)
4: pin_download_files(base_url, name, board, headers = github_headers(board),
subpath = subpath)
3: board_pin_get.pins_board_github(board, name, extract = extract,
version = version, ...)
2: board_pin_get(board, name, extract = extract, version = version,
...)
1: pin_get("cars_test", board = "PATHtoolsZambia-data")
I think my problem is deeper than I thought. I tried adding a new pin to see if that locked, and it completely broke things.
> library(pins)
> # Create a new board
> board_register_github(name = "test-old-pins",
+ repo = "justinmillar/test-old-pins")
> # Try making a pin
> pin(iris, name = "aaa", board = "test-old-pins")
Error: $ operator is invalid for atomic vectors
>
> traceback()
9: FUN(X[[i]], ...)
8: lapply(X = X, FUN = FUN, ...)
7: sapply(index, function(e) identical(e$path, path))
6: github_update_temp_index(board, index_path, commit, operation = "create",
name = name, metadata = metadata, branch = branch)
5: board_pin_create.pins_board_github(board, store_path, name = name,
metadata = metadata, ...)
4: board_pin_create(board, store_path, name = name, metadata = metadata,
...)
3: board_pin_store(board, path, name, metadata, ...)
2: pin.data.frame(iris, name = "aaa", board = "test-old-pins")
1: pin(iris, name = "aaa", board = "test-old-pins")
I think we can probably just remove the file locking; from my vague memory of looking at the code, I don't think it's likely to work 100% anyway.
I think there may be an additional (related?) issue with Git credentials. I shifted from storing my PAT in my .Renviron to using gitcreds
, but this appears to have caused a problem with registering the github board, which only works if the token is in .Renviron.
You can run Sys.setenv(GITHUB_PAT = gitcreds::gitcreds_get(use_cache = FALSE)$password)
to work around that
Reprex:
library(pins)
Sys.setenv(GITHUB_PAT = gitcreds::gitcreds_get(use_cache = FALSE)$password)
board_register_github("test-old-pins", repo = "hadley/test-pins")
pin(iris, board = "test-old-pins")
With backtrace:
Error: $ operator is invalid for atomic vectors
Backtrace:
▆
1. ├─pins::pin(iris, board = "test-old-pins")
2. └─pins:::pin.data.frame(iris, board = "test-old-pins")
3. └─pins::board_pin_store(board, path, name, metadata, ...)
4. ├─pins::board_pin_create(...)
5. └─pins:::board_pin_create.pins_board_github(...)
6. └─pins:::github_update_temp_index(...)
7. └─base::sapply(index, function(e) identical(e$path, path))
8. └─base::lapply(X = X, FUN = FUN, ...)
9. └─pins FUN(X[[i]], ...)
Simpler reprex (after gitcreds integration)
library(pins)
board <- legacy_github("hadley/test-pins")
pin(iris, board = board)
Looks like this was broken in 7cde6e72486546a23939f2ed28c1dff0c605dc22 — I didn't realise base64encode()
could take either strings OR paths.
Looks like it was 3 different things that were all slightly broken; should be good to go now.
Awesome, our workflow is back up and running, thanks so much!
This issue has been automatically locked. If you believe you have found a related problem, please file a new issue (with a reprex: https://reprex.tidyverse.org) and link to this issue.
I am unable to access pins and receiving this (new to me) error message:
Not use how the files became locked, our team had been using pins to access shared data files for the past year without issue. We're still using the old API due to using the Github board. Any ideas about what is happening here?