ouster-sdk python package raises InvalidVersion error with upcoming version of pip

[kgreenek]

PEP 440 defines a standard for the versions used in pip packages: https://peps.python.org/pep-0440/

This has been a standard since 2013, but not enforced due to compatibility concerns.

However, recently they have decided to start enforcing this standard. New versions of pip raise an InvalidVersion exception when trying to install ouster-sdk packages from pip, similar to the following:

(Traceback (most recent call last):
  File "/home/greg/.cache/bazel/_bazel_greg/b0c20c8ca453cbc6e375a5451bd4af5d/external/rules_ros2_python_x86_64-unknown-linux-gnu/lib/python3.10/runpy.py", line 196, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/home/greg/.cache/bazel/_bazel_greg/b0c20c8ca453cbc6e375a5451bd4af5d/external/rules_ros2_python_x86_64-unknown-linux-gnu/lib/python3.10/runpy.py", line 86, in _run_code
    exec(code, run_globals)
  File "/home/greg/.cache/bazel/_bazel_greg/b0c20c8ca453cbc6e375a5451bd4af5d/external/rules_python/python/pip_install/tools/wheel_installer/wheel_installer.py", line 200, in <module>
    main()
  File "/home/greg/.cache/bazel/_bazel_greg/b0c20c8ca453cbc6e375a5451bd4af5d/external/rules_python/python/pip_install/tools/wheel_installer/wheel_installer.py", line 192, in main
    _extract_wheel(
  File "/home/greg/.cache/bazel/_bazel_greg/b0c20c8ca453cbc6e375a5451bd4af5d/external/rules_python/python/pip_install/tools/wheel_installer/wheel_installer.py", line 132, in _extract_wheel
    whl_deps = sorted(whl.dependencies(extras_requested) - self_edge_dep)
  File "/home/greg/.cache/bazel/_bazel_greg/b0c20c8ca453cbc6e375a5451bd4af5d/external/rules_python/python/pip_install/tools/wheel_installer/wheel.py", line 79, in dependencies
    if req.marker is None or any(
  File "/home/greg/.cache/bazel/_bazel_greg/b0c20c8ca453cbc6e375a5451bd4af5d/external/rules_python/python/pip_install/tools/wheel_installer/wheel.py", line 80, in <genexpr>
    req.marker.evaluate({"extra": extra})
  File "/home/greg/.cache/bazel/_bazel_greg/b0c20c8ca453cbc6e375a5451bd4af5d/external/pypi__setuptools/pkg_resources/_vendor/packaging/markers.py", line 252, in evaluate
    return _evaluate_markers(self._markers, current_environment)
  File "/home/greg/.cache/bazel/_bazel_greg/b0c20c8ca453cbc6e375a5451bd4af5d/external/pypi__setuptools/pkg_resources/_vendor/packaging/markers.py", line 158, in _evaluate_markers
    groups[-1].append(_eval_op(lhs_value, op, rhs_value))
  File "/home/greg/.cache/bazel/_bazel_greg/b0c20c8ca453cbc6e375a5451bd4af5d/external/pypi__setuptools/pkg_resources/_vendor/packaging/markers.py", line 116, in _eval_op
    return spec.contains(lhs, prereleases=True)
  File "/home/greg/.cache/bazel/_bazel_greg/b0c20c8ca453cbc6e375a5451bd4af5d/external/pypi__setuptools/pkg_resources/_vendor/packaging/specifiers.py", line 568, in contains
    normalized_item = _coerce_version(item)
  File "/home/greg/.cache/bazel/_bazel_greg/b0c20c8ca453cbc6e375a5451bd4af5d/external/pypi__setuptools/pkg_resources/_vendor/packaging/specifiers.py", line 36, in _coerce_version
    version = Version(version)
  File "/home/greg/.cache/bazel/_bazel_greg/b0c20c8ca453cbc6e375a5451bd4af5d/external/pypi__setuptools/pkg_resources/_vendor/packaging/version.py", line 198, in __init__
    raise InvalidVersion(f"Invalid version: '{version}'")
pkg_resources.extern.packaging.version.InvalidVersion: Invalid version: '#34~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Thu Sep  7 13:12:03 UTC 2'
) error code: '1'

More details about the decision from the pip maintainers can be found here:
pypa/pip#12012

[twslankard]

Thanks for the report, @kgreenek .

The version string included in your stack trace (which seems to be produced from bazel, which is not part of our toolchain) is not an ouster-sdk version. Could this be caused by another package in your application?

I'm not able to reproduce this issue with the latest production version of pip (23.2.1) and with the latest version on master, which at this time is 23.2.1-227-g2333ef3b5 (with the package version 23.3.dev0).

At your convenience, would you please provide some information about which versions of pip and python3 you are using, as well as the full install command (e.g. pip install ouster-sdk)?

Best Regards,
Tom

Staff Engineer
Ouster Inc.

[kgreenek]

I am using bazel with rules_python, which is admittedly an unusual setup. Using rules_python, the version exception is raised starting with version 0.26.0. Falling back to 0.25.0 continues to work.

According to this issue on the pip github repo: "In 23.2, pip is starting to deprecate recognision of non-standard version strings. [...] The deprecated parsing logic is expected to be entirely removed in 24.0"

[twslankard]

@kgreenek thanks for the additional information. Do you have a minimum reproducible example I can try?

[kgreenek]

Here is a minimal reproducible example with instructions for how to run: https://github.com/kgreenek/ouster_sdk_pep440

[kgreenek]

The issue appears to be that this version (#34~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Thu Sep 7 13:12:03 UTC 2) for ouster-sdk is not compatible with PEP 440.

I am not sure where that version string is coming from to be honest. If that version string is part of the ouster-sdk package in pypi, I would ask if you would be willing to make a change to be in compliance with PEP 440. Otherwise, I need to dig in a bit deeper and figure out where that string is coming from.

[twslankard]

@kgreenek #34~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Thu Sep 7 13:12:03 UTC 2 is not an ouster-sdk version. Our current ouster-sdk release is 0.9.0.

[kgreenek]

Interesting. It seems like there is some interaction between rules_python and the ouster-sdk wheel going on. I'll file an issue with the rules_python folks too and see if they have any insight to add.

[twslankard]

I think you may have stumbled across a bug in the version of setuptools that is used by rules_python. (Or rules_python is providing the wrong input.)

Some investigation on my side reveals that the invalid version originates from the platform.version() value that is populated into the current environment used to assess whether the platform is complatible given the wheel's own environment markers.

This is why you'll probably find that the invalid version you get is actually the same value as platform.version() on your system. (This is true for my system, and I get a different value.)

[twslankard]

@kgreenek I've narrowed this down to the dependency spec for scipy that is present in ouster-sdk's setup.py.

The current spec is this, which I believe to be a valid dependency spec per PEP 508.

scipy >=1.7, <2;platform_system != "Darwin" or platform_machine != "arm64" or platform_version >= "21.0.0"

This dependency spec is used because there is no scipy available for ARM64 macOS 11 systems (though macOS 11 is technically supported by ouster-sdk.)

If I remove this dependency spec (specifically the platform_version >= "21.0.0" part) and rebuild the wheel and test your example with it, the issue goes away. Although I haven't confirmed this to be the case, I suspect that there is a bug in the toolchain you're using, since it is dependent, ostensibly, on the the platform_version values provided by Linux conforming to PEP 440.

A workaround would be to fork ouster-sdk, remove the scipy dependency spec, and build a new wheel for your app. Alternatively, you could follow up to confirm whether there is a bug in the toolchain.

[groodt]

Thanks for looking into this. I believe that this is actually an invalid specifier. See some notes here: bazelbuild/rules_python#1491 (comment)

tl;dr: you probably want to be using platform_release >= '21.0.0' instead anyway.

[twslankard]

I'm grateful for the assistance @groodt !

We'll work on a fix, most likely earmarked for a patch following the next release. I'll be keeping this ticket open for tracking purposes.

Best Regards,
Tom

Staff Engineer
Ouster Inc.

[lalten]

Hi, we're running into exactly the same issue. Any progress on a fix?
Side note: We don't have a compiler inside our CI image (it's a Bazel hermeticism thing) so we depend on the prebuilt wheel for ouster-sdk. That makes it a little more difficult to work around this bug.
ouster-sdk==0.8.1 is the last working version. 0.9.0 has the same issue as 0.10.0

[twslankard]

Hi @lalten,

I'm afraid we've not had the bandwidth to fix this issue yet, but we plan to address it in our next release which should be no later than end of March. I realize this is not ideal, but it is definitely a priority for us.

Best Regards,
Tom

Staff Engineer
Ouster Inc.

[lalten]

Hi @twslankard, is this issue resolved in https://github.com/ouster-lidar/ouster_example/releases/tag/20240425?

[twslankard]

Hi @lalten,

The issue is not fixed in this release, unfortunately. Please accept my apologies. We're working on it!

Cheers,
Tom

Staff Engineer
Ouster Inc.