@tetromino do you have any recommendations for such scenarios (before we move bzl_library into bazel_tools, anyhow)? Should we expose the .bzl files in a filegroup (in this case even including a generated .bzl file from another repo), or I guess let the users create filegroups themselves?

IMHO the right solution would be to define a bzl_library target (let's say @host_platform//:constraints_lib) with the new constraints.bzl file in srcs.

And if any other .bzl file in platforms is loading @host_platform//:constraints.bzl, then that file's corresponding bzl_library target needs to depend on @host_platform//:constraints_lib

That's the ideal solution, but we didn't want to use bzl_library before it's moved out of bazel_skylib.

Chatted to @tetromino offline; using a filegroup for now is the the only choice we have, really.

@aignas could you create a separate filegroup target called bzl_srcs that only includes these .bzl files, and use that instead?

I decided to not use this in rules_python yet, so this has dropped in my priority queue. If somebody is blocked by this, feel free to create a new PR and close this one.

With skylib 1.6.0, bzl_library can now depend on filegroup targets. I've sent #90 to add the appropriate filegroup targets for the new .bzl files, which should unblock downstream users of Stardoc.

When bzl_library gets moved to bazel_tools, these targets can simply be converted into bzl_library targets backwards-compatibly.