Skip to content

Ensure user code never sees our 3rd party imports - #994

Open
godlygeek wants to merge 5 commits into
bloomberg:mainfrom
godlygeek:lazy_3rd_party_imports
Open

Ensure user code never sees our 3rd party imports#994
godlygeek wants to merge 5 commits into
bloomberg:mainfrom
godlygeek:lazy_3rd_party_imports

Conversation

@godlygeek

Copy link
Copy Markdown
Contributor

Import jinja2, rich, and textual lazily so that they aren't loaded into sys.modules before running user code in memray run or memray attach.

This is also used by the `summary` reporter, which is a CLI report and
not a TUI report. Moving this breaks an import time dependency from
`memray summary` on `textual`.

Signed-off-by: Matt Wozniski <mwozniski@bloomberg.net>
Whenever the `rich` module may or may not be needed by one of our
modules, delay the import until the point where we know whether we will
need it. Continue importing it unconditionally whenever every happy,
non-error path that imports a module will always need `rich`.

Signed-off-by: Matt Wozniski <mwozniski@bloomberg.net>
Import `LiveCommand` inside the functions that actually start the live
interface, so that the import of `textual` and `rich` is not visible to
the user's application, only to the sibling process running the TUI.

Signed-off-by: Matt Wozniski <mwozniski@bloomberg.net>
Rather than having the `memray` CLI eagerly import every subcommand
before even attempting to parse the command line, switch it to
understand that the first non-option argument is a subcommand name, and
to only import the module that the specific subcommand being invoked
comes from.

Fall back to importing all subcommands when no command is given, or when
we need one parser that understands all commands (like for the manpage
generation).

Signed-off-by: Matt Wozniski <mwozniski@bloomberg.net>
Add tests ensuring that the three third-party Python libraries we
currently depend on (jinja2, rich, textual) are not imported in the
same process as the user's code, neither by `memray run` nor by
`memray attach`.

Signed-off-by: Matt Wozniski <mwozniski@bloomberg.net>
@godlygeek godlygeek self-assigned this Aug 10, 2026
@godlygeek

Copy link
Copy Markdown
Contributor Author

@lkollar This lays the groundwork for what I was describing in #893 (comment) (and is something I've wanted to clean up for a long time, anyway...)

@codecov-commenter

Copy link
Copy Markdown

Codecov Report

❌ Patch coverage is 93.65079% with 4 lines in your changes missing coverage. Please review.
✅ Project coverage is 92.39%. Comparing base (f70db81) to head (3a84cb4).

Files with missing lines Patch % Lines
src/memray/reporters/common.py 95.55% 2 Missing ⚠️
src/memray/commands/attach.py 0.00% 1 Missing ⚠️
src/memray/commands/transform.py 0.00% 1 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main     #994      +/-   ##
==========================================
- Coverage   92.45%   92.39%   -0.07%     
==========================================
  Files         101      101              
  Lines       13211    13223      +12     
  Branches      477      477              
==========================================
+ Hits        12214    12217       +3     
- Misses        997     1006       +9     
Flag Coverage Δ
cpp 92.39% <93.65%> (-0.07%) ⬇️
python_and_cython 92.39% <93.65%> (-0.07%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

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

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants