Move the memray attach callback into a module
#459
Conversation
Added --aggregate option which allows user to request aggregated mode for in-memory aggregation. Signed-off-by: Ivona Stojanovic <[email protected]>
Signed-off-by: Ivona Stojanovic <[email protected]>
Added a unit and an integration test for the --aggregate option. The unit test tests the case when --aggregate is given but --output is not. The --aggregate option is tested in the integration test. Signed-off-by: Ivona Stojanovic <[email protected]>
Previously we were maintaining this as a string literal inside the client-side `attach` code, but it's growing more complex, and we're reaching the point where it would be advantageous to have it in a normal module that linters and type checkers can analyze. Signed-off-by: Matt Wozniski <[email protected]>
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## main #459 +/- ##
==========================================
- Coverage 91.88% 91.77% -0.11%
==========================================
Files 90 92 +2
Lines 10766 10822 +56
Branches 1473 1486 +13
==========================================
+ Hits 9892 9932 +40
- Misses 872 888 +16
Partials 2 2
Flags with carried forward coverage won't be shown. Click here to find out more.
☔ View full report in Codecov by Sentry. |
|
Actually... I've realized this will break using a new version memray to attach to a Python process where an older version of memray is installed. Now, that's not really something we've ever officially supported, but it is something that has always mostly worked - the live TUI wouldn't work if the client and server use a different version of our record format, but I believe attaching a tracker that outputs to a capture file has always worked, and that's something that our users might be relying on without us realizing it. That's a strong argument for sticking with having the client inject the code to be executed, rather than having the server import it from its installed copy of memray. |
|
Let's not do this. It doesn't work as nicely as I thought it would. |
Previously we were maintaining this as a string literal inside the
client-side
attachcode, but it's growing more complex, and we'rereaching the point where it would be advantageous to have it in a normal
module that linters and type checkers can analyze.
This commit is based on the code in #455, and will need to be rebased once we land that, but it's ready for review other than that. Marking it draft until #455 is landed.