Skip to content

refactor: implement the new bzlmod api#183

Open
thesayyn wants to merge 22 commits intomainfrom
new_api
Open

refactor: implement the new bzlmod api#183
thesayyn wants to merge 22 commits intomainfrom
new_api

Conversation

@thesayyn
Copy link
Contributor

@thesayyn thesayyn commented Sep 5, 2025

Fixes #123 #56 #66 #124

@baxelrod-bdai
Copy link

I'd find this feature very useful. I hope it gets merged soon!

@thesayyn
Copy link
Contributor Author

thesayyn commented Oct 1, 2025

Still working on this, there will be some breaking changes but this will eventually land./

@gfrankliu
Copy link
Contributor

Hope this supports "postinst" script, or at least provides a hook for people to manually add a few commands from "postinst".

@loosebazooka
Copy link
Contributor

Hope this supports "postinst" script, or at least provides a hook for people to manually add a few commands from "postinst".

@gfrankliu post int is just too hard to support as you must execute it within the context of a container. You're better off doing that with a dockerfile or something.

@gfrankliu
Copy link
Contributor

Hope this supports "postinst" script, or at least provides a hook for people to manually add a few commands from "postinst".

@gfrankliu post int is just too hard to support as you must execute it within the context of a container. You're better off doing that with a dockerfile or something.

That's why I was suggesting providing a "hook" so that people can run the equivalent postint script. Users can read/understand the package provided postinst and write a compatible/equivalent script that can run using the "hook".

Some packages, like `krb5-multidev`, include several .so files to link
against in their pkg-config files:
```
prefix=/usr
exec_prefix=${prefix}
libdir=${prefix}/lib/x86_64-linux-gnu/mit-krb5
includedir=${prefix}/include/mit-krb5

defccname=FILE:/tmp/krb5cc_%{uid}
defktname=FILE:/etc/krb5.keytab
defcktname=FILE:/etc/krb5/user/%{euid}/client.keytab

Name: mit-krb5
Description: An implementation of Kerberos network authentication
Version: 1.20.1
Cflags: -isystem ${includedir}
Libs: -L${libdir} -lkrb5 -lk5crypto -lcom_err
Libs.private: -lkrb5support
```

So, instead of assuming that we have one cc_library per pkgconfig file,
we just collect all the declarations and create one `cc_import` target
for each.

Some design considerations:

### Does this violate the private-ness of `Libs.private`?

All `cc_imports` we create have private visibility already, so I don't
think it does.

### Why not depend on other debian packages exporting those libraries?

Since those files are already in the package
(https://packages.debian.org/sid/amd64/krb5-multidev/filelist), I assume
the intention is to link against the `.so` files distributed in the
`krb-multidev` package, and not to pull other deb packages. This could
be false, of course, if a user has already installed those packages and
for some reason the linker finds their SO files first, but I think
that's a bug in the definition of the krb5-multidev package, not this
implementation.

Plus, it has the added benefit that, if the debian package in question
doesn't include an appropriate .so file, we just don't create the
cc_import.
We should probably rebase and merge this one, instead of squashing.
@aspect-workflows
Copy link

aspect-workflows bot commented Mar 10, 2026

Test

⚠️ Buildkite build #58 failed.

//apt:extensions.doc_extract failed to build

in deps attribute of starlark_doc_extract rule //apt:extensions.doc_extract: missing bzl_library targets for
Starlark module(s) @bazel_lib//lib:strings.bzl, //apt/private:pkgconfig.bzl. Since this rule was created by
the macro 'bzl_library', the error might have been caused by the macro implementation

💡 To reproduce the build failures, run

bazel build //apt:extensions.doc_extract

Test

e2e/smoke

⚠️ Buildkite build #58 failed.


Buildifier

Buildifier managed files require formatting

--- ./apt/private/deb_export.bzl	2026-03-14 00:36:22.587392294 +0000
+++ /tmp/buildifier-tmp-3006932366	2026-03-14 00:36:39.821567963 +0000
@@ -8,19 +8,19 @@
     bsdtar = ctx.toolchains[TAR_TOOLCHAIN_TYPE]
 
     foreign_symlinks = {
-      symlink: json.decode(indices_json)
-      for (symlink, indices_json) in ctx.attr.foreign_symlinks.items()
+        symlink: json.decode(indices_json)
+        for (symlink, indices_json) in ctx.attr.foreign_symlinks.items()
     }
 
     # foreign_symlinks maps label -> index string (reversed for Bazel 7.0.0 compatibility)
     for (target, indices_json) in ctx.attr.foreign_symlinks.items():
         indices = json.decode(indices_json)
         for i in indices:
-          ctx.actions.symlink(
-              output = ctx.outputs.symlink_outs[i],
-              # grossly inefficient
-              target_file = target[DefaultInfo].files.to_list()[0],
-          )
+            ctx.actions.symlink(
+                output = ctx.outputs.symlink_outs[i],
+                # grossly inefficient
+                target_file = target[DefaultInfo].files.to_list()[0],
+            )
 
     if len(ctx.outputs.outs):
         fout = ctx.outputs.outs[0]
--- ./apt/private/version_constraint.bzl	2026-03-14 00:36:22.587949035 +0000
+++ /tmp/buildifier-tmp-845690216	2026-03-14 00:36:39.850567321 +0000
@@ -77,7 +77,6 @@
     v_requested_op = v_requested[0]
     return _version_relop(v_provided[1], v_requested[1], v_requested_op)
 
-
 version_constraint = struct(
     relop = _version_relop,
     is_satisfied_by = _is_satisfied_by,
--- ./distroless/toolchains.bzl	2026-03-14 00:36:21.364631053 +0000
+++ /tmp/buildifier-tmp-2576965125	2026-03-14 00:36:39.915565884 +0000
@@ -1,6 +1,6 @@
 "macro for registering toolchains required"
 
-load("@bazel_lib//lib:repositories.bzl", "register_expand_template_toolchains", "register_tar_toolchains", "register_yq_toolchains", "register_zstd_toolchains", "register_coreutils_toolchains")
+load("@bazel_lib//lib:rep

... 758 chars truncated

💡 Run the following to apply the suggested formatting fixes

bazel run //:buildifier

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

FR: An alternative API design for easier apt.install

6 participants