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

Error: must pass a package name, “DLLInfo” or “DllInfoReference” object #822

Closed
pat-s opened this issue Nov 7, 2018 · 52 comments · Fixed by r-lib/pkgload#83 or #914
Closed

Error: must pass a package name, “DLLInfo” or “DllInfoReference” object #822

pat-s opened this issue Nov 7, 2018 · 52 comments · Fixed by r-lib/pkgload#83 or #914
Milestone

Comments

@pat-s
Copy link

@pat-s pat-s commented Nov 7, 2018

The recent v6.1.1 update causes the following error on Travis:

https://travis-ci.org/mlr-org/mlr/jobs/451819776#L2685

Running script: step_run_code(devtools::document())
Updating mlr documentation
Updating roxygen version in /home/travis/build/mlr-org/mlr/DESCRIPTION
Writing NAMESPACE
Loading mlr
Loading required package: ParamHelpers
Error: must pass a package name, “DLLInfoorDllInfoReferenceobject

The error does not appear with v6.1.0. Also it just appeared today after v6.1.1 was released on CRAN.

Using devtools::document(".") works in some instances. I think this could be related to the change made in #704?

@mb706
Copy link

@mb706 mb706 commented Nov 8, 2018

The problem is this commit: dynamic libraries are not compiled, even if they don't exist. It should probably be compile = NA instead of compile = FALSE.

@pat-s
Copy link
Author

@pat-s pat-s commented Nov 8, 2018

In the mean time I'll just do a remotes::install_version("roxygen2", "6.1.0") before the problematic call.

@hadley
Copy link
Member

@hadley hadley commented Nov 8, 2018

It definitely shouldn't be compile = NA because that would return it to the previous behaviour that people complained about.

@mb706
Copy link

@mb706 mb706 commented Nov 8, 2018

Maybe you could make load_all skip load_dll and hope that loading the package never ends up calling a compiled function (should be rare enough, this is the old behaviour?). Otherwise (as I understand it) roxygenise() will just not work when no compiled dlls are present, and #771 is back where it started: compilation is necessary before documentation, only now it needs to be invoked explicitly.

@hadley
Copy link
Member

@hadley hadley commented Nov 8, 2018

My expectation is that most people are documenting after a load_all() so this should rarely be a problem. The root cause of this issue was fixed upstream in pkgdown: deployment your package website shouldn't trigger a re-roxygenise.

I agree that it would be nice if pkgload failed more gracefully if compile = FALSE and no dll is present.

@mb706
Copy link

@mb706 mb706 commented Nov 8, 2018

I think #771 & #776, or people like them, would be happiest if documentation could be created without the necessity to build dlls at all, whether done by roxygenise() itself or required to do manually. I guess manual means one can skip the build process when git checkout changes source files and compile = NA would recompile unnecessarily in this case.

@eddelbuettel
Copy link
Contributor

@eddelbuettel eddelbuettel commented Nov 9, 2018

This is clearly a continuation of #771 which I filed months ago, and which was closed 17 days ago.

It is however not fixed. So I have to continue to use version 6.0.1 which to me is the last non-borked one for the sole use case I have here. Which is creating Rd files from R files. Which is what this package was about at some point.

@krlmlr
Copy link
Member

@krlmlr krlmlr commented Nov 10, 2018

With some changes to pkgload it might be possible to load only the R code but never the DLL.?

@hadley
Copy link
Member

@hadley hadley commented Nov 10, 2018

This is a continuation of #784, where I asked for help testing the feature, and no one responded. Obviously, roxygen2 works just fine for me, so I need help from the community.

@krlmlr that would seem to me to be a weird abuse of pkgload. It shouldn't create simulated packages that can't work. I think the approach that you outline in
#771 (comment) is a better one.

@krlmlr
Copy link
Member

@krlmlr krlmlr commented Nov 10, 2018

We can end up in a broken state too with compile = FALSE. Not loading the DLL feels like a more consistent approach.

What do we need the loaded package for? \usage{}, NAMESPACE, ...? Anything where it's important to have the DLL loaded?

@markvanderloo
Copy link

@markvanderloo markvanderloo commented Nov 13, 2018

My expectation is that most people are documenting after a load_all() so this should rarely be a problem.

