Restrict package to load-only access - prevent attempts to attach it

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Restrict package to load-only access - prevent attempts to attach it

Henrik Bengtsson-5
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 that, for instance, other packages should declare this
package under 'Imports' or 'Suggests' but never under 'Depends'.  I
can document this and hope that's how it's going to be used.  But, I'd
like to make it explicit that this API should be used via imports or
::.  One approach I've considered is:

.onAttach <- function(libname, pkgname) {
   if (nzchar(Sys.getenv("R_CMD"))) return()
   stop("Package ", sQuote(pkgname), " must not be attached")
}

This would produce an error if the package is attached.  It's
conditioned on the environment variable 'R_CMD' set by R itself
whenever 'R CMD ...' runs.  This is done to avoid errors in 'R CMD
INSTALL' and 'R CMD check' "load tests", which formally are *attach*
tests.  The above approach passes all the tests and checks I'm aware
of and on all platforms.

Before I ping the CRAN team explicitly, does anyone know whether this
is a valid approach?  Do you know if there are alternatives for
asserting that a package is never attached.  Maybe this is more
philosophical where the package "contract" is such that all packages
should be attachable and, if not, then it's not a valid R package.

This is a non-critical topic but if it can be done it would be useful.

Thanks,

Henrik

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Restrict package to load-only access - prevent attempts to attach it

Duncan Murdoch-2
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 appear in search() conflicts by
> mistake.
>
> This means that, for instance, other packages should declare this
> package under 'Imports' or 'Suggests' but never under 'Depends'.  I
> can document this and hope that's how it's going to be used.  But, I'd
> like to make it explicit that this API should be used via imports or
> ::.  One approach I've considered is:
>
> .onAttach <- function(libname, pkgname) {
>     if (nzchar(Sys.getenv("R_CMD"))) return()
>     stop("Package ", sQuote(pkgname), " must not be attached")
> }
>
> This would produce an error if the package is attached.  It's
> conditioned on the environment variable 'R_CMD' set by R itself
> whenever 'R CMD ...' runs.  This is done to avoid errors in 'R CMD
> INSTALL' and 'R CMD check' "load tests", which formally are *attach*
> tests.  The above approach passes all the tests and checks I'm aware
> of and on all platforms.
>
> Before I ping the CRAN team explicitly, does anyone know whether this
> is a valid approach?  Do you know if there are alternatives for
> asserting that a package is never attached.  Maybe this is more
> philosophical where the package "contract" is such that all packages
> should be attachable and, if not, then it's not a valid R package.
>
> This is a non-critical topic but if it can be done it would be useful.

Speaking from the philosophical side, I think this is probably a bad
idea.  Presumably you have some idea of how your package will be used,
but in my experience, really interesting things happen when such
assumptions aren't met, and people use code in different ways.

So I'd prefer that you didn't try to prevent me from using your package
in some weird way.  It's fine if you document that it's intended to be
used in some particular way, but why try to prevent me from using it
differently?  Just tell me to read the docs when problems arise because
of my misuse and I ask you for help.

Duncan Murdoch

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Restrict package to load-only access - prevent attempts to attach it

Abby Spurdle
In reply to this post by Henrik Bengtsson-5
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 discourage them from doing it.
But would also allow people to attach your package, if they really want to.


On Wed, Jun 24, 2020 at 8:21 AM Henrik Bengtsson
<[hidden email]> 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 appear in search() conflicts by
> mistake.
>
> This means that, for instance, other packages should declare this
> package under 'Imports' or 'Suggests' but never under 'Depends'.  I
> can document this and hope that's how it's going to be used.  But, I'd
> like to make it explicit that this API should be used via imports or
> ::.  One approach I've considered is:
>
> .onAttach <- function(libname, pkgname) {
>    if (nzchar(Sys.getenv("R_CMD"))) return()
>    stop("Package ", sQuote(pkgname), " must not be attached")
> }
>
> This would produce an error if the package is attached.  It's
> conditioned on the environment variable 'R_CMD' set by R itself
> whenever 'R CMD ...' runs.  This is done to avoid errors in 'R CMD
> INSTALL' and 'R CMD check' "load tests", which formally are *attach*
> tests.  The above approach passes all the tests and checks I'm aware
> of and on all platforms.
>
> Before I ping the CRAN team explicitly, does anyone know whether this
> is a valid approach?  Do you know if there are alternatives for
> asserting that a package is never attached.  Maybe this is more
> philosophical where the package "contract" is such that all packages
> should be attachable and, if not, then it's not a valid R package.
>
> This is a non-critical topic but if it can be done it would be useful.
>
> Thanks,
>
> Henrik
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Restrict package to load-only access - prevent attempts to attach it

