Skip to content
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

git remotes fail if the repository contains a submodule #354

Closed
dgkf opened this issue Mar 6, 2024 · 6 comments · Fixed by #358
Closed

git remotes fail if the repository contains a submodule #354

dgkf opened this issue Mar 6, 2024 · 6 comments · Fixed by #358

Comments

@dgkf
Copy link
Contributor

dgkf commented Mar 6, 2024

When trying to download a package from a git repo that contains a submodule, I'm encountering an error arising from an attempt to write out an object that doesn't exist from the downloaded git files:

writeBin(parsed[[tr$hash[l]]]$raw, opath)

pkgload::load_all()
sy(async_git_download_repo("https://enterprise.com/user/repo.git"))
# Error in writeBin(parsed[[tr$hash[l]]]$raw, opath) :
#   can only write vector objects

Debugging this line, the error occurs when opath is the path to the submodule, resulting in a parsed[..] that returns NULL.

@gaborcsardi
Copy link
Member

git remotes indeed do not support submodules.

@dgkf
Copy link
Contributor Author

dgkf commented Mar 6, 2024

Ah, I didn't realize this was intentional. Is this something pkgdepends might support in the future or is it considered decidedly out-of-scope?

The particular package that prompted the error doesn't even require the submodule to build (it's excluded via .Rbuildignore, but used for tracking related dependencies used to build distributed inst files).

At least for this narrow use case, tracking which packfile elements can't be unpacked and suppressing issues when they're .Rbuildignore'd would help to mitigate some of these failures. If they aren't included in .Rbuildignore, having a listing of which files failed to come over in the packfile would also improve the error message emitted when submodules are the culprit.

@andrewherren
Copy link

Hi there, I have a C++ library with separate R and python bindings, all within the same organization. The C++ code is included in the R package as a submodule.

Installation from GitHub works fine with remotes::install_github but as noted in this issue, pkgdepends does not download submodules which causes downstream pak::pkg_install to fail. I'd like to use r-lib's CRAN check and pkgdown actions which require me to set up a package that builds with pak::pkg_install.

Is there a "best practice" way to let my R package depend on C++ code from another repo that plays nicely with pkgdepends? I see for example that duckdb has a vendoring script which runs in a github action, but I'm curious if there is a simpler workaround?

Thank you in advance! r-lib's tools have been a huge upgrade to my workflow!

@andrewherren
Copy link

Quick update (in case anyone else with a similar project structure stumbles upon this thread), the workaround is in fact remarkably simple and doesn't have anything to do with pak or pkgdepends. Just modify the checkout@v4 action in the _pkgdown.yml workflow generated by usethis::use_pkgdown_github_pages() to check out submodules recursively via

- uses: actions/checkout@v4
  with:
    submodules: 'recursive'

@gaborcsardi
Copy link
Member

gaborcsardi commented Apr 4, 2024

git remotes now support submodules, but it is opt in via a config value. Do you think it should be the default? We can also keep it opt-in now, and make it the default later?

@andrewherren
Copy link

I'll let @dgkf weigh in as well, but I think it's probably fine to make it opt-in as long as it's clearly documented. Seems like only a handful of us are asking about it on Github issues.

netbsd-srcmastr pushed a commit to NetBSD/pkgsrc that referenced this issue Oct 19, 2024
# pak 0.8.0

* `pkg_deps()` now accepts a vector of package names.

* The metadata cache now does not use source URLs for packages in `Archive`
  on Posit Package Manager repositories. This URLs may serve a different
  package, even a source package when the main URL for the same package
  serves a binary package. The alternative URLs are not needed on PPM,
  anyway, because PPM is in a consistent state w.r.t. metadata and
  package files (#623).

* pak now supports `gitlab::` package sources better, by adding
  explicit syntax to specify subdirectories (r-lib/pkgdepends#353, @dgkf).

* `gitlab::` and `git::` package sources now support git submodules if
  the `git-submodules` configuration option is set to `TRUE`. See
  `?"pak-config"` (r-lib/pkgdepends#354).

* The new `?ignore-unavailable` parameter makes it easy to ignore soft
  dependencies that are unavailable (#606).

* pak now automatically ignores soft dependencies that have an
  incompatible OS type (`OS_type` entry in `DESCRIPTION`) when installing
  packages.

* `repo_add()` and the `ppm_*()` functions, e.g. `ppm_snapshots()`, now
  work again after the PPM API changes
  (r-lib/pkgcache#110,
   r-lib/pkgcache#115).

# pak 0.7.2

* pak now supports using parameters for all packages with the
  `*=?<param>` form. E.g. `*=?source` installs all packages from source.

* pak now supports R 4.4.0 again, and also Rtools44.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants