Yes, I installed it within the project. If you see my .libPaths() output before, you'll see that the package did get installed in a separate folder (under renv/library within my project directory).
This will lead to entries corresponding to fpp3 and all it's dependencies (and theirs and so on) in the lockfile, if I understand correctly. Do I really need that? For my project, I expected an entry for fpp3 is sufficient, as if renv is capable of installing the current version of it, all the dependencies should be satisfied as well.
I may be wrong in this expectation. Please correct me if that is the case. My idea cam from python structures of requirement.txt, where only what I need is mentioned and not everything that comes from pip freeze.
Seeing documentation, it seems implicit option may fulfill this expectation, if I have few files with library calls in my project. Let me know if that's right. I'd have loved if it was possible to add specific packages which I choose to add, but I don't know whether that option is there or not.
Edit 1 (in reply to kevin):
I tried type = "explicit", but I'm afraid I need a little more guidance. I don't have much experience on package management in R, sorry.
I created the following DESCRIPTION file, with just one line:
Imports: fpp3
And the rest of the setup remained as before, ie. installed just fpp3 in a fresh new project, and as of now there are no scripts yet.
At this step, running renv::snapshot(type = "explicit") and renv::snapshot(type = "implicit") leads to identical results, and renv::snapshot(type = "all") contains a few standard packages with priority recommended.
Output
> renv::snapshot(type = "explicit")
The following package(s) will be updated in the lockfile:
# CRAN ===============================
- BH [* -> 1.75.0-0]
- MASS [* -> 7.3-53]
- Matrix [* -> 1.2-18]
- R6 [* -> 2.5.0]
- RColorBrewer [* -> 1.1-2]
- Rcpp [* -> 1.0.6]
- anytime [* -> 0.3.9]
- cli [* -> 2.5.0]
- colorspace [* -> 2.0-1]
- cpp11 [* -> 0.2.7]
- crayon [* -> 1.4.1]
- digest [* -> 0.6.27]
- distributional [* -> 0.2.2]
- dplyr [* -> 1.0.6]
- ellipsis [* -> 0.3.2]
- fable [* -> 0.3.1]
- fabletools [* -> 0.3.1]
- fansi [* -> 0.5.0]
- farver [* -> 2.1.0]
- feasts [* -> 0.2.2]
- fpp3 [* -> 0.4.0]
- generics [* -> 0.1.0]
- ggplot2 [* -> 3.3.3]
- glue [* -> 1.4.2]
- gtable [* -> 0.3.0]
- isoband [* -> 0.2.4]
- labeling [* -> 0.4.2]
- lattice [* -> 0.20-41]
- lifecycle [* -> 1.0.0]
- lubridate [* -> 1.7.10]
- magrittr [* -> 2.0.1]
- mgcv [* -> 1.8-33]
- munsell [* -> 0.5.0]
- nlme [* -> 3.1-149]
- numDeriv [* -> 2016.8-1.1]
- pillar [* -> 1.6.1]
- pkgconfig [* -> 2.0.3]
- progressr [* -> 0.7.0]
- purrr [* -> 0.3.4]
- rlang [* -> 0.4.11]
- rstudioapi [* -> 0.13]
- scales [* -> 1.1.1]
- slider [* -> 0.2.1]
- tibble [* -> 3.1.2]
- tidyr [* -> 1.1.3]
- tidyselect [* -> 1.1.1]
- tsibble [* -> 1.0.1]
- tsibbledata [* -> 0.3.0]
- urca [* -> 1.3-0]
- utf8 [* -> 1.2.1]
- vctrs [* -> 0.3.8]
- viridisLite [* -> 0.4.0]
- warp [* -> 0.2.0]
- withr [* -> 2.4.2]
Do you want to proceed? [y/N]:
So, my question is why does it list all these packages and not just fpp3? Even fpp3 package's DESCRIPTION file do not have all of these listed.
Imports: cli (>= 1.0.0), crayon (>= 1.3.4), dplyr (>= 0.7.4), fable (>=
0.3.0), fabletools (>= 0.3.0), feasts (>= 0.1.7), ggplot2 (>=
3.1.1), lubridate (>= 1.7.4), magrittr (>= 1.5), purrr (>=
0.2.4), rstudioapi (>= 0.7), tibble (>= 1.4.2), tidyr (>=
0.8.3), tsibble (>= 0.9.3), tsibbledata (>= 0.2.0), urca (>=
1.3-0)
I'll probably stick with implicit option only as ifendo suggested as I'll have scripts under this project soon, but just wanted to understand why it's happening.
Edit 2 (In reply to nirgrahamuk and kevinushey):
I understand dependencies and their dependencies and so on, but my point was if renv is able to store the current version of a package, it should be enough to store only that package details so that it'll automatically resolve all the dependencies to create a working virtual environment.
Admittedly, this is very much influenced from python where no one lists all libraries in requirements, just the only ones which are actually used and the rest gets solved automatically by conda or pip. So, listing of every packages under all type options are very surprising to me.
But of course these are different languages and neither everything is same nor I can expect. I'm sorry for that and I'll use the existing implementation. Thank you.