It is not my workflow and I got bitten by this just now. It means I have to update all my build travis build scripts in pkgs with compiled code to avoid build failures. Considering that part of my pkgs are free time projects, this unannounced change in behavior is less than friendly to an open source developer like me.

@hadley
Copy link
Member

@hadley hadley commented Nov 13, 2018

@markvanderloo I have been making these changes in response to user requests. It's not my intent to break your code. However, your comment would be more helpful if you could describe exactly what your workflow is, so I could avoid disrupting it in the future. I can not help you if you do not tell me what the problem is.

@eddelbuettel
Copy link
Contributor

@eddelbuettel eddelbuettel commented Nov 13, 2018

Any use of roxygenize(".", roclets="rd") on a package with src/ does.

And I said so over three months ago in #771. And it is still broken, and I am still forced to rely on 6.0.1.

@hadley
Copy link
Member

@hadley hadley commented Nov 13, 2018

@eddelbuettel Does what?

We have made at least 3 changes to roxygen2 and pkgbuild to ameliorate your issues, but without a reproducible example, it's hard to know what the problem is.

@hadley
Copy link
Member

@hadley hadley commented Nov 13, 2018

Just to be absolutely sure I'm not confused, I just re-installed roxygen2, and ran roxgenise() directly on the vctrs package (which does have a src directory):

> roxygen2::roxygenise()
Updating roxygen version in /Users/hadley/Documents/r-lib/vctrs/DESCRIPTION
Writing NAMESPACE
Loading vctrs
Writing NAMESPACE
Writing vctrs-package.Rd

It also works if I do roxygen2::roxygenise(roclets = "rd"), although I get a lot of warnings about unknown @export directives.

@krlmlr
Copy link
Member

@krlmlr krlmlr commented Nov 13, 2018

I'm seeing errors when running roxygenise() on a fresh clone of vctrs, before running devtools::load_all(). After running load_all() once I can roxygenise() in a fresh session.

@eddelbuettel
Copy link
Contributor

@eddelbuettel eddelbuettel commented Nov 13, 2018

Why do you waste your (and my) time dragging me into a debate about this?

I reported it in #771 on August 3 (!!), and showed how I triggered it (calling a simple and standard roxygenize(".", roclets="rd").). I have a workaround (see below) with a hard-wiring roxygen2 6.0.1. But if I do not use that I get:

rob:~/git/rquantlib(master)$ Rscript -e 'library(roxygen2); roxygenize(".", roclets="rd")'
Updating roxygen version in /home/edd/git/rquantlib/DESCRIPTION
Loading RQuantLib
Error in getDLLRegisteredRoutines.DLLInfo(dll, addNames = FALSE) :
  must specify DLL via a “DLLInfo” object. See getLoadedDLLs()
Calls: roxygenize ... assignNativeRoutines -> getDLLRegisteredRoutines.DLLInfo
In addition: Warning message:
roxygen2 requires Encoding: UTF-8
Execution halted
rob:~/git/rquantlib(master)$

For comparison, here is a call that works following by the same one that fails:

rob:~/git/rquantlib(master)$ roxy.r
** Using cached version 6.0.1 of roxygen2.
Loading required package: methods
Loading required package: Rcpp
Loading required package: stats
Loading required package: graphics
Loading required package: zoo

Attaching package: ‘zoo’

The following objects are masked from ‘package:base’:

    as.Date, as.Date.numeric

rob:~/git/rquantlib(master)$ Rscript -e 'library(roxygen2); roxygenize(".", roclets="rd")'
Updating roxygen version in /home/edd/git/rquantlib/DESCRIPTION
Loading RQuantLib
Error in getDLLRegisteredRoutines.DLLInfo(dll, addNames = FALSE) :
  must specify DLL via a “DLLInfo” object. See getLoadedDLLs()
Calls: roxygenize ... assignNativeRoutines -> getDLLRegisteredRoutines.DLLInfo
In addition: Warning message:
roxygen2 requires Encoding: UTF-8
Execution halted
rob:~/git/rquantlib(master)$

@markvanderloo
Copy link

@markvanderloo markvanderloo commented Nov 13, 2018

@hadley I generate documentation build time. Usually using a custom document.r executable script, sometimes with some options. e.g I like to generate the pdf manual using R CMD Rd2pdf while reviewing and updating it. I do a lot of coding in vim + bash with a few helper scripts or makefiles. (I do interactive data analyses in RStudio, but package coding a lot less).

not sure if this helps. Doing a load_all() before roxygenize() is a workaround.

@eddelbuettel
Copy link
Contributor

@eddelbuettel eddelbuettel commented Nov 13, 2018

I should add that it does not hit every package every time, but it is frequent enough (and I sometimes have to disable roxygen use in an RStudio profile as the error above gets triggered). I don't know exactly what triggers it, and the roxygen2 code is on the complicated side of things so I didn't find a hook.

@hadley
Copy link
Member

@hadley hadley commented Nov 13, 2018

@eddelbuettel I'm trying to get information from you that you have not previously supplied (the issue that you link to complains that roxygenise doesn't work and links to a script but does not provide any output). If you think this is a waste of your time and you're happy with your work around, there's no need to continue this discussion.

@markvanderloo I said load_all(), but my assumption was broader: that you had a compiled shared object in your src/directory. I was thinking that if you didn't use load_all() that you'd instead be using R CMD install . which also leaves compiled artefacts in src/. But that's obviously not happening with your workflow, which leads me to wonder what you mean by "build" time — obviously the package itself is not yet built, otherwise (I'd think) that the DLL/shared object would be available.

@eddelbuettel
Copy link
Contributor

@eddelbuettel eddelbuettel commented Nov 13, 2018

Please. I filed a bug report on August 3. The issue is still open. I said that right there and then that roxygenize(".", roclects="rd") creates the bug. I told you half a dozen times that in order to have any functionality I have use a workaround which means I don't see the failure all the time -- as I am forced to work around it.

@eddelbuettel
Copy link
Contributor

@eddelbuettel eddelbuettel commented Nov 13, 2018

Here it is, again, on a smaller repo. It does not always happen, but when it happens it is deadly.

edd@brad:~/git/anytime(master)$ Rscript -e 'library(roxygen2); roxygenize(".", roclets="rd")'
Updating roxygen version in /home/edd/git/anytime/DESCRIPTION
Loading anytime
Error in getDLLRegisteredRoutines.DLLInfo(dll, addNames = FALSE) : 
  must specify DLL via a “DLLInfo” object. See getLoadedDLLs()
Calls: roxygenize ... assignNativeRoutines -> getDLLRegisteredRoutines.DLLInfo
Execution halted
edd@brad:~/git/anytime(master)$ 

@jpritikin

This comment has been hidden.

@eddelbuettel

This comment was marked as off-topic.

@iago-pssjd
Copy link

@iago-pssjd iago-pssjd commented Aug 2, 2019

After some modifications on the package openxlsx, I was going to Build > Check Package RStudio commands and I got a similar output:

Error in getDLLRegisteredRoutines.DLLInfo(dll, addNames = FALSE) : 
  must specify DLL via a “DLLInfo” object. See getLoadedDLLs()
Calls: <Anonymous> ... assignNativeRoutines -> getDLLRegisteredRoutines.DLLInfo

Now, I decided to go first to Build > Test Package and then try Build > Check Package and it seems to have worked.

@hadley hadley added this to the v6.2.0 milestone Aug 22, 2019
hadley added a commit that referenced this issue Sep 18, 2019
@hadley hadley closed this in #914 Sep 19, 2019
hadley added a commit that referenced this issue Sep 19, 2019
@hadley
Copy link
Member

@hadley hadley commented Sep 19, 2019

roxygen will now compile code in src when needed, which should fix most of the problems in this thread.

If you don't want roxygen2 to compile your source code, you have two options:

  • Roxygen: list(load = "source") or roxygenise(load = "source") will use the strategy from roxygen2 6.0.0 and earlier

  • Roxygen: list(load = "installed") or roxygenise(load = "installed") will use the installed version of the package, assuming that you've installed it some other way

vtraag added a commit to vtraag/rigraph that referenced this issue Mar 12, 2020
It seems that because of r-lib/roxygen2#822 it
is necessary to first build the dll using compile_dll, otherwise the
NAMESPACE file will not be correctly generated.
@vtraag
Copy link

