-
Notifications
You must be signed in to change notification settings - Fork 64
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make arrow
dependency optional
#537
Comments
I would be curious if you have any specific examples of issues you've experienced on RHEL 7 (especially recently). We run CentOS 7 (without any additional devtools installation [1]) as part of our CI process on every commit/PR in Arrow and expect that installing Arrow should just work [2]. If it doesn't, we would very very much love to hear about it and help resolve that (feel free to open a jira, or I'm happy to have logs emailed to me if there's need for privacy). Here's a recent run of that on our CI: https://github.com/apache/arrow/runs/3997101335?check_suite_focus=true [1] – We also test with devtools installed to make sure that upgrading gcc also works. Here's a recent build of that nightly CI job: https://dev.azure.com/ursacomputing/crossbow/_build/results?buildId=14451&view=results |
Ok, I'm going to leave this as is then. @colearendt please let me know if you encounter any customers that this affects. |
IIRC this was a customer that generated this issue. I can find out who if that would be helpful. They were having trouble with Apologies for missing the message @jonkeane - I'll see if I can dig up any of this old info |
Updated slack thread with info from the customer. They installed
|
Aaah, we've seen this before, There are a bunch of factors that contribute to how much RAM is needed during compilation (which features are being compiled, which dependencies need to be compiled, how much parallelism is enabled). However, we've found the biggest culprit of memory in our build process was building with unity enabled (which is exactly where this failed), so we've disabled that by default (starting with the 7.0.0 release) to reduce that chances of people running into this. Unity is supposed to speed up compilation at the expense of requiring more RAM, but in cases like docker containers with relatively limited memory, that ends up in situations like this. We are also working on adding ram requirements to our docs: apache/arrow#11205 to make this a bit clearer. Hopefully these two together will resolve most cases of this, and when it doesn't there's clearer guidance of minimums. |
I'm seeing very long build times (60mins+) when trying to install arrow for the pins library within a Docker container via install.packages() on my CI, Cloud Buiild. Is there any advice on how to speed it up aside booting a bigger machine, perhaps using a different FROM to build within? I've looked at the apache-dev/arrow images but it seems some work to install R, tidyverse etc on top. I'm looking for an image that has arrow/pins ideally. |
The quickest and easiest way to install Arrow is to do one of the following:
There's more information in our documentation. I've linked to our nightly docs because we've recently improved them and they are quite a bit clearer about this — we're in the process of releasing right now so those will be on the main page soon enough! There are a (relatively broad!) set of OSes that RSPM/we support — if you're finding that the image you're using isn't supported, please let us know and we'll see what we can do. One final note about the |
Great thanks will take a look. For some reason the RStudio binaries weren't being used even though I remember since R 4.0 rocker images did default to that, but will look at those options. In general having an R arrow Docker available will be nice to have. |
This issue has been automatically locked. If you believe you have found a related problem, please file a new issue (with a reprex: https://reprex.tidyverse.org) and link to this issue. |
RHEL 7 systems (which are used often by our customers) do not have a new enough
gcc
to compilec++11
code. This creates a problem with installing thearrow
package, and workarounds often (1) involve IT or (2) are disallowed by policy.As a result, making the
arrow
dependency optional would be beneficial for customers.The text was updated successfully, but these errors were encountered: