Specify a custom location for `MUJOCO_LOG.TXT`
Is your feature request related to a problem? Please describe.
The MuJoCo log is always written to the MUJOCO_LOG.TXT file in the calling directory, which is not ideal for all project structures.
Describe the solution you'd like
- Specify a custom directory in which
MUJOCO_LOG.TXTis generated. - Specify a custom filename for the MuJoCo log.
Describe alternatives you've considered
- Moving the file after program execution is completed (cumbersome and feels like a hack).
Additional context N/A
Sorry for taking more than a year to get back to you 😬
Question: what would be the most natural way to specify the name and directory?
Also, wouldn't you want to possibly pass in STDERR and/or STDOUT instead of a filename?
Proposed Solutions for Specifying MuJoCo Log Output
Natural Way to Specify Name and Directory
The most natural way to specify a custom name and directory for the MuJoCo log file would be through configuration options passed at initialization. This approach aligns with existing conventions for managing logging and configuration in many libraries. Possible methods:
- Environment Variables
Example:
export MUJOCO_LOG_FILE=/path/to/custom_directory/custom_log.txt
This keeps the API clean, allowing the library to pick up the configuration without requiring changes in the code.
- API Function or Parameter
Expose a function or parameter in the initialization phase to set the log file:
mujoco.set_log_file("/path/to/custom_directory/custom_log.txt")
This provides explicit control within the program, which may be preferred for dynamically determined paths.
Supporting STDERR and/or STDOUT
Yes, it would be valuable to allow directing the log output to STDERR or STDOUT. This flexibility is useful for debugging, containerized environments, or scenarios where capturing output via streams is required. For instance:
A reserved keyword could indicate these options: "STDOUT": Log to standard output. "STDERR": Log to standard error. Example usage: mujoco.set_log_file("STDOUT")
This makes sense to me. I think in general we try to avoid library-level globals, but this seems justified.
Sorry for taking more than a year to get back to you 😬
Question: what would be the most natural way to specify the name and directory?
Also, wouldn't you want to possibly pass in
STDERRand/orSTDOUTinstead of a filename?
@yuvaltassa That's alright, better late than never!
I think @Nick20500's response above hits the nail on the head. STDOUT and STDERR would be great to have. I would just love to have a way to generate these logs in a user-specified location and with a user-specified name so that they are not overwritten with each new program run.