Iñaki Ucar
In reply to this post by Henrik Bengtsson-5
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
<[hidden email]> 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 appear in search() conflicts by
> mistake.
>
> This means that, for instance, other packages should declare this
> package under 'Imports' or 'Suggests' but never under 'Depends'.  I
> can document this and hope that's how it's going to be used.  But, I'd
> like to make it explicit that this API should be used via imports or
> ::.  One approach I've considered is:
>
> .onAttach <- function(libname, pkgname) {
>    if (nzchar(Sys.getenv("R_CMD"))) return()
>    stop("Package ", sQuote(pkgname), " must not be attached")
> }
>
> This would produce an error if the package is attached.  It's
> conditioned on the environment variable 'R_CMD' set by R itself
> whenever 'R CMD ...' runs.  This is done to avoid errors in 'R CMD
> INSTALL' and 'R CMD check' "load tests", which formally are *attach*
> tests.  The above approach passes all the tests and checks I'm aware
> of and on all platforms.
>
> Before I ping the CRAN team explicitly, does anyone know whether this
> is a valid approach?  Do you know if there are alternatives for
> asserting that a package is never attached.  Maybe this is more
> philosophical where the package "contract" is such that all packages
> should be attachable and, if not, then it's not a valid R package.
>
> This is a non-critical topic but if it can be done it would be useful.
>
> Thanks,
>
> Henrik
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel



--
Iñaki Úcar

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Restrict package to load-only access - prevent attempts to attach it

Henrik Bengtsson-5
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() path and access functions that way.
So, basically, all usage should be via import(), importFrom()
NAMESPACE statements or pkg::fcn() calls.  All for the purpose of
avoiding the package being used outside of other packages.

I've got a few suggestions offline in addition to the above comments
including allowing the package to be attached but having .onAttach()
wipe the attached environment so it effectively adds zero objects to
the search() path.  This is a non-critical feature for me but
nevertheless an interesting one.

/Henrik

On Fri, Jul 17, 2020 at 1:01 PM Iñaki Ucar <[hidden email]> wrote:

>
> 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
> <[hidden email]> 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 appear in search() conflicts by
> > mistake.
> >
> > This means that, for instance, other packages should declare this
> > package under 'Imports' or 'Suggests' but never under 'Depends'.  I
> > can document this and hope that's how it's going to be used.  But, I'd
> > like to make it explicit that this API should be used via imports or
> > ::.  One approach I've considered is:
> >
> > .onAttach <- function(libname, pkgname) {
> >    if (nzchar(Sys.getenv("R_CMD"))) return()
> >    stop("Package ", sQuote(pkgname), " must not be attached")
> > }
> >
> > This would produce an error if the package is attached.  It's
> > conditioned on the environment variable 'R_CMD' set by R itself
> > whenever 'R CMD ...' runs.  This is done to avoid errors in 'R CMD
> > INSTALL' and 'R CMD check' "load tests", which formally are *attach*
> > tests.  The above approach passes all the tests and checks I'm aware
> > of and on all platforms.
> >
> > Before I ping the CRAN team explicitly, does anyone know whether this
> > is a valid approach?  Do you know if there are alternatives for
> > asserting that a package is never attached.  Maybe this is more
> > philosophical where the package "contract" is such that all packages
> > should be attachable and, if not, then it's not a valid R package.
> >
> > This is a non-critical topic but if it can be done it would be useful.
> >
> > Thanks,
> >
> > Henrik
> >
> > ______________________________________________
> > [hidden email] mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
>
> --
> Iñaki Úcar

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel