-
Notifications
You must be signed in to change notification settings - Fork 155
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
Update tox configuration to use tox >= 4.4.0 #851
Conversation
Tox 4.0.0 was released in December 2022 [1] and was a major rewrite of the internals of the package that included numerous backwards incompatible changes [2]. Along with that major rewrite was a long period of instability in the package with a flurry of 47 releases [3] since 4.0.0 (which has only been 3-4 months). At the time of the 4.0.0 release we pinned the tox version in CI with Qiskit#761 to avoid this instability as our tox configuration was not compatible with tox 4.x.y and tox was actually not compatible with how we had things configured more generally. The hope was that tox would stabilize more, fix the issues that plagued the tox 4 release series and we'd be able to relax that pin without requiring bumping our minimum tox version to ensure users could use either the old version or the new version locally. However, since Qiskit#761 that hope hasn't been realized the divergence between tox 3 and tox 4 has only widened and at least personally I'm not convinced of an improvement in stability to the tox 4 release series. That being said however, this is becoming a developer pain as by default when setting up a new build environment pip will install the latest version of tox and we don't have an effective mechanism to pin the tox version for users as you need to install tox manually as it's the primary python development entrypoint we use. The only only avenue to address this would be documentation updates in the CONTRIBUTING.md file, which we didn't update at the time in Qiskit#761 because it was meant to be a version temporary pin that has turned out to not be so temporary. Since it's been >3 months since we first pinned the tox version and that pin was meant to be temporary this commit removes that pin and bumps our minimum supported tox version to be 4.4.0, which despite not being compatible with tox < 4 as we originally hoped, at least seems to work fine with install rustworkx after updating the configuration file. This should hopefully ease the onboarding experience for developers when working with rustworkx and trying to bootstrap a local development environment. Longer term I expect we'll look at moving off of tox, as it no longer seems like a project we can rely on (especially as a key component for our development and CI infrastructure) for rustworkx and instead look at something like `nox` which I've heard good things about and know that PyO3 had moved to it a year or two ago. Fixes Qiskit#812 [1] https://pypi.org/project/tox/4.0.0/ [2] https://tox.wiki/en/latest/upgrading.html [3] https://pypi.org/project/tox/#history
Pull Request Test Coverage Report for Build 4565438872
💛 - Coveralls |
be2749a
to
abd6311
Compare
Tox's isolated builder mechanism seems to be incompatible with our environment variable based package naming mechanism that we use to build the legacy retworkx package. This is causing CI to fail on the backwards compat jobs that are installing retworkx (which depends on rustworkx) to ensure that our backwards compatibility shim works as expected. Instead of trying to force tox to do the correct thing, it's just easier to stop using it for that one CI job and instead just manually install and run the tests.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, this is almost identical to #813 but it passes the CI so let's stick to it
changedir = {toxinidir}/tests | ||
commands = | ||
stestr run {posargs} | ||
|
||
[testenv:lint] | ||
basepython = python3 | ||
envdir = .tox/lint |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is the only difference from #813, really
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's fair, well this and splitting out the retworkx jobs and setting the minimum tox version. Both of these are important, because tox 4 doesn't allow shared envs anymore and also doesn't support the build interface we need for the retworkx jobs.
Tox 4.0.0 was released in December 2022 [1] and was a major rewrite of the internals of the package that included numerous backwards incompatible changes [2]. Along with that major rewrite was a long period of instability in the package with a flurry of 47 releases [3] since 4.0.0 (which has only been 3-4 months). At the time of the 4.0.0 release we pinned the tox version in CI with #761 to avoid this instability as our tox configuration was not compatible with tox 4.x.y and tox was actually not compatible with how we had things configured more generally. The hope was that tox would stabilize more, fix the issues that plagued the tox 4 release series and we'd be able to relax that pin without requiring bumping our minimum tox version to ensure users could use either the old version or the new version locally. However, since #761 that hope hasn't been realized the divergence between tox 3 and tox 4 has only widened and at least personally I'm not convinced of an improvement in stability to the tox 4 release series. That being said however, this is becoming a developer pain as by default when setting up a new build environment pip will install the latest version of tox and we don't have an effective mechanism to pin the tox version for users as you need to install tox manually as it's the primary python development entrypoint we use. The only only avenue to address this would be documentation updates in the CONTRIBUTING.md file, which we didn't update at the time in #761 because it was meant to be a version temporary pin that has turned out to not be so temporary.
Since it's been >3 months since we first pinned the tox version and that pin was meant to be temporary this commit removes that pin and bumps our minimum supported tox version to be 4.4.0, which despite not being compatible with tox < 4 as we originally hoped, at least seems to work fine with install rustworkx after updating the configuration file. This should hopefully ease the onboarding experience for developers when working with rustworkx and trying to bootstrap a local development environment. Longer term I expect we'll look at moving off of tox, as it no longer seems like a project we can rely on (especially as a key component for our development and CI infrastructure) for rustworkx and instead look at something like
nox
which I've heard good things about and know that PyO3 had moved to it a year or two ago.Fixes #812
[1] https://pypi.org/project/tox/4.0.0/
[2] https://tox.wiki/en/latest/upgrading.html
[3] https://pypi.org/project/tox/#history