feat: Enable header generation

[honnix]

Use --custom-compile-command together with label to enable header generation.

This will help users understand what bazel command to run in order to regenerate.

[honnix]

This is a bug fix.

[mark-thm]

yep, fair, we played a little fast-and-loose with the quoting here.

[mark-thm]

mind updating line 38 with the command to run to fix the problem?

[honnix]

Sure let me try to understand why it failed. Will come to this shortly.

[mark-thm]

You can safely ignore the reviewbot/autosquash failures -- our automation doesn't work well with contributions from forks and we're apparently still not suppressing the runs well enough.

There is a legit CI failure in there, though.

[honnix]

You can safely ignore the reviewbot/autosquash failures -- our automation doesn't work well with contributions from forks and we're apparently still not suppressing the runs well enough.

There is a legit CI failure in there, though.

Hmm, this is a bit tricky:

-#    bazel run @@//:generate_requirements_linux_txt
+#    bazel run @@//:generate_requirements_linux_txt_diff_test

They are different because the labels are different.

[honnix]

It's not ideal, but 7c1a469 should fix the tests.

[honnix]

Alternatively we could do

diff --git a/uv/private/pip.bzl b/uv/private/pip.bzl
index 9699fd7..00797df 100644
--- a/uv/private/pip.bzl
+++ b/uv/private/pip.bzl
@@ -1,6 +1,7 @@
 "uv based pip compile rules"

 _PY_TOOLCHAIN = "@bazel_tools//tools/python:toolchain_type"
+_DIFF_TEST_SUFFIX = "_diff_test"

 _common_attrs = {
     "requirements_in": attr.label(mandatory = True, allow_single_file = True),
@@ -25,7 +26,7 @@ def _uv_pip_compile(ctx, template, executable):
             "{{requirements_txt}}": ctx.file.requirements_txt.short_path,
             "{{resolved_python}}": py_toolchain.py3_runtime.interpreter.short_path,
             "{{python_platform}}": _python_platform(ctx.attr.python_platform),
-            "{{label}}": str(ctx.label),
+            "{{label}}": str(ctx.label).removesuffix(_DIFF_TEST_SUFFIX),
         },
     )

@@ -84,7 +85,7 @@ def pip_compile(name, requirements_in = None, requirements_txt = None, target_co
     )

     _pip_compile_test(
-        name = name + "_diff_test",
+        name = name + _DIFF_TEST_SUFFIX,
         requirements_in = requirements_in or "//:requirements.in",
         requirements_txt = requirements_txt or "//:requirements.txt",
         python_platform = python_platform or "",

The benefit is we keep the suffix manipulation in the same file, but being completely paranoid, this could accidentally remove _diff_test from a user provided label name.

[mark-thm]

thought's on passing an explicit value for this in the macro instead of doing the substitution of the _diff_test suffix in bash?

[honnix]

Isn't that the alternative I shared above? Or do you refer to something else?

[mark-thm]

I meant something a little different -- we can take an explicit attr that is the label to use for re-generating the files and set it correctly in both the compile and test targets rather than performing replacements on the name.

[honnix]

I'm not sure I fully understand that. Do you want user to set that attr?

[honnix]

Do you mean something like this:

diff --git a/uv/private/pip.bzl b/uv/private/pip.bzl
index 9699fd7..d00e21f 100644
--- a/uv/private/pip.bzl
+++ b/uv/private/pip.bzl
@@ -3,6 +3,7 @@
 _PY_TOOLCHAIN = "@bazel_tools//tools/python:toolchain_type"

 _common_attrs = {
+    "original_name": attr.string(mandatory = True),
     "requirements_in": attr.label(mandatory = True, allow_single_file = True),
     "requirements_txt": attr.label(mandatory = True, allow_single_file = True),
     "python_platform": attr.string(default = ""),
@@ -25,7 +26,7 @@ def _uv_pip_compile(ctx, template, executable):
             "{{requirements_txt}}": ctx.file.requirements_txt.short_path,
             "{{resolved_python}}": py_toolchain.py3_runtime.interpreter.short_path,
             "{{python_platform}}": _python_platform(ctx.attr.python_platform),
-            "{{label}}": str(ctx.label),
+            "{{label}}": str(ctx.label.relative(ctx.attr.original_name))  # this is a deprecated api in 7.1+
         },
     )

@@ -77,6 +78,7 @@ def pip_compile(name, requirements_in = None, requirements_txt = None, target_co

     _pip_compile(
         name = name,
+        original_name = name,
         requirements_in = requirements_in or "//:requirements.in",
         requirements_txt = requirements_txt or "//:requirements.txt",
         python_platform = python_platform or "",
@@ -85,6 +87,7 @@ def pip_compile(name, requirements_in = None, requirements_txt = None, target_co

     _pip_compile_test(
         name = name + "_diff_test",
+        original_name = name,
         requirements_in = requirements_in or "//:requirements.in",
         requirements_txt = requirements_txt or "//:requirements.txt",
         python_platform = python_platform or "",

[honnix]

Maybe it is better as:

            "{{label}}": "@@%s//%s:%s" % (
                ctx.label.workspace_name,
                ctx.label.package,
                ctx.attr.original_name,
            ),

There is a new API Label.same_package_label but not available in 7.0.

[honnix]

I'm not sure this approach is simpler but I could have misunderstood. Please feel free to update this PR.

[mark-thm]

I mean something like the original_name example, but see the tradeoffs you highlight with flux around label functionality and am happy to take your contribution as is. Thanks for exploring.

[honnix]

Thank you!