Magic command defaults upgrade + delete messages
The problem:
Magic commands previously saved to and overwrote message.json by default. The problem is:
- You want to save messages quickly, but you don't necessarily want it to overwrite.
- The name message.json is uninformative - you know nothing about the contents.
- The message JSONs are also small, so storing multiple past conversations easily outweighs the cons.
Relevant issue
Fixes #564
The Fix:
- Updated the save name convention to be
[date]_messages_[counter].jsonwhen no path is provided. - Loads the latest message
[date]_messages_[counter].jsonwhen no path is provided. - Added %delete_messages to let you clean up historical messages, which accepts a parameter (for the number of files you wish to preserve) - or deletes everything except the most recent file by default.
- Updated the
handle_helpfunction to reflect the changes.
With this approach, you can still save the messages quickly without overwriting. The names also include the date so you're able to get more information about the file (albeit nothing too in-depth). If you wish to clear out previous messages, you can also do that now too.
Testing
- [ ✅] I have performed a self-review of my code:
I have tested the code on the following OS:
- [ ] Windows
- [✅ ] MacOS
- [ ] Linux
AI Language Model (if applicable)
N/A
Took a look, no reason for builds to fail. None of my code touches the interpreter logic - purely magic commands.
I've also tested it, and all works fine. Having looked through some other PRs (open and closed) seems to be a recurring issue.
Evidence of testing
Overall, I really like this change. It's a solid improvement on storing and retrieving conversation threads. Nice work!
I wonder if we should use the same path that the user's config.yaml gets stored in if they don't provide a path - rather than polluting whatever current directory they were in when they initiated interpreter
I believe getting the correct directory for the user's config.yaml file is handled in interpreter/utils/get_config.py and we could use similar logic or extract that path creation into a separate utility that this functionality can import, too.
I wonder if we should use the same path that the user's
config.yamlgets stored in if they don't provide a path - rather than polluting whatever current directory they were in when they initiatedinterpreterI believe getting the correct directory for the user's
config.yamlfile is handled ininterpreter/utils/get_config.pyand we could use similar logic or extract that path creation into a separate utility that this functionality can import, too.
Yeah, I'm happy to extract this out if we're re-using the logic across multiple places.
@richawo I think just making the update so that %delete_messages works and resolving the most recent merge conflicts would be enough, and we can look at abstracting the common functionality out into a utility in a separate PR.
Thanks for taking this one on!
@ericrallen, hey, I'll sort it out shortly! Sorry, I've been distracted by too many projects lately 😅
No worries, @richawo.
I just wanted to revisit this one because I think it's a nice quality-of-life improvement.
Happy to help with the resolution of Merge Conflicts, too. I know sometimes they can get a bit tricky after so many changes have been made since a PR started.
Hi @richawo Any desire to revive this PR? Or should I close it? Thanks!
Haha I really should, still not fixed right?
@richawo
haha even though a lot has changed, it still defaults to messages.json if no path is provided.
Let me know if you have any questions or any other ideas for how to improve magic commands!