deriving pkg_files.renames from deploy_name=foo tags?

[ghost]

I've ported a handful of projects from Maven to Bazel, and one thing that almost always gets in the way is Bazel's opinion that the output from every java_library has a lib prefix. When it comes time to produce an RPM containing the Bazel-built libraries, I have to add renames = {"//package:label": "label.jar"} entries to all of my pkg_files targets.

With that, what if pkg_files implicitly applied an aspect to its srcs and was able to derive renames from a tag?

Consider a java_library that we want to deploy as /opt/vendor/lib/foo-1.2.3.jar:

pkg_files(
    name = "libs",
    srcs = [":foo"],
    prefix = "/opt/vendor/lib",
)

java_library(
    name = "foo",  # default output name is libfoo.jar
    tags = ["deploy_name=foo-1.2.3.jar"],  # pkg_files will implicitly treat this as renames = {":foo": "foo-1.2.3.jar"}
    ...
)

Handwavy semantics:

• deploy_name replaces the basename of the artifact, so that rules_pkg's prefix, strip_prefix, etc. work as usual.
• If necessary, we can namespace the tag so that it doesn't clash with other usages (e.g.tags = ["rules_pkg.deploy_name=..."]).
• If a target generates multiple artifacts (e.g. java_binary has 2 implicit artifacts, a jar and a launcher), then perhaps we can support mappings where the LHS corresponds to whatever's in DefaultInfo.files:
  • tags = ["deploy_name=codename.jar=publicname.jar;codename=publicname-launcher"]; or
  • tags = ["deploy_name=codename.jar=publicname.jar", "deploy_name=codename=publicname-launcher"]
• pkg_files.renames overrides the names obtained from the aspect and can be used to resolve conflicts.

WDYT?

[aiuto]

I wouldn't want an aspect that was automatically applied. That could be wasteful for everyone who does not have this problem.

But, what if you built new rule which took a list of sources (like pkg_files), applied the aspect to each and generated a mapping. The rpm would depend on that rule.

Of course, the next set of questions will be if it can rename C++ libraries too. And how we will express the semantics of C++ naming for different OS types. tags is not select()-able so you would have to embed the OS distinctions in tag names. pkg_files.renames is, so doing different mappings per OS is more readable there.

[ghost]

Fair points on all counts. (Myopia strikes again!) Thanks for the reply.