Comments (8)
Maybe users can just set getOption("pkgType")
, then they shouldn't need to pass any extra arguments to install.packages
or remotes
, unless remotes
doesn't respect that option.
Note that having PACKAGES.rds
file will make R 3.4.4 to fail trying to use your repository. I generally prefer to remove PACKAGES.rds
file.
from drat.
Quickly (and happy to chat more)
-
if
remotes::...
has a problem you need to talk to someone else; -
reads from a repository should just work; the use of
type="source"
is documented and I think we worked out that one has to use this; -
empyt binary packages are a kludge but if you want to use them you can create them;
-
we really work in the context of the base R functions
install.packages()
andupdate.packages()
which, on some platforms, will always go looking for binaries so maybe one just needs to supply such binaries.
Off to a meeting...
All that said, easy things should be easy and "just work". I need to look again at our 'drat-data' paper setup. Maybe we only ever supported source there. Are you mixing source and binary?
from drat.
Depends. The appropriate paths for a package type will only be created, if the first package of this type is added. Without having tested it, this issue probably persist, if only source packages are added.
From my point of view, it is rather a problem of remotes
and not problem of drat
. I can understand that escalating a warning to an error might makes sense under certain circumstances, but defaulting to the source type on windows or mac is not among them. I would expect the remotes
package to investigate the warning message and only trigger an error on other cases.
from drat.
Ok, taking another look. A more narrow PR of just adding placeholder PACKAGES{, .gz, .rds}
may make sense. #73 had a number of issues and was a little too hurried and overwhelming at the time.
from drat.
While I agree, writing the empty PACKAGES
to the repo ist not the most elegant solution on its own, I feel in this case it might be the best we can do. Requiring users to pass non-default type
to install.packages()
comes with its own problems, one of which (for me at least) is that remotes::install_deps()
by default promotes warning to errors and therefore fails. One can override this but all together this leads to things not "just working".
Whether the writing of empty PACKAGES
files should be part of drat
and whether this should be the default behavior of drat::initRepo()
is up to you. We could add a flag like add_bin_paths
(other suggestions?) to drat::initRepo()
that controls this behavior. Together with a bit of documentation, this should put the issue to rest. But this is just my opinion. As I said in the beginning, this is not strictly a drat
bug and therefore does not need fixing.
from drat.
Sorry, I wanted to add it as a reference for my own consumption and I accidentally put it here.
For me adding empty PACKAGES
files does the trick. Please let me know if you have a better solution.
from drat.
@FelixErnst Do we have this covered now? Another close candidate?
from drat.
Closing this for being out of scope and possibly stale.
from drat.
Related Issues (20)
- Persist drat repo across sessions HOT 2
- General problem uploading of package to drat repo HOT 39
- Error when calling insertPackage: permission issue ? HOT 17
- Add new draft vignette on 'step-by-step' demo of `drat` HOT 1
- Convert other vignettes to `minidown::water` HOT 1
- install.packages("drat") fails: `Error : object 'update_PACKAGES' is not exported by 'namespace:tools'` HOT 5
- Problem with link checker in r-devel HOT 3
- Nearing drat 0.2.0 release with main branch docs/ directory support HOT 1
- drat 0.2.0: breaking change if `dratBranch = "main"` HOT 8
- missing getPackageInfo in 0.2.0 HOT 7
- Importing and using large data R package HOT 2
- Insert binary packages to wrong repository on ARM M1 Mac HOT 25
- insertPackage is very slow when using networked windows devices HOT 7
- insertPackage is slow for cloud-based file shares HOT 3
- sorry HOT 1
- Can old package versions be removed from drat folder? HOT 6
- pruneRepo fails with for package type mac.binary.big-sur-arm64 HOT 1
- minor typo HOT 3
- Broken link in doc ? HOT 3
- Possible discrepancy between where drat and CRAN places binaries when .Platform$pkgType is "mac.binary.big-sur-x86_64" HOT 14
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from drat.