Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Python2: always require a 44.x version of setuptools #71

Merged
merged 1 commit into from
Aug 24, 2020

Conversation

gavanderhoorn
Copy link
Contributor

@gavanderhoorn gavanderhoorn commented Aug 20, 2020

The old version specification would also evaluate to true if USE_SYSTEM_PACKAGES was TRUE and the base OS already had a version of setuptools installed (which is often the case).

On Xenial fi this leads to 20.7.0 satisfying the <45 requirement, but that version doesn't appear to be compatible with pip==20.1.

For context, see #70.

@gavanderhoorn
Copy link
Contributor Author

Tested this with ROS prereleases of haros_catkin on Ubuntu Xenial with i386 arch.

@gavanderhoorn gavanderhoorn changed the title Always require a 44.x version of setuptools Python2: always require a 44.x version of setuptools Aug 20, 2020
But not anything newer.

Older versions don't appear to work reliably with `pip==20.1`.

This helps when running a build of a package depending on catkin_virtualenv on OS which ship with an old version of setuptools (such as Ubuntu Xenial) when `USE_SYSTEM_PACKAGES` is not set to `FALSE`. In that situation, only specifying 'setuptools<45` will be true, as setuptools is installed (in the systems site packages), so pip will not upgrade it. Specifying a minimum version like this will force pip to always install an up-to-date version.
@gavanderhoorn
Copy link
Contributor Author

Prerelease test with Melodic on Bionic amd64 also passes (16 tests).

@gavanderhoorn
Copy link
Contributor Author

gavanderhoorn commented Aug 24, 2020

@paulbovbel: it's a bit ironic with 6 months+ of failing builds for my pkgs on the buildfarm, but could we get this merged so the build gets back to being green? ;)

Provided this works for your use-cases as well of course.

Copy link
Member

@paulbovbel paulbovbel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks!

@paulbovbel paulbovbel merged commit 1d79b3f into locusrobotics:master Aug 24, 2020
@gavanderhoorn gavanderhoorn deleted the patch-2 branch August 25, 2020 06:36
@gavanderhoorn
Copy link
Contributor Author

Thanks 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants