Adding support for .bzl file operations

[mydatascience]

Buildtools PR checklist

• The code in this PR is covered by unit/integration tests.
• I have tested these changes and provide testing instructions below.
• I have either responded to, or resolved all Gemini comments on the PR.
• I have read Google Eng Practices on Small Changes, this PR either follows these guidelines or the description provides reasoning for why they can not be followed.

Description

This PR extends edit label resolution to allow targeting .bzl files directly (for buildozer-style edits), e.g. //pkg:defs.bzl and //pkg:defs.bzl:rule. This makes it possible to apply edit transformations (like adding/removing entries from list attributes such as patches = [...]) to .bzl files, while still relying on buildifier-compatible formatting.

It also adds unit tests covering:

resolving .bzl targets via InterpretLabelForWorkspaceLocation
editing a patches list in a parsed .bzl file (add + remove) and validating formatted output

(optional) These changes were tested using the following steps

Run unit tests for the edited package:
go test ./edit
(Optional sanity) Run the specific new tests:
go test ./edit -run 'TestInterpretLabelForWorkspaceLocation_BzlFile|TestAddAndRemovePatchesInBzlFile'

[gemini-code-assist]

Code Review

This pull request extends the build tools to support editing .bzl files, enabling buildozer-style transformations on global variables. Key changes include updated label parsing for .bzl targets, improved global variable detection that excludes function-local assignments, and modifications to cmdAdd and cmdRemove. Feedback highlights critical logic errors in the new command handlers where variable-based rule checks were inverted and cmdRemove incorrectly used an addition function. Refactoring was also recommended to eliminate duplicated label parsing logic.

[gemini-code-assist]

The condition env.Rule.Call != nil is incorrect for variable editing. According to the changes in expandTargets (lines 995-996), variable targets are represented by a dummy Rule where the Call field is nil. This check makes the logic for adding values to variables unreachable.

Suggested change

	if env.Rule != nil && env.Rule.Call != nil {
	if env.Rule != nil && env.Rule.Call == nil {

References

1. When modifying code, ensure that changes are consistent with previous behavior, especially if the previous behavior was intentional.

[mydatascience]

/gemini review

[gemini-code-assist]

Code Review

This pull request introduces support for editing global variables in .bzl files via buildozer. It includes updates to label resolution to handle .bzl files and refactors the Kind() method for more robust path extraction. Review feedback points out a risk of panics in existing commands due to the introduction of rules with nil call expressions and identifies limitations in the variable detection logic regarding tuple unpacking and loop variables.

[gemini-code-assist]

This implementation only detects global variables assigned via simple identifiers (e.g., VAR = ...). It will miss variables assigned via tuple unpacking (e.g., (A, B) = ...) or those defined as loop variables in top-level for statements. While this may be acceptable for common use cases, it is a limitation of the current variable detection logic.