Turning an app with embedded Python into a Jupyter kernel
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 20/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Necesita aclaración
- Estado de actividad
- Estancado
- Stack tecnológico
- jupyter-notebook, python
- Área
- developer-experience, tooling
Línea de trabajo
Comienza leyendo los ejemplos kernel.json y launch.py; después, inspecciona el código de inicio referenciado en qgspythonutilsimpl.cpp y el manejo de argumentos de traitlets application.py. Compara el comportamiento de inicio repetido observado con el flujo de lanzamiento de ipykernel y determina si es viable el enfoque solicitado de proceso integrado o proceso wrapper. Se considera terminado cuando exista una dirección de implementación documentada y el comportamiento de inicio y ejecución esté claramente resuelto.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
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...
- Lenguaje dominante
- Python
- Estrellas
- 734
- Forks
- 411
- Merge medio
- 1 d 2 h
- PR fusionados (30 d)
- 9
Guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de ipython/ipykernel
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 72/100
-
Dificultad 4/5 3-5 días Aptitud para principiantes 48/100
-
Dificultad 4/5 3-5 días Aptitud para principiantes 68/100
-
ipython/ipykernel#1550 · 1 comentario · 1 reacción · 1 asignado ·
Todos los issues de ipython/ipykernel
Issues similares
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 90/100
learningequality/ricecooker#747 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
BSData/horus-heresy-3rd-edition#3171 ·
-
enhancement
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
run-llama/llama_index#23199 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
KhronosGroup/glTF-Blender-IO#2769 ·