Dependencies for Binaries on Linux -- Package Manager Install Script Rule #17099
Labels
team-ExternalDeps
External dependency handling, remote repositiories, WORKSPACE file.
type: feature request
untriaged
Description of the feature request:
Hey wonderful Bazelers,
TL;DR: Allowing dependencies into the APT/pacman/etc. dependency graph; WDYT?
In more detail:
On some of the Bazel tools I maintain, folks have been bringing up the topic of linking to libraries that, if not system installed, are
apt-get
able. Bundling everything works great for distribution on platforms where the system doesn't provide a dependency manager, like Apple's and ~Android, where you usually want to ship software that depends only on the system. But for platforms with great built-in dependency management (e.g. Python, Maven, Linux), it can make more sense to just point to your dependencies if there's a way of adding them the the build graph and making sure they're installed by users, especially if they're widely used and likely shared by lots of programs.We've already got something like this for Python with pip_parse/install. For the JVM, we've got maven_install. But it seems like these users would benefit from something similar for apt/pacman/etc. Ideally, I think, it'd manage installing packages across distros, manage deploy vs dev versions, make sure you explicitly list system-installed dependencies in the Bazel build graph, and be aspect-queryable enough to generate dependency lists/scripts that could be used by the existing bundling rules and to generate dependency install scripts for shipping portable software on linux that plays nice with the package management ecosystem.I'm not (currently) a heavy Linux user, but it strikes me that there's a clean pattern emerging here: use the Bazel graph to develop first party code and dependencies you need to build, but, for platforms with high-quality, built-in package managers, allow depending on those dependency graphs, too, bundling (or not) as makes sense for that platform's distribution mechanism. (Also, it kinda feels like Google must have solved this internally, given all the gLinux/goobuntu usage. Maybe there's something externalizable there beyond the docker install rules? Or if there's already something I've missed with all my searching, then yikes, my bad, sorry, but I'd appreciate the pointer and your patience.)
What do you all think?
Thanks for all you do,
Chris
(ex-Googler)
The text was updated successfully, but these errors were encountered: