Turning an app with embedded Python into a Jupyter kernel
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 5/5
- Temps estimé
- Plus d'une semaine
- Accessibilité débutants
- 20/100
- Type d'issue
- Fonctionnalité
- Clarté
- À clarifier
- Activité
- À l'abandon
- Stack technique
- jupyter-notebook, python
- Domaine
- developer-experience, tooling
Piste de recherche
Commencez par lire les exemples kernel.json et launch.py, puis examinez le code de démarrage référencé dans qgspythonutilsimpl.cpp ainsi que la gestion des arguments dans traitlets application.py. Comparez le comportement de démarrage répété observé avec le flux de lancement d’ipykernel et déterminez si l’approche demandée avec un processus intégré ou un processus wrapper est réalisable. Le travail est terminé lorsqu’une orientation d’implémentation documentée existe et que le comportement au démarrage et à l’exécution est clairement établi.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
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...
- Langage dominant
- Python
- Étoiles
- 734
- Forks
- 411
- Merge moyen
- 1 j 6 h
- PR mergées (30 j)
- 10
Guide de contribution
Ouvrir le guide de contribution
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de ipython/ipykernel
-
Difficulté 2/5 1-3 heures Accessibilité débutants 75/100
-
Difficulté 1/5 Moins d'une heure Accessibilité débutants 72/100
-
Difficulté 4/5 3-5 jours Accessibilité débutants 48/100
-
Difficulté 4/5 3-5 jours Accessibilité débutants 68/100
-
ipython/ipykernel#1550 · 1 commentaire · 1 réaction · 1 personne assignée ·
Toutes les issues de ipython/ipykernel
Issues similaires
-
bug
Difficulté 2/5 1-3 heures Accessibilité débutants 75/100
stephrobert/dsoxlab#238 ·
-
Difficulté 2/5 1-3 heures Accessibilité débutants 75/100
-
Difficulté 2/5 1-3 heures Accessibilité débutants 75/100
sublimehq/package_control#1780 ·
-
Difficulté 2/5 1-3 heures Accessibilité débutants 65/100
-
Difficulté 2/5 1-3 heures Accessibilité débutants 70/100
nwg-piotr/nwg-displays#145 ·