On 10.01.2024 15:35, Josiah Parry wrote:
Thanks, all. As it goes, the package submission failed. The package that is suggested is available at https://r.esri.com/bin/ <https://r.esri.com/bin/> and as such provided `https://r.esri.com <https://r.esri.com>` as the url in `Additional_repositories`.

There is no

https://r.esri.com/src

hence it is obviously not a standard repository.


The request was to remove the additional repositories and provide instructions for package installation in the Description field. This package, arcgisbinding, is used in one line of the entire package https://github.com/R-ArcGIS/arcgisutils/blob/64093dc1a42fa28010cd45bb6ae8b8c57835cb40/R/arc-auth.R#L123 <https://github.com/R-ArcGIS/arcgisutils/blob/64093dc1a42fa28010cd45bb6ae8b8c57835cb40/R/arc-auth.R#L123> to extract an authorization token. It is provided for compatibility with a semi-closed-source R package. The installation instructions for which are....lengthy (https://r.esri.com/r-bridge-site/arcgisbinding/installing-arcgisbinding.html <https://r.esri.com/r-bridge-site/arcgisbinding/installing-arcgisbinding.html>) and /only /available as a windows binary. Providing an explicit call out for installation in the "Description" field of the DESCRIPTION feels like it is co-opting the Description to describe the installation process for a function that I anticipate /very few /people to use.

So you can either remove the need for that package or say something like ".... and if an authorization token is to be extracted on Windows, the 'arcgisbinding' package is needed that can be installed as explained at <https://r.esri.com>."

Best,
Uwe Ligges




Is there another approach that can be taken here? The one requested feels like an incorrect use of the description field because it no longer describes the package but how to handle one very rare edge case.

On Wed, Jan 3, 2024 at 12:36 PM Uwe Ligges <lig...@statistik.tu-dortmund.de <mailto:lig...@statistik.tu-dortmund.de>> wrote:

      From the CRAN polcies:

    "Packages on which a CRAN package depends should be available from a
    mainstream repository: if any mentioned in ‘Suggests’ or ‘Enhances’
    fields are not from such a repository, where to obtain them at a
    repository should be specified in an ‘Additional_repositories’ field of
    the DESCRIPTION file (as a comma-separated list of repository URLs) or
    for other means of access, described in the ‘Description’ field. "

    Best,
    Uwe Ligges




    On 03.01.2024 18:19, Josiah Parry wrote:
     > Thanks, both. I'm not familiar with Additional_repositories. Must
    the
     > package source be specified there? Or can it be specified via
     > documentation a la Rd file?
     >
     > On Wed, Jan 3, 2024 at 12:14 PM Uwe Ligges
     > <lig...@statistik.tu-dortmund.de
    <mailto:lig...@statistik.tu-dortmund.de>
     > <mailto:lig...@statistik.tu-dortmund.de
    <mailto:lig...@statistik.tu-dortmund.de>>> wrote:
     >
     >
     >
     >     On 03.01.2024 17:58, Duncan Murdoch wrote:
     >      > On 03/01/2024 11:33 a.m., Josiah Parry wrote:
     >      >> I have a scenario where I have an exported function that
     >     requires the
     >      >> installation a package that *is not* available on CRAN.
    The body
     >     of the
     >      >> function is generally:
     >      >>
     >      >> fx <- function() {
     >      >>    rlang::check_installed("noncranpkg")
     >      >>    noncranpkg::gx()
     >      >> }
     >      >>
     >      >> As required, this package is in the Suggests field. But this
     >     results in a
     >      >> note:
     >      >>
     >      >> checking package dependencies ... NOTE
     >      >> Package suggested but not available for checking:
    ‘noncranpkg’
     >      >>
     >      >> Can this be safely ignored?
     >      >
     >      > Uwe said yes, and he's an authority.  But for your users, it
     >     might be
     >      > nice to include an Additional_repositories field so they
    can find
     >     the
     >      > package.  This needs to be organized as an actual
    repository; the
     >     drat
     >      > package is a very convenient way to set one up.
     >
     >     Thanks for elaborating, yes of course, people have to declare
    where to
     >     get the package from. The note from above is still unavoidable in
     >     that case.
     >
     >     Best,
     >     Uwe
     >
     >      >
     >      > Duncan Murdoch
     >      >
     >      > ______________________________________________
     >      > R-package-devel@r-project.org
    <mailto:R-package-devel@r-project.org>
     >     <mailto:R-package-devel@r-project.org
    <mailto:R-package-devel@r-project.org>> mailing list
     >      > https://stat.ethz.ch/mailman/listinfo/r-package-devel
    <https://stat.ethz.ch/mailman/listinfo/r-package-devel>
     >     <https://stat.ethz.ch/mailman/listinfo/r-package-devel
    <https://stat.ethz.ch/mailman/listinfo/r-package-devel>>
     >

______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Reply via email to