Skip to content
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

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

Closed
cpsauer opened this issue Dec 31, 2022 · 2 comments
Closed
Labels
team-ExternalDeps External dependency handling, remote repositiories, WORKSPACE file. type: feature request untriaged

Comments

@cpsauer
Copy link
Contributor

cpsauer commented Dec 31, 2022

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)

@sgowroji sgowroji added team-ExternalDeps External dependency handling, remote repositiories, WORKSPACE file. untriaged type: feature request labels Jan 1, 2023
@Wyverald
Copy link
Member

This sounds like a rather huge undertaking. Making it work across all distros also sounds like a pipe dream to me. This might be better as a discussion topic on bazel-dev@googlegroups.com instead of as an issue here; please feel free to send a more detailed proposal once it's ready.

Also, it kinda feels like Google must have solved this internally, given all the gLinux/goobuntu usage.

Google doesn't really use system libraries -- everything is in the monorepo and statically linked.

@Wyverald Wyverald closed this as not planned Won't fix, can't repro, duplicate, stale Jan 17, 2023
@cpsauer
Copy link
Contributor Author

cpsauer commented Jan 18, 2023

Oh, okay. Bummer. Sad to see it go down so fast, since I think there's a real, general need here, if not currently mine nor Google's.

I think, instead, if we ever become heavy linux-dev users, we'll just build it--or help others do so if we keep hearing clamors for it. I think there's a useful core that'd be fairly easy to spin up, proceeding incrementally from there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
team-ExternalDeps External dependency handling, remote repositiories, WORKSPACE file. type: feature request untriaged
Projects
None yet
Development

No branches or pull requests

3 participants