Session context level CLI wanted.

[NoughtQ]

Is your feature request related to a problem? Please describe.
Although the functionality of ExpOven itself offers a lot of convenience, I find it a bit cumbersome to have to type the bake command every time I want to use ExpOven. I think it could be made even simpler.

Describe the solution you'd like
I think we could take inspiration from how conda works:

• Use the bake activate command to activate ExpOven, after which the execution status of subsequent commands will be monitored by ExpOven. If possible, it would be ideal to indicate the running status of ExpOven on the command line, similar to how conda virtual environments are displayed.
• Use the bake deactivate command to deactivate ExpOven.

Describe alternatives you've considered
None.

Additional context
None.

[IsshikiHugh]

Thank you for your suggestion!

I have some different opinions on this:

1. I believe that what actually bother you is that each time you type your command and you find that you need to move the cursor to the beginning and then type bake.
   • In that case, I suggested you to use ding instead of bake. For example python run_exp.py ; ding "run_exp done!".Although some information is lost, it's convenient in my cases.
   • Or, you can choose to use the function wrapper @oven.monitor. It remains some necessary information as well.
2. The solution you provided is great but it has two problems I thought:
   1. People (at least people as I know) usually won't run huge experiments continuously. That means, what they do actually is like:

      python run_exp.py
      ll
      cd some/where
      vim some/file
      python run_exp.py
      

      In that case, some very short command will be quite noisy.
   2. One possible way to make it usable is to make this only affect current terminal session. I am not sure whether it's easy to implement, but even if it's not that complicate, we still need to adapt different shells, that's more annoying.

Let me know if you have any different ideas. I am glad to discuss this with you!

[NoughtQ]

Thank you for your response! You’ve raised some different perspectives, and I’d like to further elaborate on my views regarding these points:

1. First, my situation is not exactly as you described. If I want to monitor the status of a running program, I’m more accustomed to typing bake first and then entering the command. The solution you provided still doesn’t address the hassle of repeatedly entering the bake command: my habit is to maintain a long-running terminal session dedicated to running experiments. In this session, I might run experiments multiple times in succession, which can be quite annoying. Wouldn’t it be much more convenient if I could activate ExpOven right after starting the session?

2. You suggested a solution for Python programs: adding the @oven.monitor decorator. For Python programs, this is indeed a good option. However, although ExpOven is designed for AI researchers, and many AI projects are implemented in Python, I hope ExpOven can offer greater versatility. With the solution I proposed, it would be possible to monitor programs other than Python, which I believe would be more practical and convenient.

Adapting this feature to work across different terminals is indeed a significant challenge. However, I asked DeepSeek "how conda manages to display the state of the virtual environment in the terminal", and it provided a seemingly feasible solution. I think you could draw some inspiration from that.

[IsshikiHugh]

Thank you for the informative reply!
Your concern does make the point. However, conda's logic can't perfectly fit your need. Here I will present my considering and my solution, it's nice if you can share your opinions about this.

Why not conda's implementation.

Conda control virtual environments through overwriting specific commands like python.

That means, only limited, pre-prepared commands would be affected, I believe that's what you want. At least I think that's worse than ask the programmer to use shell_execute("ding xxx") inside each program.

trap might be helpful.

However, I found trap command might helps, but it's still not perfect. Basically, what trap enable some triggers before/after the commands (and there are more details there, about command SIGNALs). But it can't decorate the raw command. I.e., you can call bake $RAW_CMD in extra, but you can't replace $RAW_CMD with bake $RAW_CMD.

Thus, we need to unpack the wrapping logic to the shell script level, using something like ding, like:

capture $RAW_CMD
START_TIME=$(date)   # Shell sensitive, e.g., fish use `set START_TIME $(date)`.
ding "$RAW_CMD started at $(START_TIME)"
$RAW_CMD
END_TIME=$(date)
ding "$RAW_CMD ended at $(END_TIME)"

That seems feasible, but still some difficulties there:

1. It takes effort to align the performance of bake and this strategy.
2. Adapting different shells is annoying, for bash/zsh/..., it can be easily adapted, but personally, I hope it supports fish as well. But that leads to the problem of how to detect the current activated shell. I don't think ExpOven want to do something with .zshrc or .bashrc or config.fish.

Conclusion

If we can only find the above solution and can't solve those problems better, I'd rather don't incorporate this into the main ExpOven, but maybe provide some shell-specific code snippets and let the user to add them. Maybe something like oven embed zsh. And after that it imports oven activate and oven deactive. But this just make the problem more complex. (Since some corner cases need to be tested.)

Thus, I think we can first find an elegant solution within this issue, and to see if others have this need as well.

[NoughtQ]

Thank you for your detailed and patient explanation!

I must admit that my initial thoughts might have been somewhat superficial, as I only saw the convenience brought by the conda activate/deactivate commands on the surface, without carefully considering their actual operational mechanisms: after activating a virtual environment with conda, it only affects certain commands (such as python), which is actually sufficient in most cases. Moreover, the virtual environment is physically located within the miniconda or anaconda directory. Clearly, we wouldn't want to create a virtual environment directly within the ExpOven project directory.

Given my current knowledge and engineering capabilities, I can't think of a better solution. However, I hope to keep this issue open, as other developers using ExpOven might come up with better ideas.

[IsshikiHugh]

Yeah, you are right. But one thing I would mention is that we actually have an ExpOven-owned folder, ~/.config/oven. So the directory issue is not a problem. (Also, I don't think we need such a huge storage like conda.)

I will keep this in my mind in case we have more elegant solution in the future.