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

Add support for .ar and .deb files to repository_ctx #15130

Closed
kjlubick opened this issue Mar 28, 2022 · 5 comments
Closed

Add support for .ar and .deb files to repository_ctx #15130

kjlubick opened this issue Mar 28, 2022 · 5 comments
Assignees
Labels
P2 We'll consider working on this in future. (Assignee optional) team-ExternalDeps External dependency handling, remote repositiories, WORKSPACE file. type: feature request

Comments

@kjlubick
Copy link
Contributor

Description of the problem / feature request:

I intend to add support for .ar archive files and .deb files (which are the same file format).

Feature requests: what underlying problem are you trying to solve with this feature?

download_and_extract supports many compressed or packaged file formats already. Adding .ar and .deb files will make it easier for toolchains to download and extract .deb files into their sysroot without requiring an external tool.

Example hermetic toolchain that downloads .deb files and extracts them.

Have you found anything relevant by searching the web?

Apache Commons Compress already has support for .ar files and this package is already used by Bazel for Compressed Tar files so we shouldn't need any additional third party dependencies.

@aiuto
Copy link
Contributor

aiuto commented Mar 30, 2022

I would like to find a way to do this by making it an external set of repository rules that can have it's own development team. The issue is that most of the core Bazel team never see .deb files. They won't be able to adequately maintain or enhance it. I;m tied up this week and meteorcloudy@ is out on vacation. We can talk next week.

@ckolli5 ckolli5 added team-ExternalDeps External dependency handling, remote repositiories, WORKSPACE file. untriaged labels Mar 30, 2022
@meteorcloudy meteorcloudy added type: feature request P2 We'll consider working on this in future. (Assignee optional) and removed untriaged labels Apr 5, 2022
bazel-io pushed a commit that referenced this issue Apr 5, 2022
This implements #[15130](#15130).

As I was updating the docs for .ar and .deb formats, I also addressed some previous formats that had been added but not propagated through to all the documentation places.

Closes #15132.

PiperOrigin-RevId: 439569440
@aiuto
Copy link
Contributor

aiuto commented Apr 12, 2022

The more I think about it, the more I believe this belongs to a new rule set. That would follow the pattern of jvm_external, where we built new repository rules outside of bazel itself, so they can advance at different rates. Looking at your patch, you will decompress the .deb file, but a fully fleshed out rule could have so much more. For example, installing a package and then making the libraries and headers available as a .so.

Since I have some .deb file experience (on the building them side from rules_pkg), I can offer to help on parts of this, but what you need is a place to host it. Could you create a repository under Skia's control? Then we can point to that as the recommended place for support of .deb install from the workspace.

@meteorcloudy
Copy link
Member

meteorcloudy commented Apr 12, 2022

Hey Tony, this features is already implemented in #15132. I don't think this belong to a new rule, just like we are not extracting .zip, .tar files using a ruleset (this is a totally different process as building archive with rules_pkg). This is an enhancement of the functionality in repository_ctx to decompress an archive, then the repository rule can do anything it wants. This works naturally with http_archive.

I'm closing this since the feature has already been merged.

meteorcloudy pushed a commit to meteorcloudy/bazel that referenced this issue Apr 12, 2022
This implements #[15130](bazelbuild#15130).

As I was updating the docs for .ar and .deb formats, I also addressed some previous formats that had been added but not propagated through to all the documentation places.

Closes bazelbuild#15132.

PiperOrigin-RevId: 439569440
ckolli5 pushed a commit that referenced this issue Apr 20, 2022
This implements #[15130](#15130).

As I was updating the docs for .ar and .deb formats, I also addressed some previous formats that had been added but not propagated through to all the documentation places.

Closes #15132.

PiperOrigin-RevId: 439569440

Co-authored-by: Kevin Lubick <[email protected]>
@uhthomas
Copy link
Contributor

uhthomas commented Jun 23, 2022

.deb files usually contain additional archives which makes actually extracting information from .deb archives with http_archive awkward. The repository will end up with debian_binary, control.tar and data.tar files where data.tar needs to be extracted again in another repository rule, or BUILD rule if you're feeling adventurous. Is there any way for the data.tar to be extracted automatically by http_archive?

@meteorcloudy
Copy link
Member

@uhthomas I think it's possible to write a custom starlark repository rule to keep extracting the *.tar files with the repository_ctx.extract API. Doing this in http_archive is probably not ideal, because how do you decide when to extract further?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P2 We'll consider working on this in future. (Assignee optional) team-ExternalDeps External dependency handling, remote repositiories, WORKSPACE file. type: feature request
Projects
None yet
Development

No branches or pull requests

5 participants