Python: upgrade clap

[redsun82]

This allows to get rid of the now unmaintained atty dependency (see https://github.com/github/codeql/security/dependabot/343).

This required some code changes because of some breaking changes in clap.

Also needed to assign a new bazel repo name to the crates_vendor to avoid name conflicts in MODULE.bazel.

PR Overview

This PR updates the label regex and its corresponding substitution to accommodate breaking changes in dependencies and to assign a new Bazel repository name for crates_vendor.

• Updated the regex in patch_defs.py to capture a broader vendor pattern.
• Modified the lambda replacement to align with the new capture group order.

Changes

File	Description
misc/bazel/3rdparty/patch_defs.py	Updated regex and label substitution to support new repository naming conventions and dependency upgrades

Copilot reviewed 71 out of 71 changed files in this pull request and generated no comments.

Comments suppressed due to low confidence (2)

misc/bazel/3rdparty/patch_defs.py:5

• The use of '.*' in the vendor capture group may be too permissive and could capture unintended characters; consider refining the regex to only match the expected vendor format.

label_re = re.compile(r'"@(vendor.*)//:(.+)-([\d.]+)"')

misc/bazel/3rdparty/patch_defs.py:13

• Double-check that the new group indices in the lambda correspond correctly to the intended label parts (repo name, package name, version); ensure that m[1] is the repo and m[2].replace('-', '_') produces the proper target label.

line = label_re.sub(lambda m: f'"@{m[1]}__{m[2]}-{m[3]}//:{m[2].replace("-", "_")}"', line)

Tip: Copilot only keeps its highest confidence comments to reduce noise and keep you focused. Learn more

[redsun82]

Whoops, had forgotten rerunning the bazel vendoring 😅

[yoff]

I may need a (potentially offline) explanation for the repo name change. Otherwise this looks fine.

[yoff]

I am not sure I understand why this is a problem now and not before?

[redsun82]

The short answer is sheer coincidence 😄

The slightly longer answer is: this is what bazel uses to prefix names of external rust dependencies of the python extractor, which then get pulled in in MODULE.bazel. The names are of the form <repository_name>__<crate name>_<version>, but it turns out they need to be disjoint from the dependencies of the other tree-sitter extractors, because then you end up defining something twice in MODULE.bazel (which in hindsight is not that weird).

Until now it just so happened that the versions of the common dependencies in the two lock files were never overlapping, until I had anyhow hit this condition after updating clap.

This does mean there is no sharing of dependencies between the two families of tree-sitter extractor, which does mean potentially rebuilding some of those when building the whole dist. In order to do share those we would need to put everything in the same workspace, and we saw that was causing an increased build cost for building just one of the two (i.e. building python was incurring overhead coming from ruby/rust). It might be that is not the case any more with this vendoring thing and the newer version of rules_rust, we might need to retest that (cc @criemen).

If you wonder why I did not rename the other crates_vendor rule, it's just because I did not want to conflict with #18789. I will probably also rename that there.

[yoff]

If you wonder why I did not rename the other crates_vendor rule, it's just because I did not want to conflict with #18789. I will probably also rename that there.

Yes I did wonder that, thanks for the detailed answer! :-)

[yoff]

LGTM