I don't think I made it clear in my original email, but I don't wish to propose a new direction; rather, I want to understand the direction we are currently heading.
As we've added vcpkg and conan support, is the intention we would replace our bespoke dependency management system? Or take on maintenance of both? I just want to make sure that if we work on a ticket like ARROW-17295 [1] that we aren't adding a system we don't intend to maintain in the long term. [1] https://issues.apache.org/jira/browse/ARROW-17295 On Fri, Aug 5, 2022 at 2:26 PM Wes McKinney <[email protected]> wrote: > The current libarrow_bundled_dependencies.a was created to address the > problem of libarrow.a being "useless" (unable to be used to link with > application code) if any dependencies were built by the Arrow build > system (notably: this the case when using the default allocator > jemalloc). I'm not sure who would be harmed by forcing use of conan or > vcpkg to manage bundled dependencies (rather than having Arrow build > them), but it would be good to have a clearer picture of what that > might look like in the "before and after". > > On Thu, Aug 4, 2022 at 2:45 AM Antoine Pitrou <[email protected]> wrote: > > > > > > I would welcome trimming down our hand-written dependency bundling and > > delegate most of the work to vcpkg or conan, but I don't know how usable > > and flexible those alternatives are. Somehow more knowledgeable > > (probably Kou or perhaps Krisztian?) should answer. > > > > (also note that using an external package manager can restrict our > > freedom in pinning a particular version of a dependency, though that's > > perhaps not a problem with most of them) > > > > Regards > > > > Antoine. > > > > > > Le 03/08/2022 à 19:57, Will Jones a écrit : > > > I was creating this ticket ARROW-17295 [1], but ended up unsure if > this is > > > something we'd like to maintain, so I thought I would bring it up for > > > discussion. Essentially: should we expand the capabilities of our > bundled > > > dependency system? Or should we constrain the scope and point users > that > > > wish for more functionality toward package managers such as vcpkg and > Conan? > > > > > > My understanding is that our bundled dependency system was created to > fill > > > the gaps where package managers failed to provide working builds or a > > > recent enough version of a package. More recently, we added support for > > > vcpkg and have started to use that in many of our CI and packaging > builds > > > [2]. And in the past few months, we have worked on adding support for > Conan > > > [3]. > > > > > > So my question is what is the future of Arrow C++'s bundled dependency > > > system? Do we want: > > > (a) To expand its functionality and encourage use by downstream > projects > > > (b) Keep as is, and consider it primarily for internal use > > > (c) Move away from it in favor of using vcpkg or conan > > > > > > [1] https://issues.apache.org/jira/browse/ARROW-17295 > > > [2] > > > > https://github.com/apache/arrow/blob/master/dev/tasks/python-wheels/github.osx.amd64.yml > > > [3] https://issues.apache.org/jira/browse/ARROW-16089 > > > >
