Skip to content

load_code unintentionally public? #335

Description

@pearsonca

I'm attempting to use pkgload in a boot-strappy context with data-raw - basically, I want to use part of the R API while building the data.

I may be misreading, but load_all doesn't seem to support a code-only version. Hence, I went to load_code, which suggests it loads only the code.

However, when I attempt to use load_code() directly:

Error in source_many(paths, encoding, env) : 
  is.environment(envir) is not TRUE
Error in `unload()`:
! Package testtesttest not found in loaded packages or namespaces.
Run `rlang::last_trace()` to see where the error occurred.

(here testtesttest is the pure skeleton package from Rstudio -> Create Project -> Create R package)

The culprit seems to be in ns_env - requires that a namespace already be loaded.

So a few thoughts:

  • is load_code not intended to be public API pkgload?
  • if load_code is supposed to be public API, clearly I'm using it wrong - is there a way to clear up how to use it properly in the documentation?
  • is there another "preferred" approach to acheive what I'm trying to do specifically (load code only as-if packaged in the namespace)?

Activity

  1. lionel- commented on Jul 2, 2026

    @lionel-
    Member

    What do you mean exactly by "code-only version"?

  2. pearsonca commented on Jul 2, 2026

    @pearsonca
    Author

    What do you mean exactly by "code-only version"?

    For my particular case, a package namespace that includes only the functional API defined in the R/ folder, exclusive of the package data. I understand some of that API might not work (e.g. because it depends on data having been generated) and that features like documentation might not be available.

    That seems to be what the pkgload documentation suggests in https://pkgload.r-lib.org/reference/load_code.html: "Sources all .R/.r files in the R/ directory, storing results into the package namespace."

  3. lionel- commented on Jul 3, 2026

    @lionel-
    Member

    @pearsonca Gotcha! Please let me know if the latest main fixes your issue

  4. pearsonca commented on Jul 10, 2026

    @pearsonca
    Author

    @lionel- I can confirm it does, thanks.

    Some further notes re ergonomics for my use case:

    • to get at the functions, i have to use packageName:::function (i.e. internal function) syntax - can't use the global context or ::. I tried using attach(getNamespace(packageName), ...), which seems like it would have worked if I didn't have compiled code as well; to use that approach, I had to do load_code => load_dll. I opted for the ::: mildly odd syntax since I didn't actually need any of the compiled code.
    • I have some data.table calls inside my particular functions. library'ing in data.table within the data-raw script was insufficient, had to use .datatable.aware marker in package. More generally, I expect there may be weird dependency problems for other packages with functions created by load_code

    Not suggesting these need fixing, but might be worth updating function documentation to set expectations for direct use.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions