An embedded and charset-unspecified text was scrubbed... Name: not available URL: <https://stat.ethz.ch/pipermail/r-devel/attachments/20140417/335f1929/attachment.pl>
R-3.1.0 OSX Snow Leopard installs old binary
16 messages · Gábor Csárdi, Dan Tenenbaum, Simon Urbanek
On Apr 17, 2014, at 9:30 AM, G?bor Cs?rdi <csardi.gabor at gmail.com> wrote:
Hi All, I am not sure why this happens, but apparently an old binary is installed by default. Downloading and installing the new binary by hand works fine.
I think you may be misinterpreting - the is no binary for igraph 0.7 because it fails make check, so I don't see how "Downloading and installing the new binary by hand works fine." can be true. The *source* is available so you can compile it from sources, but that's different that what you asked for which was to install the *binary*. Cheers, Simon
Is this the intended behavior? If yes, may I ask what is the reason for it? Thanks, Gabor
install.packages("igraph")
There is a binary version available (and will be installed) but the
source version is later:
binary source
igraph 0.6.5-2 0.7.0
trying URL '
http://cran.rstudio.com/bin/macosx/contrib/3.1/igraph_0.6.5-2.tgz'
Content type 'application/x-gzip' length 4466270 bytes (4.3 Mb)
opened URL
==================================================
downloaded 4.3 Mb
The downloaded binary packages are in
/var/folders/ws/7rmdm_cn2pd8l1c3lqyycv0c0000gn/T//RtmpJiLDYF/downloaded_packages
sessionInfo()
R version 3.1.0 (2014-04-10) Platform: x86_64-apple-darwin10.8.0 (64-bit) locale: [1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8 attached base packages: [1] stats graphics grDevices utils datasets methods base loaded via a namespace (and not attached): [1] tools_3.1.0 [[alternative HTML version deleted]]
______________________________________________ R-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
An embedded and charset-unspecified text was scrubbed... Name: not available URL: <https://stat.ethz.ch/pipermail/r-devel/attachments/20140417/88b81faa/attachment.pl>
An embedded and charset-unspecified text was scrubbed... Name: not available URL: <https://stat.ethz.ch/pipermail/r-devel/attachments/20140417/ea581591/attachment.pl>
----- Original Message -----
From: "G?bor Cs?rdi" <csardi.gabor at gmail.com> To: "Simon Urbanek" <simon.urbanek at r-project.org> Cc: r-devel at r-project.org Sent: Thursday, April 17, 2014 4:42:50 PM Subject: Re: [Rd] R-3.1.0 OSX Snow Leopard installs old binary On Thu, Apr 17, 2014 at 5:18 PM, Simon Urbanek <simon.urbanek at r-project.org>wrote:
On Apr 17, 2014, at 9:30 AM, G?bor Cs?rdi <csardi.gabor at gmail.com> wrote:
Hi All, I am not sure why this happens, but apparently an old binary is installed by default. Downloading and installing the new binary by hand works fine.
I think you may be misinterpreting - the is no binary for igraph 0.7 because it fails make check,
Btw. it fails R CMD check (there is no make check afaik) because it suggests a BioC package (graph), that is not available.
The graph package is available: http://www.bioconductor.org/packages/release/bioc/html/graph.html ...but maybe not installed on the CRAN build machine. All of this would make more sense if the OP was using the Mavericks build of R because we don't yet have BioC binary packages for that, but his original sessionInfo() showed that he was using the Snow Leopard build.
Can CRAN packages not depend on BioC packages any more?
I think they can. graph is in igraph's Suggests. If CRAN packages could not depend on BioC packages, I would imagine that igraph would be removed from CRAN until it got rid of that dependency. Dan
Thanks, Gabor [...] [[alternative HTML version deleted]]
______________________________________________ R-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
On Apr 17, 2014, at 6:31 PM, G?bor Cs?rdi <csardi.gabor at gmail.com> wrote:
On Thu, Apr 17, 2014 at 5:18 PM, Simon Urbanek <simon.urbanek at r-project.org> wrote: On Apr 17, 2014, at 9:30 AM, G?bor Cs?rdi <csardi.gabor at gmail.com> wrote:
Hi All, I am not sure why this happens, but apparently an old binary is installed by default. Downloading and installing the new binary by hand works fine.
I think you may be misinterpreting - the is no binary for igraph 0.7 because it fails make check, so I don't see how "Downloading and installing the new binary by hand works fine." can be true. What is the tgz linked from here, then? http://cran.r-project.org/web/packages/igraph/index.html
That is the 3.0 package. Sorry, my bad, the symlinks have not been switched from prerelease to release - my bad, now fixed. Cheers, Simon
Gabor The *source* is available so you can compile it from sources, but that's different that what you asked for which was to install the *binary*. Cheers, Simon
Is this the intended behavior? If yes, may I ask what is the reason for it? Thanks, Gabor
install.packages("igraph")
There is a binary version available (and will be installed) but the
source version is later:
binary source
igraph 0.6.5-2 0.7.0
trying URL '
http://cran.rstudio.com/bin/macosx/contrib/3.1/igraph_0.6.5-2.tgz'
Content type 'application/x-gzip' length 4466270 bytes (4.3 Mb)
opened URL
==================================================
downloaded 4.3 Mb
The downloaded binary packages are in
/var/folders/ws/7rmdm_cn2pd8l1c3lqyycv0c0000gn/T//RtmpJiLDYF/downloaded_packages
sessionInfo()
R version 3.1.0 (2014-04-10)
Platform: x86_64-apple-darwin10.8.0 (64-bit)
locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] tools_3.1.0
[[alternative HTML version deleted]]
______________________________________________ R-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
On Apr 17, 2014, at 7:42 PM, G?bor Cs?rdi <csardi.gabor at gmail.com> wrote:
On Thu, Apr 17, 2014 at 5:18 PM, Simon Urbanek <simon.urbanek at r-project.org> wrote: On Apr 17, 2014, at 9:30 AM, G?bor Cs?rdi <csardi.gabor at gmail.com> wrote:
Hi All, I am not sure why this happens, but apparently an old binary is installed by default. Downloading and installing the new binary by hand works fine.
I think you may be misinterpreting - the is no binary for igraph 0.7 because it fails make check, Btw. it fails R CMD check (there is no make check afaik) because it suggests a BioC package (graph), that is not available. Can CRAN packages not depend on BioC packages any more?
No, the issue is that igraph suggests graph yet fails when it's not present. It should guard against failure is case it's not available. I didn't look at this particular case, but sometimes that is necessary to break infinite dependency loops. Cheers, Simon
An embedded and charset-unspecified text was scrubbed... Name: not available URL: <https://stat.ethz.ch/pipermail/r-devel/attachments/20140417/f46aa0f7/attachment.pl>
On Apr 17, 2014, at 9:24 PM, G?bor Cs?rdi <csardi.gabor at gmail.com> wrote:
On Thu, Apr 17, 2014 at 9:07 PM, Simon Urbanek <simon.urbanek at r-project.org> wrote: [...] No, the issue is that igraph suggests graph yet fails when it's not present. It should guard against failure is case it's not available. I didn't look at this particular case, but sometimes that is necessary to break infinite dependency loops. So if I make 'graph' a dependency via Imports, then everything will be OK? We can rely on Imports and Depends from BioC being available, but not on Suggests?
The Suggests failure has nothing to do with BioC. Only packages listed in Depends/Imports are required for a package to work so there is no guarantee for any packages in Suggests to be available - hence the package should not break if they are not available - that's the whole point of Suggests. If you list it in Depends/Imports then it won't even get to the check if those packages are not available - it won't build at all. I didn't look at the dependencies in this particular case, but one reason to use Suggests is to break dependency loops: if A depends on B and B on A, then there is no way to install them, so typically A suggests B and B depends on A so that A can be installed and checked first without B and then B checked with A and finally A with B. If A breaks without B then it makes such bootstrapping impossible - we found some packages with this issue, that's why mentioned this - I don't know if that's the case with igraph or not. As for BioC, the builds for BioC are independent of CRAN, so CRAN doesn't build BioC packages and thus their availability is subject to manual intervention - on the OS X build machine there is currently no automated way to track BioC packages, but we're working on it. Cheers, Simon
An embedded and charset-unspecified text was scrubbed... Name: not available URL: <https://stat.ethz.ch/pipermail/r-devel/attachments/20140417/0713d3c3/attachment.pl>
On Apr 17, 2014, at 9:52 PM, G?bor Cs?rdi <csardi.gabor at gmail.com> wrote:
On Thu, Apr 17, 2014 at 9:43 PM, Simon Urbanek <simon.urbanek at r-project.org> wrote: [...] The Suggests failure has nothing to do with BioC. Only packages listed in Depends/Imports are required for a package to work so there is no guarantee for any packages in Suggests to be available - hence the package should not break if they are not available - that's the whole point of Suggests. If you list it in Depends/Imports then it won't even get to the check if those packages are not available - it won't build at all. I didn't look at the dependencies in this particular case, but one reason to use Suggests is to break dependency loops: if A depends on B and B on A, then there is no way to install them, so typically A suggests B and B depends on A so that A can be installed and checked first without B and then B checked with A and finally A with B. I would naively think that if you install A and B _together_, then they should be fine. At least this is how dependencies work on various Linux distributions, AFAIK.
They cannot be installed together, R doesn't have a concept of "together" since it doesn't separate copying and parse/eval stages so you cannot "pre-install" the packages and then run them through R to create the binary. Therefore dependencies are always sequential.
If A breaks without B then it makes such bootstrapping impossible - we found some packages with this issue, that's why mentioned this - I don't know if that's the case with igraph or not. As for BioC, the builds for BioC are independent of CRAN, so CRAN doesn't build BioC packages and thus their availability is subject to manual intervention - on the OS X build machine there is currently no automated way to track BioC packages, but we're working on it. So this effectively means that if I Import/Depend/Suggest etc. a BioC package in igraph, then igraph will likely not be available for OSX. Right?
No. Cheers, Simon
An embedded and charset-unspecified text was scrubbed... Name: not available URL: <https://stat.ethz.ch/pipermail/r-devel/attachments/20140417/fc15e162/attachment.pl>
An embedded and charset-unspecified text was scrubbed... Name: not available URL: <https://stat.ethz.ch/pipermail/r-devel/attachments/20140417/2ae0b036/attachment.pl>
An embedded and charset-unspecified text was scrubbed... Name: not available URL: <https://stat.ethz.ch/pipermail/r-devel/attachments/20140417/228421c0/attachment.pl>
On Apr 17, 2014, at 10:37 PM, G?bor Cs?rdi <csardi.gabor at gmail.com> wrote:
On Thu, Apr 17, 2014 at 10:24 PM, Simon Urbanek <simon.urbanek at r-project.org> wrote: [...]
:) Let's try to make this simple. What can I do to make igraph available for OSX users? I guess this is clear, I can make all examples that load suggested packages optional.
Yes, I think that would be a good idea if you really want to support Suggests. Well, I could not care less about the 1-2 functions that use 'graph', but I want the package to be eventually available on CRAN for OSX. I'll update the examples whenever I can find a free day to check the reverse dependencies....
Thanks. I have verified that graph is now available and igraph seems to pass check with it so it should be available tomorrow. Cheers, Simon
----- Original Message -----
From: "G?bor Cs?rdi" <csardi.gabor at gmail.com> To: "Simon Urbanek" <simon.urbanek at r-project.org> Cc: r-devel at r-project.org Sent: Thursday, April 17, 2014 6:52:33 PM Subject: Re: [Rd] R-3.1.0 OSX Snow Leopard installs old binary On Thu, Apr 17, 2014 at 9:43 PM, Simon Urbanek <simon.urbanek at r-project.org>wrote: [...]
The Suggests failure has nothing to do with BioC. Only packages listed in Depends/Imports are required for a package to work so there is no guarantee for any packages in Suggests to be available - hence the package should not break if they are not available - that's the whole point of Suggests. If you list it in Depends/Imports then it won't even get to the check if those packages are not available - it won't build at all. I didn't look at the dependencies in this particular case, but one reason to use Suggests is to break dependency loops: if A depends on B and B on A, then there is no way to install them, so typically A suggests B and B depends on A so that A can be installed and checked first without B and then B checked with A and finally A with B.
I would naively think that if you install A and B _together_, then they should be fine. At least this is how dependencies work on various Linux distributions, AFAIK.
If A breaks without B then it makes such bootstrapping impossible - we found some packages with this issue, that's why mentioned this - I don't know if that's the case with igraph or not. As for BioC, the builds for BioC are independent of CRAN, so CRAN doesn't build BioC packages and thus their availability is subject to manual intervention - on the OS X build machine there is currently no automated way to track BioC packages, but we're working on it.
So this effectively means that if I Import/Depend/Suggest etc. a BioC package in igraph, then igraph will likely not be available for OSX. Right?
Wrong. It's just the Mavericks binaries that are not yet available. Snow Leopard binaries are available. Dan
Gabor
Cheers, Simon
[[alternative HTML version deleted]]
______________________________________________ R-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel