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

Pin tox version used in CI to < 4.0.0 #761

Merged
merged 1 commit into from
Dec 13, 2022
Merged

Conversation

mtreinish
Copy link
Member

The most recent tox release, 4.0.0, is a major rewrite of the internals of tox and several things behave quite differently. This new release is causing CI jobs to fail as something in incompatible with our tox configuration. This commit pins the tox version we're using in CI to unblock things until we can update the tox configuration to be compatible with both the new and old versions of tox.

The most recent tox release, 4.0.0, is a major rewrite of the internals
of tox and several things behave quite differently. This new release
is causing CI jobs to fail as something in incompatible with our tox
configuration. This commit pins the tox version we're using in CI to
unblock things until we can update the tox configuration to be
compatible with both the new and old versions of tox.
@coveralls
Copy link

Pull Request Test Coverage Report for Build 3676908400

  • 0 of 0 changed or added relevant lines in 0 files are covered.
  • No unchanged relevant lines lost coverage.
  • Overall coverage increased (+0.03%) to 96.949%

Totals Coverage Status
Change from base Build 3621874818: 0.03%
Covered Lines: 13506
Relevant Lines: 13931

💛 - Coveralls

@mtreinish mtreinish merged commit be3d117 into Qiskit:main Dec 13, 2022
@mtreinish mtreinish deleted the pin-tox branch December 13, 2022 12:11
jlapeyre added a commit to jlapeyre/rustworkx that referenced this pull request Feb 10, 2023
IvanIsCoding pushed a commit that referenced this pull request Feb 27, 2023
The most recent tox release, 4.0.0, is a major rewrite of the internals
of tox and several things behave quite differently. This new release
is causing CI jobs to fail as something in incompatible with our tox
configuration. This commit pins the tox version we're using in CI to
unblock things until we can update the tox configuration to be
compatible with both the new and old versions of tox.
mergify bot added a commit that referenced this pull request Feb 27, 2023
* Fix Matplotlib warning when building docs (#820)

Fix the warning in the docs because of matplotlib.cm deprecations.

(cherry picked from commit 50c3968)

* Fix clippy with Rust 1.66.0 (#762)

The recent release of Rust 1.66.0 [1] added new on by default clippy rules
which are causing failures when we run the clippy CI job with the new
rust version. This commit updates the code to fix the issues that clippy
has identified which will unblock CI.

[1] https://blog.rust-lang.org/2022/12/15/Rust-1.66.0.html

* Set MSRV for clippy in rustworkx (#793)

Starting in the recently released Rust 1.67.0 clippy enabled a new rule
by default, uninlined_format_args [1], which warns when format!() is
used and a variable is not put in the string inline but isntead as a
separate argument in the macro. For example, `format!("{}", foo)`
Instead the rule suggests using the variable inline the format call
(e.g. `format!("{foo}")`. However, with our msrv of 1.56.1
this syntax was not supported. So trying to fix the places the rule is
triggered as suggested will fail to compile with rust 1.56.1. To address
this and solve this for future rust releases and potential new rules this
commit adds a clippy.toml file which sets the msrv for the rustworkx crate
This will by default disable rules that weren't on by default in rust
1.56.1.

[1] https://rust-lang.github.io/rust-clippy/master/index.html#uninlined_format_args

* Pin tox version used in CI to < 4.0.0 (#761)

The most recent tox release, 4.0.0, is a major rewrite of the internals
of tox and several things behave quite differently. This new release
is causing CI jobs to fail as something in incompatible with our tox
configuration. This commit pins the tox version we're using in CI to
unblock things until we can update the tox configuration to be
compatible with both the new and old versions of tox.

---------

Co-authored-by: Ivan Carvalho <8753214+IvanIsCoding@users.noreply.github.com>
Co-authored-by: Matthew Treinish <mtreinish@kortar.org>
mtreinish added a commit to mtreinish/retworkx that referenced this pull request Mar 30, 2023
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
mergify bot pushed a commit that referenced this pull request Apr 1, 2023
* Update tox configuration to use tox >= 4.4.0

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

* Stop using tox for retworkx backwards compat jobs

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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants