Mistake in documentation and question on install.package

[tony-aw]

Hi,

In the documentation of groundhog::groundhog.library(), the description for argument force.install has a mistake, for it reads: "logical (defaults to FALSE). When set to TRUE, will" ... Will what? The sentence is not finished; Please correct this.

I also have a question: groundhog.library() installs AND loads a package; is there also a function to only install a package without immediately loading it; i.e. something like groundhog.install() ? Because I don't see it explained in the documentation.

Thank you in advance for your time.

Kind regards,

Tony.

[urisohn]

1. Thanks, will fix with next release.
2. Not currently. Would be easy enough to add, What's a use case for installing specific versions of packages but not loading them?

Finalizing v3.0.0 so feedback is quite timely.

[tony-aw]

Thank you for the quick response.

The use cases of installing but not attaching an R package should be fairly obvious; here are a few use cases with examples:

• Sometimes package A has additional, optional functionality if package B is installing (so B would be a suggested package for A, not a dependency). In such a case, loading and attaching package B merely for additional functionality in package A might pollute your namespace. A practical example would be ggplot2: It requires the hexbin package for hexagonal binning. But I wouldn’t want to attach hexbin in its entirely: its a large package, and might mask functions from other packages, which forces me to deal with masking.
• Suppose package A and package B are both required, but have some overlapping namespace. In that case I want to attach neither of them, and always use A::some_function() andB::some_function(). If packages Aand B have long names, I probably I would want to alias both packages instead. For example, the data.table and lubridate packages have some overlapping namespaces. I can solve this by loading data.table as dt <- loadNamespace(“data.table”) and lubridate as lub <- loadNamespace(“lubridate”). In both cases, the packages are not attached (i.e. no library() or require() is run).
• Sometimes a single script requires many, many R packages. And it becomes increasingly unclear which function came from which package, which can become problematic - especially when debugging the script. The solution is the same as in the previous point: constantly use ::, or alias the R packages. Again, in both cases, the packages are not actually attached (i.e. no library() or require() is run).

There may be more use cases, but I don’t want to make this message too long, so I’ll leave it to this. Please note the difference between attaching and loading an R package: aliasing an R package "A", using A::some_function(), and even calling a function that internally uses package A will all technically load package A, but it will not attach package A. Only explicitly attaching a package requires the functions library() or require().

Thank you again for your time.

Kind regards,

Tony.

[urisohn]

I see. These are cases where attaching is not necessary, but i don't think attaching causes any problems. You can still do pkgB:: when pkgA (or pkgB) is already attached.

The first case involved suggested dependencies, you don't need to do that by hand, you just instruct groundhog to get the suggested packages too: groundhog.library(pkgA,date,include.suggests=TRUE)

Is there any case where attaching would cause a problem you think? Or simply, where you would actively prefer not to attach?

btw: i see now that i used the word 'loading' too loosely in my first response. I should have said what's a use case for installing and not attaching. Sorry

[tony-aw]

Hi,

Thank you once again for the quick response.

To immediately answer your question: Yes, there are certainly cases where using library() is explicitly not preferred.

For example: The dplyr R package overwrites (and explicitly changes!) functions from stats and even base (!) functions when attached. As these are core R packages, obviously one may often want to keep the base and stats functionality as-is. With groundhog, I cannot load (without attaching) dplyr, thus I cannot use dplyr without overwriting functions from stats. Since stats and base are core R packages, this behaviour may be very unwanted.

I may think of more examples where library() / require() is unwanted, but I'm trying to keep this short, and I trust one example is sufficient.

Now, are there other ways around the issue given in the above example? Sure there are (I could list alternative approaches here, but I'm trying to keep this short). But all alternative ways I can think of are more convoluted than simply using :: or alias <- loadNamespace(...) and excluding library / require.

Therefore, I would greatly appreciate it if some sort of groundhog.install() function is added to groundhog that installs a package, but doesn't do anything beyond that. Since groundhog.library() already has the install functionality, I assume creating a pure groundhog.install() function shouldn't be too problematic. And I trust my request isn't so weird.

By the way: You don't need to apologize for using "loading" and "attaching" interchangeably. In this particular context, this distinction happens to be relevant. But often these words are used interchangeably (also I sometimes use them interchangeably, and I'm very particular about my terminology :-) ).

Thank you for taking the time reading through my long messages.

Kind regards,

Tony

[urisohn]

Yeah, ok. I am persuaded. I will add the option install.only=TRUE to groundhog.library() which will install but not load or attach any of the packages.

(i am afraid that if it were a separate function people would be confused as to whether they need to always run it the way install.packages() needs to be run)

[tony-aw]

Thank you! Much appreciated! :-)

(I personally don't care if it is a separate function, or an argument within an existing function; groundhog.install() was merely an example of a possible function name).

Kind regards,

Tony.

[urisohn]

On further consideration i decided not to do this, at least for now. It seems to add ambiguity regarding both just what version of packages are being used on a script and how to use groundhog. Ultimately what is missing from the R architecture in general is a command(s) that defines the set of packages to be used on a script without attaching them. Base R does not have it because the entire library is used by default without stipulating it in any given script, so a person reading a script does not knwo what package versions are being used. That's what having an install.only option would entail, you start a script, define packages to be used, whether attached or not, and then explicitly mention any package you use. I do like that and think it is a superior way of communicating to other users what package (versions) are being used . But it is not how R works, and I am afraid that having only groundhog work that way will create ambiguity and confusion. So I rather stick closer to the notion that you are replacing library() with groundhoglibrary. This is a judgment call and I am close to the fence, I may revisit in the future. But v3.0.0 will not have this capability.