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

Make sure that 'tox -erust' fails on bad RC. #13753

Open
wants to merge 5 commits into
base: main
Choose a base branch
from

Conversation

kevinhartman
Copy link
Contributor

Summary

Previously, a non-zero exit code from the subprocess would not fail the tox run like we'd expect.

Previously, a non-zero exit code from the subprocess would not
fail the tox run like we'd expect.
@kevinhartman kevinhartman requested a review from a team as a code owner January 28, 2025 22:43
@qiskit-bot
Copy link
Collaborator

One or more of the following people are relevant to this code:

  • @Qiskit/terra-core

@coveralls
Copy link

coveralls commented Jan 28, 2025

Pull Request Test Coverage Report for Build 13063277813

Warning: This coverage report may be inaccurate.

This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

Details

  • 0 of 0 changed or added relevant lines in 0 files are covered.
  • 302 unchanged lines in 7 files lost coverage.
  • Overall coverage decreased (-0.1%) to 88.805%

Files with Coverage Reduction New Missed Lines %
crates/circuit/src/circuit_data.rs 3 94.94%
crates/qasm2/src/lex.rs 4 91.98%
qiskit/transpiler/preset_passmanagers/generate_preset_pass_manager.py 4 97.83%
crates/qasm2/src/parse.rs 6 96.68%
qiskit/providers/backend_compat.py 13 92.63%
crates/circuit/src/interner.rs 131 42.74%
crates/circuit/src/dag_circuit.rs 141 89.38%
Totals Coverage Status
Change from base Build 13010967771: -0.1%
Covered Lines: 79752
Relevant Lines: 89806

💛 - Coveralls

mtreinish
mtreinish previously approved these changes Jan 29, 2025
Copy link
Member

@mtreinish mtreinish left a comment

Choose a reason for hiding this comment

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

LGTM, just left a small comment inline. It doesn't really matter in this context though.

tox.ini Outdated
@@ -41,7 +41,7 @@ commands =
python -c '\
import os, subprocess, sysconfig;\
os.environ["LD_LIBRARY_PATH"] = os.pathsep.join(filter(None, [sysconfig.get_config_var("LIBDIR"), os.getenv("LD_LIBRARY_PATH")]));\
subprocess.run(["cargo", "test", "--no-default-features"])'
subprocess.run(["cargo", "test", "--no-default-features"]).check_returncode()'
Copy link
Member

Choose a reason for hiding this comment

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

Not that it particularly matters in this context. But what I normally do is:

Suggested change
subprocess.run(["cargo", "test", "--no-default-features"]).check_returncode()'
subprocess.run(["cargo", "test", "--no-default-features"], check=True)'

Copy link
Member

Choose a reason for hiding this comment

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

I think pylint has a lint against failing to check the return code of subprocess.run - it might be a motivation to move this inline script into a proper file in the tools directory so it's subject to lint?

Copy link
Member

Choose a reason for hiding this comment

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Seems like a good idea, and should let us use the same script from tox and CI.

Done in 663eaa8.

Copy link
Member

@mtreinish mtreinish left a comment

Choose a reason for hiding this comment

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

This LGTM for the most part. I like having the script in a dedicated file now. Just one question/suggestion inline.

Comment on lines +33 to +35
os.environ["LD_LIBRARY_PATH"] = os.pathsep.join(
filter(None, [sysconfig.get_config_var("LIBDIR"), os.getenv("LD_LIBRARY_PATH")])
)
Copy link
Member

Choose a reason for hiding this comment

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

Is there a reason to not just do?:

Suggested change
os.environ["LD_LIBRARY_PATH"] = os.pathsep.join(
filter(None, [sysconfig.get_config_var("LIBDIR"), os.getenv("LD_LIBRARY_PATH")])
)
os.environ["LD_LIBRARY_PATH"] = os.pathsep.join([
sysconfig.get_config_var("LIBDIR"),
os.getenv("LD_LIBRARY_PATH")
])

I've always found the filter(None, ...) pattern a bit odd when you can just use a generator expression.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The reason I did that was to filter out None in the case that "LD_LIBRARY_PATH" isn't actually set to anything. I can do something different if you prefer!

@kevinhartman kevinhartman added the on hold Can not fix yet label Jan 30, 2025
This fixes an issue where the site-packages added to sys.path
could be wrong (e.g. if using Framework-based Python on macOS).

This was happening because the venv would install qiskit using
one pathing scheme while the Python interpreter baked into the test
executable would use (potentially) another when generating the path
from PYTHONUSERBASE.

See https://docs.python.org/3/library/sysconfig.html#installation-paths
for details.

To resolve this, we just set the path to the venv's site-packages via
PYTHONPATH.
@kevinhartman kevinhartman removed the on hold Can not fix yet label Jan 30, 2025
@kevinhartman
Copy link
Contributor Author

While testing this on his machine, @raynelfss discovered an issue with using the existing approach with PYTHONUSERBASE to get the virtual environment's site-packages into the embedded Python interpreter's path. The issue was that venvs use a potentially different folder layout when installing packages than the system's Python will use when looking for them, so the path returned by site.USER_SITE was incorrect.

Instead, we now set the PYTHONPATH to directly be the actual full path to the active Python interpreter's site-packages, which is more natural anyways. This wasn't done originally because before this PR, we weren't actually invoking cargo test from within a Python script.

Anyway, this should be good to go now.

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.

5 participants