1.5.0-rc3 fails when parsing local identifiers starting with digits followed by non digits

[philsc]

🐞 bug report

Affected Rule

The issue is caused by the rule: py_library. Bazel errors out pretty early in the build process.

Error in fail: Failed to parse PEP 440 version identifier '0.1.0+brt.9e26ab0fd97503827d5b406699d5290c29c430c5'. Parse error at 'e26ab0fd97503827d5b406699d5290c29c430c5'

Is this a regression?

The 1.3.0 version we're currently using does not throw this error.

Description

We have a custom version of the lerobot package with identifier 0.1.0+brt.9e26ab0fd97503827d5b406699d5290c29c430c5.

AFAICT this should be fine under PEP 440:

Local version identifiers MUST comply with the following scheme:
<public version identifier>[+<local version label>]

where

local version labels MUST be limited to the following set of permitted characters:

• ASCII letters ([a-zA-Z])
• ASCII digits ([0-9])
• periods (.)

It looks to me like we are following that.

🔬 Minimal Reproduction

I don't have a public wheel with a local identifier to show you, unfortunately.

🔥 Exception or Error

ERROR: /var/lib/buildkite-agent/builds/shasta-ci-blue-i-05dc558a48121b7cf-1/blue-river-technology/k8_output_base/external/my_deps_3_10_lerobot/BUILD.bazel:5:20: in py_library rule @@my_deps_3_10_lerobot//:pkg:
[2025-06-25T21:43:20Z] Traceback (most recent call last):
[2025-06-25T21:43:20Z] 	File "/var/lib/buildkite-agent/builds/shasta-ci-blue-i-05dc558a48121b7cf-1/blue-river-technology/k8_output_base/external/rules_python/python/private/py_library.bzl", line 114, column 27, in _py_library_impl_with_semantics
[2025-06-25T21:43:20Z] 		return py_library_impl(
[2025-06-25T21:43:20Z] 	File "/var/lib/buildkite-agent/builds/shasta-ci-blue-i-05dc558a48121b7cf-1/blue-river-technology/k8_output_base/external/rules_python/python/private/py_library.bzl", line 164, column 52, in py_library_impl
[2025-06-25T21:43:20Z] 		package, version_str = _get_package_and_version(ctx)
[2025-06-25T21:43:20Z] 	File "/var/lib/buildkite-agent/builds/shasta-ci-blue-i-05dc558a48121b7cf-1/blue-river-technology/k8_output_base/external/rules_python/python/private/py_library.bzl", line 241, column 26, in _get_package_and_version
[2025-06-25T21:43:20Z] 		version.normalize(version_str),  # will have no dashes either
[2025-06-25T21:43:20Z] 	File "/var/lib/buildkite-agent/builds/shasta-ci-blue-i-05dc558a48121b7cf-1/blue-river-technology/k8_output_base/external/rules_python/python/private/version.bzl", line 511, column 18, in normalize_pep440
[2025-06-25T21:43:20Z] 		return _parse(version, strict = True)["norm"]
[2025-06-25T21:43:20Z] 	File "/var/lib/buildkite-agent/builds/shasta-ci-blue-i-05dc558a48121b7cf-1/blue-river-technology/k8_output_base/external/rules_python/python/private/version.bzl", line 548, column 18, in _parse
[2025-06-25T21:43:20Z] 		_fail(
[2025-06-25T21:43:20Z] Error in fail: Failed to parse PEP 440 version identifier '0.1.0+brt.9e26ab0fd97503827d5b406699d5290c29c430c5'. Parse error at 'e26ab0fd97503827d5b406699d5290c29c430c5'

🌍 Your Environment

Operating System:

  
Ubuntu 22.04
  

Output of bazel version:

  
$ bazel version
Bazelisk version: development
Build label: 7.2.0
Build target: @@//src/main/java/com/google/devtools/build/lib/bazel:BazelServer
Build time: Mon Jun 10 13:04:32 2024 (1718024672)
Build timestamp: 1718024672
Build timestamp as int: 1718024672
  

Rules_python version:

  
1.5.0-rc3
  

Anything else relevant?

Not that I can think of.

[rickeylev]

I'm not sure what the parser bug is, I think an easy fix for now is to move that get_package_and_version() call inside get_imports_and_venv_symlinks. That code path is only relevent when the experimental site-packages support is enabled. Skipping it should avoid it.

Integration testing this without a wheel with a local version identifier will probably be hard.

I sent out #3031 -- are you able to patch that in and see if it works?

[rickeylev]

repro: #3032

Poking it a bit, it seems to not like a digit followed by non-digit.

• brt.9e fail
• brt.v9e ok
• brt.99 ok

[aignas]

Just to note that in general the version handling of the local specifier may be wrong when comparing versions. I think in the current implementation this is not implemented properly:

Comparison and ordering of local versions considers each segment of the local version (divided by a .) separately. If a segment consists entirely of ASCII digits then that section should be considered an integer for comparison purposes and if a segment contains any ASCII letters then that segment is compared lexicographically with case insensitivity. When comparing a numeric and lexicographic segment, the numeric section always compares as greater than the lexicographic segment. Additionally a local version with a great number of segments will always compare as greater than a local version with fewer segments, as long as the shorter local version’s segments match the beginning of the longer local version’s segments exactly.

However, this bug is not strictly talking about comparing local versions.

[philsc]

I can confirm that aab2650 fixes that error, thank you!

I'm submitting it into our CI build to see if I can find anything else.