Deprecate ctx.configuration.host_path_separator

[fmeum]

Using this field for its intended purpose is essentially almost incorrect as it is based on the OS of the machine running Bazel, not any execution platform. It can be used to sneakily reason about the local machine in a build rule, but that's discouraged and should be done in a repository rule instead.

[Copilot]

Pull Request Overview

This PR deprecates the use of ctx.configuration.host_path_separator by updating its documentation to discourage its usage and suggest alternative approaches.

• Updates the documentation for host_path_separator to highlight deprecation and provide alternative guidance.
• Clarifies the inherent limitations of using the OS-dependent separator in Bazel build rules.

Comments suppressed due to low confidence (1)

src/main/java/com/google/devtools/build/lib/starlarkbuildapi/BuildConfigurationApi.java:55

• Consider adding the @deprecated annotation to the getHostPathSeparator() method to signal deprecation at the code level.

String getHostPathSeparator();

[meteorcloudy]

Is it possible to offer an easy drop-in replacement for this API based on the execution platform?

It's been used quite widely:
https://sourcegraph.com/search?q=context:global+%22host_path_separator%22+file:.*.bzl&patternType=keyword&sm=0

[katre]

I had a discussion a while back (possibly with @susinmotion ?) about adding a ctx.exec_platform_has_constraint method (especially since this is currently available to native rules but not Starlark).

Would that make this easier to migrate?

[meteorcloudy]

Yeah, I do believe those are used mostly in rule implementations to construct build actions. Just wonder if we can add a helper function somewhere (bazel_skylib) to be a drop-in replacement?

[katre]

Not without support for finding out whether the exec platform uses windows-style separators (which is, basically, ctx.exec_platform_has_constraint).

[meteorcloudy]

Oh, I see, I confused it with ctx.target_platform_has_constraint and thought it's already available. Then, yes, I do think adding ctx.exec_platform_has_constraint is probably desired. @fmeum WDYT?

[fmeum]

ctx.exec_platform_has_constraint doesn't quite cut it since there could be multiple execution platforms in a rule. We could do ctx.exec_groups["my_group"].exec_platform_has_constraint(), but then we would need a convenient way to name the default exec group.