Jurigged

Warnings

• gotcha Functions that are currently executing or are part of an active generator/async function will continue to run with their original code. Only subsequent invocations will reflect the changes. Breakpoints on the stack cannot be changed.
  Fix: Changes apply to the next execution of the function. For critical debugging, a full restart might be necessary, or consider alternative debugging approaches.
• breaking Changing class initializers (`__init__`) or attribute names can lead to broken objects. Jurigged updates methods on existing instances but does not re-run `__init__` or rename attributes, potentially causing inconsistencies between new methods and old data.
  Fix: Carefully manage changes to class structure, especially `__init__` and attribute definitions, during live updates. For substantial structural changes, a full application restart is recommended.
• gotcha Updating code for decorators or closures may not work reliably. Decorators that inspect or modify function code might not update properly, potentially leading to unexpected behavior or stale logic.
  Fix: Avoid making live changes to decorator definitions or the functions they wrap in complex ways. If modifications are essential, a restart is often the safest approach.
• gotcha Changing top-level module code (outside of `if __name__ == '__main__':`) can cause the `jurigged` watcher thread to stop, preventing further hot reloads. This is particularly problematic if the top-level code includes long-running loops.
  Fix: Always place your main application logic within an `if __name__ == '__main__':` block. `jurigged` will then re-execute only the diff if this guard is not touched.
• gotcha Line numbers in patched code can sometimes diverge, leading to incorrect line numbers in stack traces, debugger breakpoints drifting, and unexpected behavior. This issue is more prevalent with complex functions, nested functions, or altered decorator calls.
  Fix: If line number inconsistencies occur, restarting the application is the most reliable solution. For complex scenarios, consider simplifying the hot-reloaded code or improving test coverage to catch these issues early.
• gotcha File watching mechanisms can be inconsistent. Specifically, `watchdog` on Windows may watch directories rather than individual files, and some editors (like `vi` saving to temporary swap files) can cause issues. There are also no direct hooks for cleanup on hot reload, which can complicate state management for applications like web servers that manage connections.
  Fix: If file changes are not detected, try using the `--poll <INTERVAL>` flag (e.g., `jurigged --poll 1 your_script.py`). For applications requiring specific cleanup, consider implementing manual restart mechanisms or architectural patterns that tolerate abrupt code changes.

Install

• pip install jurigged Install with pip

Imports

• watch

  import jurigged
  jurigged.watch()

  To enable programmatic file watching, e.g., in an IPython/Jupyter session, or to explicitly start watching in a script.

Quickstart

To use jurigged, you can either run your script with `jurigged your_script.py` from the command line, or programmatically call `jurigged.watch()` within your script. Create a file named `my_app.py` with the code above. Run it using `jurigged my_app.py`. Then, modify the `greet` function (e.g., to `return "Hello, updated Jurigged!"`) and save the file. You will see the output change live without restarting the script.

import jurigged
import time

def greet():
    return "Hello, Jurigged!"

def main():
    jurigged.watch()
    print("Watching for changes... edit this file and save!")
    while True:
        print(greet())
        time.sleep(2)

if __name__ == '__main__':
    main()