Livecoding Mode for Python
@catilac đang làm issue này rồi.
Từ ngày 24/1/2026.
Đánh giá
Issue này chưa được đánh giá.
Mô tả
Leverage bevy_ecs to watch the currently running sketch for changes and hotswap on successfully compiling edits
Edit: I'm currently working on this, but there are some architectural questions I have.
Current Approach
I've created a new bevy Asset called Sketch and spawn that object at Startup.
When I make a change to sketch.py bevy will notice. yay
The question now is how does the actual reloading mechanism work for Python? And there is a larger question of how does this mechanism work for other language frontends (Processing4/java, lua, ocaml, scheme, ruby, etc...)
For Python (w/ pyo3)
- Make a change to
sketch.py - Bevy will observe and [emit an event]
processing_pyo3crate will check if a reload is necessary- Using something like importlib.reload(), pyo3 can reload the module, and skip creating a new graphics context if it doesn't have to, and grab the new draw and setup functions.
+--------+ +------+
| Python |------->| Bevy |
+--------+ +------+
^ |
| |
+-- onChange ----+
What about other language front-ends?
I suppose some custom plugin loading could work. The Sketch Asset could be something that Python introduces, so that would allow for us to only use any of that design only for our pyo3 implementation
The other front-ends would have to build their own systems, and we could expose hot-reloading related FFI methods?
I think at the moment, I really like the idea of just having a Python related Livecoding bevy plugin. I'm still learning about bevy's ECS system, but is it possible for us to represent our "scene graph" as an intermediary that can easily map to the existing entities in bevy?
ie:
def draw():
background(220)
fill(255, 0, 100)
stroke(0)
stroke_weight(2)
rect(100, 100, 200, 150)
when I change stroke_weight, could bevy know to update, or refresh that particular entity?
or is it easier to just drop all the entities and re-run the sketch? I might be over thinking it.
For now I'm going to work towards getting python to hotreload.
- Ngôn ngữ chính
- Rust
- Star
- 69
- Fork
- 14
- Merge trung bình
- 15 ngày 22 giờ
- Pull request đã merge (30 ngày)
- 3
Hướng dẫn đóng góp
Chưa lập chỉ mục được hướng dẫn đóng góp cho kho mã nguồn này
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của processing/libprocessing
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
processing/libprocessing#233 ·
-
Dropping Python 3.10 support Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
processing/libprocessing#229 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 62/100
processing/libprocessing#201 ·
-
Gate processing_midi for WASM Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 65/100
processing/libprocessing#194 ·
-
documentation
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
processing/libprocessing#146 · 1 bình luận ·
Tất cả issue của processing/libprocessing
Issue tương tự
-
todo:perf
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 84/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 88/100
-
ACP agents get no MCP servers when the thread is created before the project's first worktree loads Đang mởstate:needs triage
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 88/100
zed-industries/zed#64611 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 74/100
ontola/atomic-server#1625 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 88/100
objectionary/phie#154 ·