Source tarballs not found with 'local.repos'
Nobody has claimed this yet.
- Dominant language
- R
- Stars
- 409
- Forks
- 89
- PR merge metrics
- No merged PRs in 30d
Description
I have downloaded source tarballs for all dependencies of my project:
> head(dir('localsrc', recursive = TRUE))
[1] "AMGUtils/AMGUtils_0.69.tar.gz" "assertthat/assertthat_0.2.0.tar.gz" "backports/backports_1.1.2.tar.gz"
[4] "base64enc/base64enc_0.1-3.tar.gz" "BH/BH_1.66.0-1.tar.gz" "bindr/bindr_0.1.1.tar.gz"
(this is the same kind of structure as packrat's own packrat/src/ directory.)
When I try to use this as a local.repos argument, the command fails:
> packrat::init(options=list(local.repos='localsrc'))
Initializing packrat project in directory:
- "~/git/loadfx"
Error in read.dcf(...) : cannot open the connection
In addition: Warning message:
In read.dcf(...) :
cannot open compressed file 'localsrc/AMGUtils/DESCRIPTION', probable reason 'No such file or directory'
Is this not how the feature is intended to be used? If not - would it be easy to add? I'm wondering if the "directories containing package sources within sub-directories" mentioned in the local.repos docs are actually untarred source tarballs, which would seem a lot harder to manage (especially since it wouldn't let me pick from multiple versions of a package).
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Reproduce the failure with packrat::init(options=list(local.repos='localsrc')) using the tarball layout shown in the issue. Trace the local.repos handling and compare it with the documented directory structure; done means the intended source-tarball behavior is supported or the documentation clearly matches the accepted layout.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- r
- Domain
- tooling
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100