@vtraag vtraag commented Mar 12, 2020

Currently, I am working on updating an R package (rigraph) that provides an interface for a C library (igraph). I seem to be running in a type of catch-22 situation when running roxygen2 on that package.

Using the load = "source" option leads to the problem mentioned in issue #595 about the missing roxygen_devtest package. The cause of this error is in

https://github.com/igraph/rigraph/blob/5e7a689afde1864c2f36b2a7825db24f2f89b22b/R/zzz-deprecate.R#L39

where packageName() evaluates to roxygen_devtest. This could perhaps be resolved in some way, but it it not immediately clear to me how.

So, in order for roxygen2 to properly generate documentation, I therefore need to use the load = "installed" option. This then requires me to call pkgbuild::compile_dll before calling roxygenise(load = "installed"), because I otherwise get the error mentioned here. However, pkgbuild::compile_dll requires a NAMESPACE file, which should actually be generated by roxygen2. I now solve this by first creating an artificial NAMESPACE file, which then needs to be removed again in order to have roxygen2 generate the proper NAMESPACE file. This seems to work. However, there is a rather strange dependency here: roxygenise depends on compile_dll which depends on the output of roxygenise again. I imagine others have faced this situation as well. I am hoping someone will have a more "proper" solution then this one?

@eddelbuettel
Copy link
Contributor

@eddelbuettel eddelbuettel commented Mar 12, 2020

I tried to look at your package to see my "solution" of relying on the older version works, but your package / repo seems non-standard so I can't.

edd@rob:/tmp/rigraph(update/0.8.0)$ roxy.r 
** Using cached version 6.0.1 of roxygen2.
First time using roxygen2. Upgrading automatically...
Error: File `/tmp/rigraph/DESCRIPTION' does not exist
edd@rob:/tmp/rigraph(update/0.8.0)$ 

@vtraag
Copy link

@vtraag vtraag commented Mar 12, 2020

@eddelbuettel , thanks for taking a look! The package first needs to be bootstrapped by calling make. This generates the DESCRIPTION file (among others), and somewhere during this process the NAMESPACE is also generated.

@eddelbuettel
Copy link
Contributor

@eddelbuettel eddelbuettel commented Mar 12, 2020

Very non-standard build.

Something somewhere which I cannot find seems to require roxygen_devtest. Which I don't have. Moving on ...

@vtraag
Copy link

@vtraag vtraag commented Mar 12, 2020

Yes, indeed, hence some of the issues that arise. Thanks for taking a look nonetheless.

Regarding the problem with roxygen_devtest:

Using the load = "source" option leads to the problem mentioned in issue #595 about the missing roxygen_devtest package. The cause of this error is in

https://github.com/igraph/rigraph/blob/5e7a689afde1864c2f36b2a7825db24f2f89b22b/R/zzz-deprecate.R#L39

where packageName() evaluates to roxygen_devtest. This could perhaps be resolved in some way, but it it not immediately clear to me how.

If I understand it correctly, running load="source" is equivalent to the procedure of roxygen2 of version 6.0.x and earlier, according to the documentation. It therefore makes sense that you also run into this problem when using an older version of roxygen2, but good to see that confirmed, thanks!

@krlmlr
Copy link
Member

@krlmlr krlmlr commented Mar 12, 2020

@vtraag: Can you please try the dev version of the pkgload package?

@vtraag
Copy link

@vtraag vtraag commented Mar 12, 2020

@vtraag: Can you please try the dev version of the pkgload package?

@krlmlr , yes, I would be glad to. In what way? Using the load = "source" option, or using the load = "installed" option?

@krlmlr
Copy link
Member

@krlmlr krlmlr commented Mar 12, 2020

Install it via devtools::install_github("r-lib/pkgload"), then update documentation with roxygen2. The package is used internally by roxygen2.

@vtraag
Copy link

@vtraag vtraag commented Mar 12, 2020

@krlmlr, thanks, but that unfortunately that does not solve things.

The problem is also understandable: roxygenize(load = "installed") tries to load an installed package, but it is not yet installed, because it is in the process of being installed. Hence, it requires first pkgbuild::compile_dll, which brings the outlined catch-22 situation. In the documentation it says:

Use this strategy if you have installed a development version of the package already. This is the highest fidelity strategy, but requires work outside of roxygen2.

Does the "work outside of roxygen2" here effectively refer to the type of catch-22 situation that I outlined?

The alternative of using roxygenize(load = "source") also still yields the same error of missing roxygen_devtest.

@gaborcsardi
Copy link
Collaborator

@gaborcsardi gaborcsardi commented Mar 12, 2020

Running

git clean -fdx .
make

builds the R package, including the docs just fine.

@vtraag
Copy link

@vtraag vtraag commented Mar 12, 2020

The problem is that the generated NAMESPACE is incomplete, so that the functions are not correctly exported. That is at least the problem that I experienced when testing locally (before trying it on Travis), because it errors out at some point with the DLLInfo problem reported in this issue. I'm now double checking whether this also does not work on Travis. Can you verify whether the NAMESPACE you generate is correct, @gaborcsardi ? If so, it begs the question how your local setup is different from mine (and Travis, presumably).

Note that the workaround of creating a temporary dummy NAMESPACE file does work on Travis (note that there are still some other issues that result in a failed build, which can be resolved, and on which I am working now).

@gaborcsardi
Copy link
Collaborator

@gaborcsardi gaborcsardi commented Mar 12, 2020

This does not really belong into a closed issue of roxygen2.... but there is no setup or anything:

git clone https://github.com/igraph/rigraph.git
cd rigraph
git submodule init
git submodule update
make
R CMD INSTALL igraph_1.1.2.9000.tar.gz

This does not error anywhere for me.

@vtraag
Copy link

@vtraag vtraag commented Mar 12, 2020

You are right: make does seem to run correctly on Travis, at least for R 3.5. It does not on my machine (also R 3.5), however, and I therefore assumed it would neither on Travis. The output on my local machine (using git clean -fdx followed by make) produces:

First time using roxygen2. Upgrading automatically...
Updating roxygen version in /tmp/tmp.RWJYtN0M6u/DESCRIPTION
Writing NAMESPACE
Loading igraph
Error in getDLLRegisteredRoutines.DLLInfo(dll, addNames = FALSE) : 
  must specify DLL via a “DLLInfo” object. See getLoadedDLLs()
Calls: document ... assignNativeRoutines -> getDLLRegisteredRoutines.DLLInfo
Execution halted
Rscript -e 'devtools::build(path = ".")'
✔  checking for file ‘/home/vtraag/Dropbox/traveller/src/rigraph/DESCRIPTION’ ...
─  preparing ‘igraph’:
✔  checking DESCRIPTION meta-information ...
─  cleaning src
─  checking for LF line-endings in source and make files and shell scripts
─  checking for empty or unneeded directories (382ms)
─  building ‘igraph_1.1.2.9000.tar.gz’

Notice the DLLInfo issue reported here, hence I considered this to be the appropriate place to discuss this. Anyway, I will investigate further what the difference is between my local machine and the setup on Travis.

@gaborcsardi
Copy link
Collaborator

@gaborcsardi gaborcsardi commented Mar 12, 2020

Try to run the make steps one by one, and then go into the temporary directory (/tmp/tmp.RWJYtN0M6u above) and see what is wrong there.

I suspect that your tree is not functional, is this the dev branch as on GitHub or have you modified it?

@vtraag
Copy link

@vtraag vtraag commented Mar 12, 2020

The problem appears with roxygen2 version 7.0.2. The released version of 7.1.0, which was released yesterday, solves the issue. I was testing this already before yesterday, hence, the problem seemed to be related to this issue. Anyway, glad to see it is resolved in version 7.1.0.

@vtraag
Copy link

@vtraag vtraag commented Mar 12, 2020

@gaborcsardi , I can try to see if I can debug the issue further for roxygen2, version 7.0.2, but given it is resolved in version 7.1.0, perhaps that is no longer relevant. Let me know if you want me to take another look at the issue.

@gaborcsardi
Copy link
Collaborator

@gaborcsardi gaborcsardi commented Mar 12, 2020

Oh no, if it works with the new version, that's fine.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.