Open kgreenek opened 8 months ago
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.
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"
@kgreenek thanks for the additional information. Do you have a minimum reproducible example I can try?
Here is a minimal reproducible example with instructions for how to run: https://github.com/kgreenek/ouster_sdk_pep440
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.
@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
.
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.
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.)
@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.
Thanks for looking into this. I believe that this is actually an invalid specifier. See some notes here: https://github.com/bazelbuild/rules_python/issues/1491#issuecomment-1763358448
tl;dr: you probably want to be using platform_release >= '21.0.0'
instead anyway.
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.
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
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.
Hi @twslankard, is this issue resolved in https://github.com/ouster-lidar/ouster_example/releases/tag/20240425?
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.
@lalten
The team tells me our latest release should resolve this issue. I apologize for the mixed messages. Would you be willing to try https://pypi.org/project/ouster-sdk/0.11.1/ and let me know if it meets your needs?
I've confirmed the issue is still present. I'm working on a fix now.
Cheers, Tom
I don't think this issue is fixable at this time, at least not without help from the Bazel maintainers.
Here's what we see so far:
pip
(24.0) and the most recent setuptools
(70.0.0).setuptools
package has a method for evaluating environment markers that raises InvalidVersion
for the marker platform_release >= "21.0.0"'
. This method is apparently what Bazel uses.platform_release
values at install time. (Note, since pip
install doesn't fail, pip
must not be using the marker evaluation methods.)
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:
More details about the decision from the pip maintainers can be found here: https://github.com/pypa/pip/issues/12012