Von: "Kurt Hornik" <Kurt.Hornik at wu.ac.at>
An: "Laurent Gatto" <lgatto at protonmail.ch>
CC: "Kurt Hornik" <Kurt.Hornik at wu.ac.at>, "Trevor Davis" <trevor.l.davis at gmail.com>, r-devel at r-project.org, "roland
fuss" <roland.fuss at thuenen.de>
Gesendet: Dienstag, 3. Juni 2025 19:23:01
Betreff: Re: [Rd] FR: improve "use" function
Thanks.
In general, I guess we all agree that if 'include.only' or 'exclude' ask
for something (currently) impossible then a suitably classed condition
object should be thrown. Could be both a warning or an error ...
And perhaps we should take 'include.only' as 'include', i.e., be fine
when we give 'include.only' as a subset of what is already included.
Personally, I am not a big fan of suggesting to use detach() in the
condition message.
Best
-k
On Tuesday, May 27th, 2025 at 9:13 AM, Kurt Hornik <Kurt.Hornik at wu.ac.at> wrote:
Thanks.
This is really about what
library("foo", include.only = "fun2")
should do if package 'foo' was already attached and the include.only
contradicts a previous specification.
In principle, one could look into allowing the underlying
attachNamespace() to add more exports into the package environment (the
'only' in 'include.only' might suggest differently, but we would have to
live with that). However, using detach/attach is not the right way of
doing this, as it possibly modifies the search path and may trigger
hooks that should not be triggered. Doing it right would probably need
an .Internal and hence be a lot of work ...
What definitely needs attention is the fact that currently the above is
silently ignored. So at least for now we should teach attachNamespace()
to throw a suitably classed error if called with include.only that
contradicts a previous specification.
Contributions welcome :-)
Some work has been done on that front during last week's r-dev-day
with Ella Kaye and Philippe Grosjean [1]. After some more thinking, I
think we haven't been stringent enough, and would suggest that the
user should be alerted as soon as what they want to attach doesn't
match exactly what is already on the search path. Something along the
lines of (the warning/message can of course be amended).
These two situations are OK, given that exactly the same set is asked
for repeated, either with a limited set of functions:
library("Matrix", include.only = "isDiagonal")
library("Matrix", include.only = "isDiagonal") ## ok
or, in a new session, with the whole package:
library("Matrix", include.only = "isDiagonal")
library("Matrix", include.only = "isDiagonal") ## ok
Below, (again, in a new session) the user could be mislead that either
only qr would be attached (and isDiagonal not anymore), or all
Matrix's exported symbols:
library("Matrix", include.only = "isDiagonal")
library("Matrix", include.only = "qr") ## warn
Warning message:
In library("Matrix", include.only = "qr") :
The package 'Matrix' is already loaded with a different set of functions. Please
detach() it first.
library("Matrix") ## warn
Warning message:
In library("Matrix") :
The package 'Matrix' is already loaded with a different set of functions. Please
detach() it first.
In the following cases, a subset is asked after all symbols are
attached, which also triggers a warning/message:
library("Matrix")
library("Matrix", exclude = "isDiagonal") ## warn
Warning message:
In library("Matrix", exclude = "isDiagonal") :
The package 'Matrix' is already loaded with a different set of functions. Please
detach() it first.
library("Matrix", include.only = "isDiagonal") ## warn
Warning message:
In library("Matrix", include.only = "isDiagonal") :
The package 'Matrix' is already loaded with a different set of functions. Please
detach() it first.
If this is a good way forward, I would be happy to carry on that work.