-
Notifications
You must be signed in to change notification settings - Fork 59
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
Suggestion: dependency order to package dependency table #511
Comments
With a bit of work you can use the dependency information in the ❯ dl <- pak::pkg_download("dplyr", dest_dir = "/tmp/dl", platforms="source", dependencies = NA)
ℹ No downloads are needed, 16 pkgs (6.04 MB) are cached
❯ dl$deps[[1]]
# A data frame: 23 × 5
ref type package op version
* <chr> <chr> <chr> <chr> <chr>
1 R depends R ">=" "3.4"
2 callr suggests callr "" ""
3 covr suggests covr "" ""
4 crayon suggests crayon "" ""
5 digest suggests digest "" ""
6 glue suggests glue ">=" "1.6.0"
7 grDevices suggests grDevices "" ""
8 htmltools suggests htmltools "" ""
9 htmlwidgets suggests htmlwidgets "" ""
10 knitr suggests knitr "" ""
# ℹ 13 more rows
# ℹ Use `print(n = ...)` to see more rows You need to use the keep the rows where OTOH, if you are installing (a subset of) packages, you can still use pak to install them. You can create a mini repository on the disk, by calling |
Btw. there is usually a large number of possible installation orders, and pak never actually creates such an order because it installs packages in parallel. But if that's helpful I can add a column to the output that defines a fixed installation order that you can run sequentially. |
This is a brilliant idea. I'll give that a go and see if I cant figure it out! |
Trying to get this working but hitting some things I am I little uncertain of. the argument > pak::pkg_download(
"psych",
dest_dir ="test_pak",
dependencies = NA,
r_versions = c("4.3", "4.1", "4.4"),
platforms = c("source", "windows")
)
✔ Updated metadata database: 5.38 MB in 37 files.
ℹ R 4.1 i386+x86_64-w64-mingw32 packages are missing from Bioconductor
ℹ R 4.4 i386+x86_64-w64-mingw32 packages are missing from Bioconductor
ℹ R 4.3 i386+x86_64-w64-mingw32 packages are missing from Bioconductor
✖ Updating metadata database ... failed But running "4.4" in singular works. pak::pkg_download(
"psych",
dest_dir ="test_pak",
dependencies = NA,
r_versions = c("4.4"),
platforms = c("source", "windows")
)
✔ Updated metadata database: 2.14 MB in 10 files.
ℹ R 4.4 i386+x86_64-w64-mingw32 packages are missing from Bioconductor
✔ Updating metadata database ... done
ℹ Getting 4 pkgs (7.76 MB), 6 (4.53 MB) cached
✔ Got mnormt 2.1.1 (x86_64-w64-mingw32) (179.34 kB)
✔ Got lattice 0.21-8 (x86_64-w64-mingw32) (1.36 MB)
✔ Got nlme 3.1-162 (x86_64-w64-mingw32) (2.34 MB)
✔ Got psych 2.3.3 (i386+x86_64-w64-mingw32) (3.87 MB)
✔ Downloaded 4 packages (7.76 MB)in 6.6s having the version option is great, as the air-gapped machines usually lag behind in R versions, or might have projects bound to modules with specific versions for reproducibility. so, for the last there I at least get a folder with data, win and src stuff. Looking good. Runinng But, I still cant seem to use that when installing > install.packages("psych", repos = file.path("file:/","test_pak"), type = "source")
Error in read.dcf(file = tmpf) : cannot open the connection
In addition: Warning message:
In read.dcf(file = tmpf) :
cannot open compressed file '/Users/athanasm/workspace/test_pak/src/contrib/PACKAGES', probable reason 'No such file or directory' And yeah, the PACKAGES files are in the root of the folder I provide, not in their subdirs. Sorry some of these questions are not directly pak things, just trying to wrap my head around how this all works so I can make this package and improve my own and colleagues work in the airgapped server. |
Yes, this is a bug. It should work, but it is poorly tested currently. I'll open an issue for it.
Yes, that's how CRAN organizes their directories. One thing I was thinking about is that |
ok thanks. my head is starting to be wrapped :) theoretically, if Historically, I have made a new zip file for each pacakge a user wants to get installed airgapped, with the recipe to install, and import them all and run sequentially. With pak I see the option allowing multiple packages to use the same system, reducing the size overall and making it more efficient. But that would mean that the PACKAGES files would need to get updated when its run every time, right? Which I guess is almost arbitrary, since it takes so little time to run. I like having it wrapped in a single function like pkg_download, though I could see a cleaner use of it through a separate function like pak_mirror(). Thinking of it, I think maybe in the long run, pak_mirror might be a better option. |
Yeah, you are right that that API would not be very intuitive for Something like
Currently it decompresses all package files to read the metadata, so it is not that little, actually, if you have a lot of packages. OTOH, I understand that having a single zip file instead of a local repository has a lot of value for your use case, so maybe we could have a better solution for that first. E.g. have a But in any case, adding a column for one possible installation order is still fine. Or ordering that data frame according to a legal installation order is also an option. |
To be honest, yes, if you are interested in catering for this scenario in pak directly, that would be amazing! The single zip file is just for easy port into the airgapped environment, and a simple single file to point to to start the install process once inside. If you are interested, my current dev version of this package is here. Broken right now, but making progress on porting things to pak. But the README alone might help you understand where I have been and where I want to go with this . having a |
I think
|
@drmowinckels So, currently, This makes the installation order tricky, because if the binary and the source builds are of different versions, then their installation order might be different. In fact, pak does not even run the dependency solver for Do you download source or binary packages? Do you use the |
Thanks for the thorough information, I'm learning a lot! Initially, I only ever got the source files, as I singularly had our RedHat virtual environment in mind. Later, I have seen more and more issues being posted by people using the package for the windows VMs as well. So I was thinking of exposing the platforms argument to have the user resolve this (alternatively give them a similar option to choose "windows" or "linux" and then provide the correct corresponding argument to pak for them). |
I love pak! Its solving a real issue I have in a package for my work. But its missing a small thing for it to be my holy grail.
So, I have a package that downloads the source file of a package and source files for its dependencies, to prepare a zip file for import to an airgapped environment where the packages can be installed. pak creates a really lovely basis for this through
pak::pkg_download
.The only thing I am missing, is somehow to know which order the packages should be installed in to resolve dependency issues as installing.
During pak::pkg_deps_tree you construct a tree
https://github.com/r-lib/pak/blob/main/R/package.R#L267
but then return the data without any indication of the order they depend on each other to help with something like this.
This could potentially solves by another column to the package dep data.frame, though it already is quite large, or if it was returned in their order to be installed, to resolve such issues?
The text was updated successfully, but these errors were encountered: