Dear R-developers,
As part of our package building process, we maintain internal CRAN-like
repositories of our packages. This has worked pretty well, but we are
running into issues with R 3.1 and OSX mavericks.
Specifically, machines with osx mavericks seem to, by default, expect
packages to be located under a 'mavericks' sub-directory, but this is
not the location reported when generating a mac.binary appropriate
contrib url.
>contrib.url('foo')
[1] "foo/bin/macosx/mavericks/contrib/3.1/"
If I ask where the mac binaries are on a linux machine (AND on mac
mavericks machines) I get
>contrib.url('foo',type='mac.binary')
[1] "foo/bin/macosx/mavericks/contrib/3.1/"
But the OSX machine gives an error and fails to locate the packages if
they are located at foo/bin/macosx/contrib/3.1/
So where are the mac binaries supposed to located in a CRAN-like
repository so that they can be installed on a mac with the default
install command? And is there a way for a non-mac machine (i.e. our
linux deploy server) to determine that directory other than
contrib.url(,type='mac.binary) ?
thanks for your help,
-skye
what is the current correct repos structure for mac osx binaries?
6 messages · Skye Bender-deMoll, Simon Urbanek, Brian Ripley
On Jun 13, 2014, at 5:41 PM, Skye Bender-deMoll <skyebend at skyeome.net> wrote:
Dear R-developers, As part of our package building process, we maintain internal CRAN-like repositories of our packages. This has worked pretty well, but we are running into issues with R 3.1 and OSX mavericks. Specifically, machines with osx mavericks seem to, by default, expect packages to be located under a 'mavericks' sub-directory, but this is not the location reported when generating a mac.binary appropriate contrib url.
contrib.url('foo')
[1] "foo/bin/macosx/mavericks/contrib/3.1/" If I ask where the mac binaries are on a linux machine (AND on mac mavericks machines) I get
contrib.url('foo',type='mac.binary')
[1] "foo/bin/macosx/mavericks/contrib/3.1/"
I don't think that is true. On all machines (Linux, OS X, ...) I get
contrib.url('foo', type='mac.binary')
[1] "foo/bin/macosx/contrib/3.1" Note that the type for the mavericks build is "mac.binary.mavericks", so on all machines you also get
contrib.url('foo',type='mac.binary.mavericks')
[1] "foo/bin/macosx/mavericks/contrib/3.1" The only difference are the defaults for pkgType - they differ by the build, but the repo structure is fixed and consistent across all platforms. Cheers, Simon
But the OSX machine gives an error and fails to locate the packages if they are located at foo/bin/macosx/contrib/3.1/ So where are the mac binaries supposed to located in a CRAN-like repository so that they can be installed on a mac with the default install command? And is there a way for a non-mac machine (i.e. our linux deploy server) to determine that directory other than contrib.url(,type='mac.binary) ? thanks for your help, -skye
______________________________________________ R-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
2 days later
Dear R-devel, Apologies for the confusing typo in the reported paths my previous question, thanks to Simon for providing the answer that the default repository type on the mac is now "mac.binary.mavericks" not "mac.binary" as the docs for install.packages state. Perhaps the docs for install packages could be updated something like: ... type character, indicating the type of package to download and install Possible values are (currently) "source", "mac.binary.BUILD_NAME" and "win.binary". The BUILD_NAME on OSX is determined internally by ???. ... I'm still not quite clear how the CRAN-like repository should be structured for OSX. CRAN seems to include .tgz packages in both http://cran.r-project.org/bin/macosx/contrib/3.1/ and http://cran.r-project.org/bin/macosx/mavericks/contrib/3.1/ The directory contents are not identical, but both include packages built as recently as today. Is bin/macosx/contrib/3.1/ a snowleopard build? Do I need to maintain two directories as well? It seems like if I put my packages in http://foo/bin/macosx/contrib/3.1/ the mavericks machines won't find them. But if I put the packages in http://foo/bin/macosx/mavericks/contrib/3.1/ people with the snowleopard build wont find them. Perhaps this is the desired behavior if the mavericks binaries are not snowleopard compatible? thanks again for your help, -skye
On 06/13/2014 05:22 PM, Simon Urbanek wrote:
On Jun 13, 2014, at 5:41 PM, Skye Bender-deMoll <skyebend at skyeome.net> wrote:
Dear R-developers, As part of our package building process, we maintain internal CRAN-like repositories of our packages. This has worked pretty well, but we are running into issues with R 3.1 and OSX mavericks. Specifically, machines with osx mavericks seem to, by default, expect packages to be located under a 'mavericks' sub-directory, but this is not the location reported when generating a mac.binary appropriate contrib url.
contrib.url('foo')
[1] "foo/bin/macosx/mavericks/contrib/3.1/" If I ask where the mac binaries are on a linux machine (AND on mac mavericks machines) I get
contrib.url('foo',type='mac.binary')
[1] "foo/bin/macosx/mavericks/contrib/3.1/"
I don't think that is true. On all machines (Linux, OS X, ...) I get
contrib.url('foo', type='mac.binary')
[1] "foo/bin/macosx/contrib/3.1" Note that the type for the mavericks build is "mac.binary.mavericks", so on all machines you also get
contrib.url('foo',type='mac.binary.mavericks')
[1] "foo/bin/macosx/mavericks/contrib/3.1" The only difference are the defaults for pkgType - they differ by the build, but the repo structure is fixed and consistent across all platforms. Cheers, Simon
But the OSX machine gives an error and fails to locate the packages if they are located at foo/bin/macosx/contrib/3.1/ So where are the mac binaries supposed to located in a CRAN-like repository so that they can be installed on a mac with the default install command? And is there a way for a non-mac machine (i.e. our linux deploy server) to determine that directory other than contrib.url(,type='mac.binary) ? thanks for your help, -skye
______________________________________________ R-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
On Jun 16, 2014, at 1:18 PM, Skye Bender-deMoll <skyebend at skyeome.net> wrote:
Dear R-devel, Apologies for the confusing typo in the reported paths my previous question, thanks to Simon for providing the answer that the default repository type on the mac is now "mac.binary.mavericks" not "mac.binary" as the docs for install.packages state.
That is incorrect. The default varies by the distribution you use. For the "regular" binary based on 10.6+ it is "mac.binary". For the special Mavericks distribution it is "mac.binary.mavericks".
Perhaps the docs for install packages could be updated something like: ... type character, indicating the type of package to download and install Possible values are (currently) "source", "mac.binary.BUILD_NAME" and "win.binary". The BUILD_NAME on OSX is determined internally by ???. ... I'm still not quite clear how the CRAN-like repository should be structured for OSX. CRAN seems to include .tgz packages in both http://cran.r-project.org/bin/macosx/contrib/3.1/ and http://cran.r-project.org/bin/macosx/mavericks/contrib/3.1/ The directory contents are not identical, but both include packages built as recently as today. Is bin/macosx/contrib/3.1/ a snowleopard build? Do I need to maintain two directories as well? It seems like if I put my packages in http://foo/bin/macosx/contrib/3.1/ the mavericks machines won't find them. But if I put the packages in http://foo/bin/macosx/mavericks/contrib/3.1/ people with the snowleopard build wont find them. Perhaps this is the desired behavior if the mavericks binaries are not snowleopard compatible?
Yes, Mavericks build is incompatible with the Snow Leopard build, that's why there are two separate distributions and two separate repositories. Cheers, Simon
thanks again for your help, -skye On 06/13/2014 05:22 PM, Simon Urbanek wrote:
On Jun 13, 2014, at 5:41 PM, Skye Bender-deMoll <skyebend at skyeome.net> wrote:
Dear R-developers, As part of our package building process, we maintain internal CRAN-like repositories of our packages. This has worked pretty well, but we are running into issues with R 3.1 and OSX mavericks. Specifically, machines with osx mavericks seem to, by default, expect packages to be located under a 'mavericks' sub-directory, but this is not the location reported when generating a mac.binary appropriate contrib url.
contrib.url('foo')
[1] "foo/bin/macosx/mavericks/contrib/3.1/" If I ask where the mac binaries are on a linux machine (AND on mac mavericks machines) I get
contrib.url('foo',type='mac.binary')
[1] "foo/bin/macosx/mavericks/contrib/3.1/"
I don't think that is true. On all machines (Linux, OS X, ...) I get
contrib.url('foo', type='mac.binary')
[1] "foo/bin/macosx/contrib/3.1" Note that the type for the mavericks build is "mac.binary.mavericks", so on all machines you also get
contrib.url('foo',type='mac.binary.mavericks')
[1] "foo/bin/macosx/mavericks/contrib/3.1" The only difference are the defaults for pkgType - they differ by the build, but the repo structure is fixed and consistent across all platforms. Cheers, Simon
But the OSX machine gives an error and fails to locate the packages if they are located at foo/bin/macosx/contrib/3.1/ So where are the mac binaries supposed to located in a CRAN-like repository so that they can be installed on a mac with the default install command? And is there a way for a non-mac machine (i.e. our linux deploy server) to determine that directory other than contrib.url(,type='mac.binary) ? thanks for your help, -skye
______________________________________________ R-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
1 day later
Please forgive another comment on this topic. The 'type' argument to tools::write_PACKAGES doesn't currently accept the 'mac.binary.mavericks' value. It seems like it should, to make it possible to pass the same 'type' argument to all of the package generation and manipulation functions? > tools::write_PACKAGES(type='mac.binary.mavericks') Error in match.arg(type) : 'arg' should be one of ?source?, ?mac.binary?, ?win.binary? best, -skye
On 06/16/2014 11:32 AM, Simon Urbanek wrote:
On Jun 16, 2014, at 1:18 PM, Skye Bender-deMoll <skyebend at skyeome.net> wrote:
Dear R-devel, Apologies for the confusing typo in the reported paths my previous question, thanks to Simon for providing the answer that the default repository type on the mac is now "mac.binary.mavericks" not "mac.binary" as the docs for install.packages state.
That is incorrect. The default varies by the distribution you use. For the "regular" binary based on 10.6+ it is "mac.binary". For the special Mavericks distribution it is "mac.binary.mavericks".
On 17/06/2014 21:38, Skye Bender-deMoll wrote:
Please forgive another comment on this topic.
But it is not on the topic ... this function is run on a single directory.
The 'type' argument to tools::write_PACKAGES doesn't currently accept the 'mac.binary.mavericks' value. It seems like it should, to make it possible to pass the same 'type' argument to all of the package generation and manipulation functions?
> tools::write_PACKAGES(type='mac.binary.mavericks')
Error in match.arg(type) : 'arg' should be one of ?source?, ?mac.binary?, ?win.binary?
Functions 'should' do what they are documented to do:
type: Type of packages: currently source ?.tar.gz? archives, and
Mac or Windows binary (?.tgz? or ?.zip?, respectively)
packages are supported. Defaults to ?"win.binary"? on
Windows and to ?"source"? otherwise.
All Mac binary packages are .tgz. We had Universal and Leopard packages
for a long time with using type = "mac.binary" here. The
specializations of that type are only used where needed.
It does do the job it was designed and documented to do.
best, -skye
Brian D. Ripley, ripley at stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UK Fax: +44 1865 272595