Skip to content

Dependencies for Binaries on Linux -- Package Manager Install Script Rule #17099

Closed as not planned
@cpsauer

Description

@cpsauer

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-getable. 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)

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions