[R-pkg-devel] How do I prevent macOS from attempting to build my package?
Package status reports come in three different severities: NOTE, WARNING, and
ERROR. Motivated by Brodie's nice (dependency-free) accessor function for
per-maintainer status [1], I have looked into reducing the number of ERRORs.
I hit a road block. Several of my packages depend on external libraries that
must be present. I test for these in configure, but their absence is still an
ERROR. This makes the situation on macOS a little delicate. Simon, who is
doing, and always done, a metric ton of work around R and OS X / maxOS is the
only one who could change this but I cannot realistically ask him to keep a
number of (in some cases more difficult or esoteric) libraries afloat. And
some of these have now been missing on his platform for several years.
And in one case (RcppAPT, requiring libapt-dev) the build is even
imppossible. Now, the Fedora maintainer knows this and has the build
blacklisted.
Hence:
R> source("checkCRAN.R")
Package ERROR WARN NOTE OK
[...]
23 RcppAPT 24
[...]
No failures from Fedora. But two from macOS which I can never ever get rid
off (unless I do silly code acrobatics by #ifdef'ing all real code away).
So here is my question: Can we we please refine
OS_type: unix
a little more, and/or maybe allow other blacklists in the package upload?
Thoughts or comments most welcome.
Thanks, Dirk
[1]
https://gist.github.com/brodieG/e60c94d4036f45018530ea504258bcf3#file-cran-check-r
--
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Downloading software as part of package installation
On 04.09.2018 04:18, David B. Dahl wrote: I would like advise and help in interpreting a part of the CRAN Repository Policy. It states, "Downloads of additional software or data as part of package installation or startup should only use secure download mechanisms (e.g., ‘https’ or ‘ftps’)." From this, I take that it is permissible for a package to use its .onLoad function to download and install files in the package's subdirectory. E.g., for the package 'foo', the .onLoad function could place items in a subdirectory of 'system.file(package="foo")'. Since package installation called the .onLoad function when "testing if installed package can be loaded," this would work (assuming the computer has internet access at the time, otherwise the download could be skipped). Once downloaded, the package wouldn't need to download it ever again. The benefit of this approach is that the additional software is automatically downloaded when the package is installed, rather than the user knowing they having to manually call a special function to download the software (to another location) after package installation. Does this seem like a valid approach for CRAN? And, does the answer change when I get R CMD check says: checking installed package size ... NOTE installed size is 182.1Mb Think about license issues: A binary CRAN package (e.g. for Mac or Windows) will contain that other software while the source package does not. Hence it may be a license violation depoending on the license of the software you download. Best, Uwe Ligges This is just a NOTE, so my understanding is that is permissible. Any thoughts? Thanks!! -- David __ R-package-devel@r-project.org mailing list 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
Re: [R-pkg-devel] How do I prevent macOS from attempting to build my package?
On 04.09.2018 16:36, Dirk Eddelbuettel wrote:
Package status reports come in three different severities: NOTE, WARNING, and
ERROR. Motivated by Brodie's nice (dependency-free) accessor function for
per-maintainer status [1], I have looked into reducing the number of ERRORs.
I hit a road block. Several of my packages depend on external libraries that
must be present. I test for these in configure, but their absence is still an
ERROR. This makes the situation on macOS a little delicate. Simon, who is
doing, and always done, a metric ton of work around R and OS X / maxOS is the
only one who could change this but I cannot realistically ask him to keep a
number of (in some cases more difficult or esoteric) libraries afloat. And
some of these have now been missing on his platform for several years.
And in one case (RcppAPT, requiring libapt-dev) the build is even
imppossible. Now, the Fedora maintainer knows this and has the build
blacklisted.
Hence:
R> source("checkCRAN.R")
Package ERROR WARN NOTE OK
[...]
23 RcppAPT 24
[...]
No failures from Fedora. But two from macOS which I can never ever get rid
off (unless I do silly code acrobatics by #ifdef'ing all real code away).
So here is my question: Can we we please refine
OS_type: unix
a little more, and/or maybe allow other blacklists in the package upload?
Thoughts or comments most welcome.
Comments:
Disclaimer for this field in general (as others are listening, too): we
should always try not to use it alt all and produce cross platform code.
In your specific case: You can try to ask Simon or discuss this on
R-devel so that most R-core members will read this, too.
Best,
Uwe
Thanks, Dirk
[1]
https://gist.github.com/brodieG/e60c94d4036f45018530ea504258bcf3#file-cran-check-r
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] How do I prevent macOS from attempting to build my package?
On 4 September 2018 at 17:07, Uwe Ligges wrote: | Disclaimer for this field in general (as others are listening, too): we | should always try not to use it alt all and produce cross platform code. It would be nice if the CRAN system was more open so that contributed builds could be used. With my Debian hat on I have at times "cheated" by packaging a library so that Kurt would have it on the Debian machines he uses. But I have no means to influence Simon's machine, nor the option to have my package built or tested elsewhere for that particular OS. | In your specific case: You can try to ask Simon or discuss this on | R-devel so that most R-core members will read this, too. Posted to r-devel. Cheers, Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Downloading software as part of package installation
Uwe: Oh, right, I wasn't thinking about binary packages. Thanks! -- David On Tue, Sep 4, 2018 at 9:02 AM Uwe Ligges wrote: > > > > On 04.09.2018 04:18, David B. Dahl wrote: > > I would like advise and help in interpreting a part of the CRAN > > Repository Policy. It states, "Downloads of additional software or > > data as part of package installation or startup should only use secure > > download mechanisms (e.g., ‘https’ or ‘ftps’)." > > > > From this, I take that it is permissible for a package to use its > > .onLoad function to download and install files in the package's > > subdirectory. E.g., for the package 'foo', the .onLoad function could > > place items in a subdirectory of 'system.file(package="foo")'. Since > > package installation called the .onLoad function when "testing if > > installed package can be loaded," this would work (assuming the > > computer has internet access at the time, otherwise the download could > > be skipped). Once downloaded, the package wouldn't need to download > > it ever again. > > > > The benefit of this approach is that the additional software is > > automatically downloaded when the package is installed, rather than > > the user knowing they having to manually call a special function to > > download the software (to another location) after package > > installation. > > > > Does this seem like a valid approach for CRAN? > > > > And, does the answer change when I get R CMD check says: > > > > checking installed package size ... NOTE > >installed size is 182.1Mb > > Think about license issues: > A binary CRAN package (e.g. for Mac or Windows) will contain that other > software while the source package does not. Hence it may be a license > violation depoending on the license of the software you download. > > Best, > Uwe Ligges > > > > This is just a NOTE, so my understanding is that is permissible. > > > > Any thoughts? Thanks!! > > > > -- David > > > > __ > > R-package-devel@r-project.org mailing list > > 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
