https://pantsbuild.org/ logo
#general
Title
# general
b

bitter-ability-32190

12/27/2021, 3:56 PM
(Tangentially related to this discussion about programmatically modifying BUILD files by running Buildifier on them) Follow-up from this discussion about the lowest-bar way to introduce Pants for linting/formatting. 🧵
The top-level
BUILD
file had a few bumps, so I got clever and sliced our repo another way.
Introducing
pants-plugins/bazel-compat-macros.py
Copy code
# Macros for Bazel defintions
def alias(*args, **kwargs): ...
def genrule(*args, **kwargs): ...
def exports_files(*args, **kwargs): ...
def load(*args, **kwargs): ...
def requirement(arg): ...
# ... you get the idea ;)
def glob(*args, **kwargs): return []

# Ones we do care about
def py_library(**kwargs):
    srcs = kwargs.get("srcs", [])
    if srcs:
        return python_sources(name=kwargs["name"], sources=srcs)

def py_test(**kwargs):
    srcs = kwargs.get("srcs", [])
    if srcs:
        return python_sources(name=kwargs["name"], sources=srcs)
Then to do the other side:
Copy code
# In pants-compat.bzl
def python_requirements(**kwargs):
  pass
And finally, the top-level
BUILD
Copy code
load("//:pants-compat.bzl", "python_requirements")

package(default_visibility = ["//visibility:public"])

# Bazel stuff

python_requirements(
    module_mapping = {
        "absl-py": ["absl"],
        # ...
    },
)
Now Pants will pick up on all my files already known to Bazel 🎉
😈
c

curved-television-6568

12/27/2021, 4:06 PM
Haha… that’s awesome! 😄
🙌 1
b

bitter-ability-32190

12/27/2021, 4:08 PM
It works for format, going to try and finagle it for
lint
I'm wondering if Pants should maybe have a "ignore-unrecognized-definitions" option for this use case. 🤔 We'll have to see how it pans out for: • linting (w.r.t. deps) • when we want to incrementally migrate to using
pants
for more than format/linting/checking
@hundreds-father-404 who seems to be my sounding board for crazy ideas 🤓
c

curved-television-6568

12/27/2021, 4:22 PM
maybe have a “ignore-unrecognized-definitions” option
is it too many definitions to “stub” out with macros? or are there other constructs that doesn’t map to a macro syntactically ?
b

bitter-ability-32190

12/27/2021, 4:25 PM
No, and actually now that I think about it, it's likely a bad idea. Take a look at my definition for
glob
For
lint
, it's much more complicated 😂 . Bazel is cool with double-ownership, but Pants not so much
The jist of the issue is that some of our
py_binary
rules are used in
py_test
, but declare
srcs=[...]
for their sources. But there may or may not be a
py_library
which also has the declared
srcs
, leading to ambiguous ownership. The solution is to scrub the `py_binary`s that use an already-owned
py_library
to use the
:foo/bar
syntax instead of declaring ownership
I think I'm going to make Bazel error if
py_binary
contains an actual src in
srcs
, and then
py_binary
is empty to Pants
Copy code
def py_binary(
    srcs = [],
    **kwargs
):
    for src in srcs:
        if src.endswith(".py"):
            # This is valid Bazel, but for Pants-compat to work, each src should be owned
            # once-and-only-once. And the easiest way to do that is throught `py_library`.
            fail(
                "`py_binary` cannot claim a Python src. Use `py_library` instead and depend on it.\n\n"
                + "E.g. declare:\n\n"
                + "py_library(\n"
                + '  name = "{}",\n'.format(src[:-3])
                + '  srcs = ["{}"],\n'.format(src)
                + ")\n\n"
                + 'Then set the `py_binary` `srcs` attribute to ":{}"'.format(src[:-3])
            )
    _py_binary(
        srcs=srcs,
        **kwargs,
    )