[CI] Add README for raydepsets dependency lock file management tool

[elliot-barn]

Adding read me for raydepsets

[gemini-code-assist]

Code Review

This pull request introduces a comprehensive README file for the raydepsets tool. The README is well-structured and covers the tool's purpose, usage, configuration, and internal workings. My review focuses on improving the clarity and precision of the documentation to ensure it's as helpful as possible for users. I've suggested a few minor text changes to clarify the behavior of some CLI options, the subset operation, and to make an example more illustrative. I also pointed out a potential point of confusion regarding a CUDA version string.

[gemini-code-assist]

The README mentions CUDA 12.8, but the configuration files (e.g., rayimg.depsets.yaml) use cu128 in PyTorch index URLs. This can be confusing as PyTorch's official naming scheme for CUDA 12.1 is cu121. To improve clarity and avoid potential confusion for users trying to understand or extend the configurations, please clarify if cu128 is a typo, a custom identifier, or if it indeed corresponds to CUDA 12.8. If it's a custom identifier, a brief note might be helpful.

[gemini-code-assist]

The description for CONFIG_PATH states it's a "Path to a .depsets.yaml config file". This is slightly misleading as the tool actually processes all .depsets.yaml files in the directory of the provided path. To make this clearer for users, I suggest updating the description to better reflect this behavior.

Suggested change

	| `CONFIG_PATH` | Path to a `.depsets.yaml` config file (default: `ci/raydepsets/configs/*.depsets.yaml`) |
	| `CONFIG_PATH` | Path to a config file. All `.depsets.yaml` files in the path's directory will be loaded. (default: `ci/raydepsets/configs/*.depsets.yaml`) |

[gemini-code-assist]

The description for --all-configs is "Build depsets from all config files, not just the specified one". This could be clearer about which "all config files" it refers to. Based on the implementation, it builds depsets from all config files found in the same directory as the CONFIG_PATH argument. I suggest clarifying this to avoid ambiguity.

Suggested change

	| `--all-configs` | Build depsets from all config files, not just the specified one |
	| `--all-configs` | Build depsets from all config files in the `CONFIG_PATH` directory, not just the one specified in the path. |

[gemini-code-assist]

The description for the subset operation says it "Validates that all requested requirements exist in the source." This is slightly ambiguous and could be interpreted as checking for individual packages. The implementation actually verifies that the specified requirement files are part of the source depset's definition. To improve clarity, I suggest making this explicit.

Suggested change

	Extracts a subset of already-resolved dependencies from another depset's lock file. Validates that all requested requirements exist in the source.
	Extracts a subset of already-resolved dependencies from another depset's lock file. Validates that all requested requirement files exist in the source depset's definition.

[gemini-code-assist]

The example for YAML anchors is helpful. To better illustrate the benefit of using anchors for keeping definitions DRY, consider showing two depsets that reuse the common settings. This would make the advantage of using anchors more apparent.

Suggested change

	depsets:
	- name: my_depset
	<<: *common_settings
	operation: compile
	requirements:
	- requirements.txt
	output: output.lock
	depsets:
	- name: my_depset_1
	<<: *common_settings
	operation: compile
	requirements:
	- requirements1.txt
	output: output1.lock
	- name: my_depset_2
	<<: *common_settings
	operation: compile
	requirements:
	- requirements2.txt
	output: output2.lock