Thanks. Though, AFAIU, that addresses another use case/need.
I want reverse package dependencies to be able to import functions
from my package using standard R namespace mechanisms, e.g. import()
and importFrom(). The only thing I want to prevent is relying on it
being *attached* to the search()
Hi Henrik,
A bit late, but you can take a look at smbache's {import} package [1]
in case you didn't know it. I believe it does what you are describing.
[1] https://github.com/smbache/import
Iñaki
On Tue, 23 Jun 2020 at 22:21, Henrik Bengtsson
wrote:
>
> Hi,
>
> I'm developing a package whose A
You could go one step down, print a note or a warning.
Also, you could combine different approaches:
Check for an (additional) environment variable.
If set, print a note, if not set, generate a warning (or an error).
That would prevent someone accidently attaching your package, and
would discoura
On 23/06/2020 4:21 p.m., Henrik Bengtsson wrote:
Hi,
I'm developing a package whose API is only meant to be used in other
packages via imports or pkg::foo(). There should be no need to attach
this package so that its API appears on the search() path. As a
maintainer, I want to avoid having it a
Hi,
I'm developing a package whose API is only meant to be used in other
packages via imports or pkg::foo(). There should be no need to attach
this package so that its API appears on the search() path. As a
maintainer, I want to avoid having it appear in search() conflicts by
mistake.
This means
