Turning an app with embedded Python into a Jupyter kernel
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức phù hợp với người mới
- 20/100
- Loại issue
- Tính năng
- Độ rõ ràng
- Cần làm rõ
- Mức độ hoạt động
- Đình trệ
- Công nghệ
- jupyter-notebook, python
- Lĩnh vực
- developer-experience, tooling
Hướng nghiên cứu
Bắt đầu bằng cách đọc các ví dụ kernel.json và launch.py, sau đó kiểm tra mã khởi động được tham chiếu trong qgspythonutilsimpl.cpp và cách xử lý đối số của traitlets application.py. So sánh hành vi khởi động lặp lại đã quan sát với luồng khởi chạy của ipykernel và xác định liệu cách tiếp cận tiến trình nhúng hoặc tiến trình wrapper được yêu cầu có khả thi hay không. Được xem là hoàn tất khi có định hướng triển khai được ghi lại và hành vi khởi động cũng như thực thi đã được giải quyết rõ ràng.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
I am doing a few experiments on apps with Python integration via embedded Python, i.e. QGIS (and FreeCAD). The objective is to turn them into Jupyter kernels. Both apps come with their own Python console, but I'd like to run their GUI and Jupyter lab side-by-side while Jupyter's kernel is actually the embedded Python interpreter of the GUI app. I essentially want to use Jupyter for interacting with the apps instead of the apps' own consoles.
I started with QGIS (and on Windows, because I was curious ...). For "implementation details" see below.
QGIS launches, but from Jupyter's perspective, the kernel keeps starting. It never "finishes" starting. Interestingly, I can actually re-start the kernel, i.e. QGIS, from within Jupyter just fine. Either way, code can not be executed.
- Completely ignoring my "implementation": Is what I described even possible?
- I am trying to make sense of
ipykernel(andipythonfor that matter), but it is not trivial to get started. Does my "implementation" make any sense or do I have to approach things differently altogether? - Alternatively, could I turn an already running process (pure Python or with embedded Python) into a "kernel" by attaching to it from some kind of a wrapper process (via some form of IPC) which is the actual kernel from Jupyter's perspective?
This is what I have so far:
kernel.json, which injects code at startup via PYQGIS_STARTUP:
{
"argv": [
"C:/Users/demo/mambaforge/envs/cluster/Library/bin\\qgis.exe",
"-m",
"ipykernel_launcher",
"-f",
"{connection_file}"
],
"display_name": "QGIS",
"language": "python",
"env": {
"PYQGIS_STARTUP": "C:/Users/demo/mambaforge/envs/cluster/share/jupyter/kernels/qgis/launch.py"
}
}
launch.py which is supposed to launch the kernelapp. argv is a bit of an issue because QGIS does not expose it via sys, hence the ugly hack. I think it should forward the args to the right place in traitlets:
from threading import Thread
import os
from time import time
import sys
from qgis.core import QgsApplication
from ipykernel import kernelapp as app
LOG_FN = 'C:/Users/demo/mambaforge/envs/cluster/share/jupyter/kernels/qgis/log.out'
def log_out(msg):
with open(LOG_FN, mode = 'a') as f:
f.write('%d | %s\n' % (round(time()), msg))
def launch_ipython():
log_out('Argv...')
argv = QgsApplication.arguments().copy() # HACK: sys.argv not available
log_out(str(argv))
log_out('App...')
app.launch_new_instance(argv = argv) # Blocks ... ?
log_out('Done?')
sys._ipython = Thread(target = launch_ipython) # HACK for later access
sys._ipython.start()
log.out from a single kernel start. Looks like two instances, threads or processes are getting started:
1621087681 | Argv...
1621087681 | ['C:/Users/demo/mambaforge/envs/cluster/Library/bin\\qgis.exe', '-m', 'ipykernel_launcher', '-f', 'C:\\Users\\demo\\AppData\\Roaming\\jupyter\\runtime\\kernel-b5e49e78-f742-49c1-b75d-6425c4fbee6a.json']
1621087681 | App...
1621087681 | Argv...
1621087681 | ['C:/Users/demo/mambaforge/envs/cluster/Library/bin\\qgis.exe', '-m', 'ipykernel_launcher', '-f', 'C:\\Users\\demo\\AppData\\Roaming\\jupyter\\runtime\\kernel-b5e49e78-f742-49c1-b75d-6425c4fbee6a.json']
1621087681 | App...
- Ngôn ngữ chính
- Python
- Star
- 734
- Fork
- 411
- Merge trung bình
- 1 ngày 2 giờ
- Pull request đã merge (30 ngày)
- 9
Hướng dẫn đóng góp
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 ipython/ipykernel
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 72/100
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 48/100
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 68/100
-
ipython/ipykernel#1550 · 1 bình luận · 1 reaction · 1 người được giao ·
Tất cả issue của ipython/ipykernel
Issue tương tự
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 90/100
learningequality/ricecooker#747 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
BSData/horus-heresy-3rd-edition#3171 ·
-
enhancement
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
run-llama/llama_index#23199 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 84/100
KhronosGroup/glTF-Blender-IO#2769 ·