[
https://issues.apache.org/jira/browse/ARROW-14719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Miles McBain updated ARROW-14719:
---------------------------------
Description:
This is a companion issue to this one I raised for \{renv}:
[https://github.com/rstudio/renv/issues/860]
The use of env vars to control package features at build time as described at
[https://arrow.apache.org/docs/r/articles/install.html|https://arrow.apache.org/docs/r/articles/install.html)]
is not compatible with R's premier package dependency control system: \{renv}.
{renv} caches package builds, which creates a failure mode where the cached
build of \{arrow} on one system does not have the same features as that on
another. The two systems can restore from the same `renv.lock` file and get
package libraries that contain the same versions of \{arrow} with different
capabilities, potentially causing the project to unexpectedly fail an automated
deployment.
This actually happened to my team.
It could be helpful to have LIBARROW_MINIMAL set to false by default, reducing
the chance of this happening. But ultimately any use of env vars driving
capabilities in build creates a risk of version capability mismatches that
{renv} cannot mitigate at present.
There are possibly some clever solutions that could be deployed on both sides.
This issue is just trying to start a conversation.
was:
This is a companion issue to this one I raised for \{renv}:
[https://github.com/rstudio/renv/issues/860]
The use of env vars to control package features at build time as described at
[https://arrow.apache.org/docs/r/articles/install.html|https://arrow.apache.org/docs/r/articles/install.html)]
is not compatible with R's premier package dependency control system: \{renv}.
{renv} caches package builds, which creates a failure mode where the cached
build of \{arrow} on one system does not have the same features as that on
another. The two systems can restore from the same `renv.lock` file and get
package libraries that contain the same versions of \{arrow} with different
capabilities, potentially causing the project to unexpectedly fail an automated
deployment.
This actually happened to my team.
It could be helpful to have LIBARROW_MINIMAL, set to false by default,
reducing the chance of this happening. But ultimately any use of env vars
driving capabilities in build creates a risk of version capability mismatches
that {renv} cannot mitigate at present.
There are possibly some clever solutions that could be deployed on both sides.
This issue is just trying to start a conversation.
> [R] Environment variables controlling package build makes locking down
> package version difficult/impossible
> -----------------------------------------------------------------------------------------------------------
>
> Key: ARROW-14719
> URL: https://issues.apache.org/jira/browse/ARROW-14719
> Project: Apache Arrow
> Issue Type: Improvement
> Components: R
> Affects Versions: 6.0.0
> Environment: Linux
> Reporter: Miles McBain
> Priority: Major
>
> This is a companion issue to this one I raised for \{renv}:
> [https://github.com/rstudio/renv/issues/860]
>
> The use of env vars to control package features at build time as described at
> [https://arrow.apache.org/docs/r/articles/install.html|https://arrow.apache.org/docs/r/articles/install.html)]
> is not compatible with R's premier package dependency control system:
> \{renv}.
>
> {renv} caches package builds, which creates a failure mode where the cached
> build of \{arrow} on one system does not have the same features as that on
> another. The two systems can restore from the same `renv.lock` file and get
> package libraries that contain the same versions of \{arrow} with different
> capabilities, potentially causing the project to unexpectedly fail an
> automated deployment.
> This actually happened to my team.
> It could be helpful to have LIBARROW_MINIMAL set to false by default,
> reducing the chance of this happening. But ultimately any use of env vars
> driving capabilities in build creates a risk of version capability mismatches
> that {renv} cannot mitigate at present.
> There are possibly some clever solutions that could be deployed on both
> sides. This issue is just trying to start a conversation.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
