Ipython: La fonction "Télécharger au format PDF" affiche un message d'erreur inutile et nécessite une grande dépendance

L'erreur de latex s'est-elle affichée dans la page d'erreur HTML ou uniquement dans le terminal ?
Tant que le message d'erreur spécifique arrive à la page d'erreur, je pense
c'est tout ce que nous pouvons faire. Nous ne sommes pas sur le point d'essayer d'analyser pourquoi le latex a échoué - je suis
bien sûr, il y a plusieurs façons possibles.

Il serait intéressant d'étudier d'autres moyens de produire un PDF,
comme utiliser reportlab ou wkhtmltopdf. Nous ne devrions certainement pas appeler
à un service Web par défaut.

L'erreur de latex s'est affichée dans le terminal. Dans la page d'erreur HTML, le seul message que j'ai reçu était nbconvert failed: PDF creating failed . Qu'en est-il de l'ajout du traceback à la page d'erreur HTML ?

J'ai oublié de mentionner que l'idée d'utiliser un service Web était censée être une solution de repli lorsqu'une erreur se produit dans l'installation locale. Ne devrait-il pas être assez simple de créer un serveur recevant des demandes de conversion de fichiers ipynb similaires à ce que fait nbviewer ?

Les services Web comme nbviewer sont des personnes opt-in qui rendent leur travail public et sur internet.
Avoir un service Web pour PDF par défaut serait vraiment mauvais pour la confidentialité et rendrait le notebook inutilisable en ligne.

Le seul service qui fait ça pour l'instant est matjax, car il était trop gros. Et pour la version 4.0, nous l'expédierons dans le cadre d'IPython.

@Carreau Je ne dis pas que le PDF serait publié en ligne publiquement, mais converti dans un serveur géré par Ipython et livré en téléchargement pour l'utilisateur comme solution de secours au cas où il n'y aurait pas une installation correcte sur la machine locale.

Il est très mal vu dans le monde open source d'avoir un logiciel qui envoie automatiquement vos données à un serveur alors que vous ne lui avez pas explicitement demandé de le faire. Nous pourrions éventuellement faire quelque chose comme ça en tant qu'option explicite « convertir en PDF sur les serveurs d'IPython », mais nous ne le ferions pas comme solution de repli lorsque la conversion locale échouait.

Oui, tu as raison, ce serait mieux. Peut-être un message indiquant que quelque chose s'est mal passé avec la conversion et un bouton supplémentaire pour télécharger le fichier à l'aide d'un service Web externe.

Je pense que cela pourrait être faisable, mais dans ce cas pourquoi s'arrêter au PDF ?
Avoir un service de conversion (complet, mais toujours restreint) dans le cloud pourrait avoir du sens et a déjà été mentionné à quelques reprises. Ce serait une "API nbviewer". Cependant, cela soulève une question juridique problématique de responsabilité en cas de fuite de données utilisateur, de piratage ou d'autres choses que nous ne sommes pas (encore) prêts à résoudre.

Cependant, écrire le code pour que l'entreprise puisse le déployer sur son réseau local serait bien.

Eh bien, la conversion PDF nécessite un gros téléchargement (bien que la majeure partie de sa taille soit de la documentation) et il est peu probable que chaque utilisateur d'Ipython ait ce package installé. Par conséquent, j'ai pensé que réduire l'effort nécessaire pour commencer à utiliser cette fonctionnalité serait un ajout intéressant. Quelles autres conversions avez-vous en tête ?

En fait, je ne serais pas très heureux d'obtenir un service de conversion complet car un tel projet nécessite beaucoup d'efforts qui nuirait à l'amélioration du cahier et la loi des rendements décroissants s'applique rapidement dans ce cas.

En ce qui concerne les fuites de données utilisateur, je pensais que la seule chose requise pour que cela fonctionne est le fichier pynb. Quel type d'informations utilisateur est nécessaire pour la conversion ? Dans tous les cas, un serveur fournissant des PDF n'est pas censé enregistrer les informations de l'utilisateur.

Les données utilisateur incluent le contenu du bloc-notes lui-même. Et bien que le serveur ne soit pas censé enregistrer ces informations, vous ne savez pas quand vous lui envoyez une requête HTTP ce qu'il va en faire.

Pour le moment, je n'ai aucun problème à dire que vous devez installer Latex pour convertir les cahiers en PDF. Les dépendances ne sont pas quelque chose que nous devons éviter.

Pour le moment, je n'ai aucun problème à dire que vous devez installer Latex pour convertir les cahiers en PDF. Les dépendances ne sont pas quelque chose que nous devons éviter.

Je suis d'accord avec @takluyver , peut-être que quelque chose de plus élaboré pourra être développé plus tard, mais pour l'instant, je vais bien demander aux gens d'installer Latex s'ils veulent utiliser ces fonctionnalités...

L'erreur de latex s'est affichée dans le terminal. Dans la page d'erreur HTML, le seul message que j'ai reçu était nbconvert failed : la création du PDF a échoué. Qu'en est-il de l'ajout du traceback à la page d'erreur HTML ?

Cela me semble une bonne idée, qu'est-ce que tout le monde en pense?

Cela me semble une bonne idée, qu'est-ce que tout le monde en pense?

Cela me semble bien...

Qu'en est-il de l'ajout du traceback à la page d'erreur HTML ?

Cela peut avoir du sens, bien que les erreurs LaTeX soient parmi les erreurs les plus longues et les moins informatives qui existent. Nous devons nous assurer que nous gérons correctement des milliers de lignes de sortie d'erreur, alors qu'en général, au plus une de ces lignes contient des informations significatives.

Quelles autres conversions avez-vous en tête

Tout. Si nous pouvons PDF, pourquoi pas HTML, RST, Markdown et même Just Latex.
Installer Pandoc n'est pas facile...

En ce qui concerne les fuites de données utilisateur, je pensais que la seule chose requise pour que cela fonctionne est le fichier pynb. Quel type d'informations utilisateur est nécessaire pour la conversion ? Dans tous les cas, un serveur fournissant des PDF n'est pas censé enregistrer les informations de l'utilisateur.

Si vous avez des fichiers annexes, comme des images liées, vous devrez peut-être également les télécharger.
Même si le serveur n'est pas censé garder les choses, si nous nous faisons pirater, cela pourrait,
ou il pourrait même vous donner un PDF infecté.

Il est difficile d'imaginer ce qui peut être fait avec les données (ou leur absence), voir [cet exemple])http://mashable.com/2015/01/28/redditor-muslim-cab-drivers/) où le modèle de les données manquantes ont permis de deviner la religion du chauffeur de taxi de NY.

Bien que nous soyons d'accord sur le fait que le service serait agréable, nous ne l'activerons probablement pas par défaut.
Nous avons également besoin du temps des développeurs et des développeurs pour maintenir le service en ligne + être protégés par la loi,
donc à moins que quelqu'un ne vienne le faire, ou que nous obtenions un financement pour cela, il y a seulement une petite chance que cela se produise.

Pour le message d'erreur, cela aurait du sens.

Je suis d'accord que, pour le moment, il vaut mieux décrire les dépendances et améliorer le message d'erreur.

Est-il possible de détecter si LaTeX est installé avant d'essayer de convertir le fichier ipynb ? Si cela est possible, Ipython serait en mesure de donner un message d'erreur utile au lieu de générer une erreur sur un fichier très spécifique. Dans mon cas, je pensais qu'un autre paquet avait installé une distribution LaTeX car pdflatex semblait fonctionner. Je suppose que la plupart des erreurs rencontrées par les utilisateurs d'Ipython, dans ce contexte, sont dues au fait de ne pas avoir installé de distribution LaTeX. Par conséquent, une détection précoce de ce problème profiterait à la plupart des utilisateurs.

Peut-être qu'un compromis raisonnable est d'ajouter le retraçage à la page d'erreur HTML mais de ne pas l'afficher par défaut (car il est trop long et non informatif.) Après avoir cliqué sur un texte tel que "Vous voulez voir le retraçage ?", le retraçage être montré. Cependant, si la détection précoce d'une dépendance manquante est possible, le message principal de la page d'erreur doit le transmettre.

@takluyver

Les données utilisateur incluent le contenu du bloc-notes lui-même. Et bien que le serveur ne soit pas censé enregistrer ces informations, vous ne savez pas quand vous lui envoyez une requête HTTP ce qu'il va en faire.

Mais voulez-vous dire fouiner comme @Carreau l'a suggéré ? Sinon, nous savons ce que le serveur fera de cette requête.

@Carreau

Tout. Si nous pouvons PDF, pourquoi pas HTML, RST, Markdown et même Just Latex.
Installer Pandoc n'est pas facile...

Je ne pense pas que HTML ou RST soient nécessaires dans un service de conversion car ils sont déjà disponibles dans le bloc-notes lui-même. Les conversions Markdown et LaTeX peuvent cependant être utiles.

Si le serveur est piraté, tout est possible. Cependant, la probabilité d'être piraté est suffisamment faible pour ne pas empêcher les gens de lancer un service. Au lieu de cela, des mesures de sécurité doivent être prises (installer rapidement les mises à jour de sécurité, ouvrir uniquement les ports requis, activer un pare-feu, installer uniquement les applications nécessaires, SSL, etc.)

Je pense que nous vérifions déjà si la commande pdflatex est disponible. Je doute qu'il existe un bon moyen de vérifier si tous les fichiers qui auront besoin de traiter le Latex sont présents, à part l'exécuter.

Je doute qu'il existe un bon moyen de vérifier si tous les fichiers qui auront besoin de traiter le Latex sont présents, à part l'exécuter.

Je seconde ce doute.

Je ne pense pas que HTML ou RST soient nécessaires dans un service de conversion car ils sont déjà disponibles dans le bloc-notes lui-même. Les conversions Markdown et LaTeX peuvent cependant être utiles.

Ne sous-estimez pas les choses que fait nbconvert/nbviewer :-) si vous avez SVG, il peut même $ inkscape de SVG à PNG. Vous n'avez pas encore touché ça.

Si le serveur est piraté, tout est possible. Cependant, la probabilité d'être piraté est suffisamment faible pour ne pas empêcher les gens de lancer un service. Au lieu de cela, des mesures de sécurité doivent être prises (installer rapidement les mises à jour de sécurité, ouvrir uniquement les ports requis, activer un pare-feu, installer uniquement les applications nécessaires, SSL, etc.)

C'est beaucoup de travail, et ne sous-estimez pas le grand pare-feu et la NSA.
Mais de toute façon, il existe de nombreux labos où la connexion à distance aux services Internet est hors de question.
aussi, mais je pense que vous sous-estimez fortement la quantité de travail dans "etc" et la "probabilité de se faire pirater".

Si des gens comme, disons Peter Norvig, sont connus pour utiliser des ordinateurs portables, puis utiliser potentiellement le service, il sera alors avec 100% de chances d'être la cible d'attaques.

Dans les distributions Debian, cela fonctionne :

 ➜  ~  dpkg -s sudo | grep "install ok installed"
 Status: install ok installed
 ➜  ~  dpkg -s texlive | grep "install ok installed"
 Status: install ok installed
 ➜  ~  dpkg -s texlive-latex-extra | grep "install ok installed"

J'ai désinstallé texlive-latex-extra avant d'exécuter la dernière commande. Je n'ai pas la moindre idée de Windows, cependant.

@Carreau Non, je voulais dire que nbconvert effectue déjà de nombreuses conversions utiles, nous n'avons donc pas besoin d'un service de conversion implémentant à nouveau la même chose.

Concernant les problèmes de sécurité, c'est beaucoup de travail mais c'est presque du travail mécanique. Contre les agences de renseignement, vous ne pouvez rien faire. La NSA interrompt désormais régulièrement les connexions cryptées SSL. La quantité de travail dans "etc" dépend des exigences particulières du site, mais dans ce cas, du fait de la simplicité du service, les besoins supplémentaires ne sont pas trop exigeants.

Google est régulièrement la cible d'espionnage industriel, et si une agence de renseignement étrangère voulait voler des informations, il y a presque 0% de chance que le vecteur d'attaque choisi soit un service ipynb->pdf. Ils savent que les personnes averties en technologie ne téléchargeront pas d'informations sensibles d'une manière aussi négligente. De plus, s'ils voulaient obtenir les données de Norvig, ils infecteraient son ordinateur portable et toute mesure de sécurité supplémentaire serait alors inutile.

J'ai installé à la fois latex et pdflatex, mais sur RHEL 6 et 7, c'est toujours sur adjustbox.sty que la conversion trébuche. Doit-il être ce fichier de style qui ne semble pas être celui par défaut ?

L'exportation PDF est désespérément difficile sur Windows 7 (ou n'importe quel Windows d'ailleurs).

Voici le processus :

1. Mistune manquant - l'installation de pip est cassée, mais heureusement, l'installation de conda est devenue disponible aujourd'hui.
2. Pandoc manquant. Pas du tout disponible dans pip ou conda, alors recherchez sur le Web un programme d'installation Windows de 18 Mo.
3. pdflatex manquant. Où trouve-t-on cela pour Windows ? Il y a quelque chose appelé MiKTeX qui est une installation de 163 Mo, et il n'est pas clair qu'il fera cette exportation PDF.

Jusqu'à présent, il s'agit d'une installation et d'une désinstallation de pip cassées, d'une installation réussie de conda et de 2 téléchargements massifs de tiers aléatoires avant de nous rapprocher.

Je ne sais tout simplement pas comment quelqu'un pourrait maintenir cela sur une charge de machines d'utilisateurs, et il s'agit simplement de produire un fichier au format PDF. De nombreux autres progiciels gèrent l'exportation PDF sans aucune dépendance.
N'y a-t-il pas un meilleur moyen ?

@blokeley J'espère que vous n'avez dû vous en
Si vous avez un meilleur moyen qui fonctionne, alors ce serait génial.

Je pense que nous pourrions résoudre ce problème de deux manières :

1. Essayez de vérifier que latex et ses dépendances sont installés.
2. Écrivez un modèle PDF et un exportateur, qui sort directement au format PDF.

Je pense que (2) est en fait plus facile que (1). Je ne sais pas si c'est le genre de chose pour laquelle l'équipe est intéressée à allouer de la main-d'œuvre... J'ai eu un modèle PDF direct qui fonctionnait dans le passé, c'était très basique cependant.

Je pense qu'il n'y a que deux manières raisonnables pour nous d'exporter PDF :

• HTML via aperçu avant impression du navigateur -> print-to-pdf
• Latex

Si quelqu'un souhaite écrire un autre exportateur PDF en utilisant différents outils, il serait le bienvenu en tant qu'exportateur tiers personnalisé, mais probablement pas en tant que nouvel exportateur livré avec nbconvert lui-même.

Peut-être que quelque chose d'aussi simple que de renommer "PDF" en "Latex PDF" et qu'un message d'erreur plus détaillé suffirait. À l'heure actuelle, le message HTML est « 500 : Erreur de serveur interne » sans que rien n'indique qu'il s'agit d'un problème de dépendance (sauf dans la console du serveur, à laquelle l'utilisateur peut ne pas avoir accès).

Peut-être quelque chose d'aussi simple que de renommer "PDF" en "Latex PDF"

déjà fait dans #7951

Le message d'erreur devrait encore être amélioré, cependant.

J'adorerais écrire l'exportateur PDF mais mon temps est quelque peu limité (je ne vous ennuierai pas avec les excuses). S'il ne se passe rien d'autre, j'essaierai d'écrire un prototype cet été.

Ou, de manière plus réaliste, pourrait-il s'agir d'un projet Google Summer of Code ? Je serais heureux de donner un peu d'argent.

IPython ne fait pas de GSoC - Fernando est convaincu que cela ne vaut pas la peine de prendre le temps de guider les gens.

J'ai des problèmes similaires à blokely pour Windows 7.
Je suis derrière un pare-feu dans mon travail et j'ai besoin d'une autorisation spéciale pour installer un logiciel. Un certain nombre de mes collègues et moi-même essayons la distribution Anaconda. nous espérions que ce serait la seule chose que nous aurions à installer.
Je suppose que nous avons besoin d'un total de 3 addons, mathjax, pandoc, (ces deux sont documentés dans les instructions d'installation détaillées) et un troisième MiKTeX qui n'est pas dans les instructions d'installation. vous ne le découvrirez pas avant d'aller sur la page pandoc. faire fonctionner correctement le notebook et nbconvert sur Windows derrière un pare-feu n'est pas facile !

Quelqu'un pourrait écrire un exportateur PDF nbconvert qui soit directement au format PDF à l'aide de reportlab (qui est désormais installable par pip sur Windows), soit qui produit du HTML, puis le convertit en PDF à l'aide d'un outil tel que wkhtmltopdf ou weasyprint . Si tout s'est bien passé, nous pouvons même l'inclure dans nbconvert. Mais je ne pense pas que ce soit une priorité suffisamment élevée pour que nous y travaillions nous-mêmes de si tôt.

@ Drafter250, vous aurez peut-être également besoin d'Inkscape si vous souhaitez utiliser des tracés matplotlib vectorisés (svg) convertis en pdf.
@takluyver J'ai également

Il y a certainement beaucoup de dépendances ici. Pour nbconvert. Latex, sphinx, jinja, miktex, inkscape. etc. j'ai du mal à garder tout ça droit. Existe-t-il des ressources pour décrire comment tous ces éléments interagissent pour donner à nbconvert toutes les fonctionnalités. Aussi peut-être qu'il serait préférable de désactiver diverses commandes pour lesquelles les dépendances n'ont pas pu être résolues

Pour le moment, je n'ai aucun problème à dire que vous devez installer Latex pour convertir les cahiers en PDF. Les dépendances ne sont pas quelque chose que nous devons éviter.

Le problème est qu'actuellement, toutes (la plupart ?) des distributions RHEL-ish sont bloquées pour la conversion. Le code latex généré repose sur adjustbox.sty et il n'y a pas de package disponible qui fournit ce fichier (affecte : RHEL6, RHEL7, EPEL6, EPEL7, Scientific et soi-disant CentOS aussi)

Cela semble être la demande d'extraction incriminée concernant l'erreur d'origine de l'OP :

• #3578 Utilisez Adjustbox pour spécifier la taille de la figure dans nbconvert -> latex
  490

Il pourrait être intéressant d'expérimenter avec jsPDF .

@serverhorror il existe déjà un rapport de bogue pour Adjustbox. Donc j'espère qu'il y aura une solution bientôt.
Alternativement, il ne devrait pas être trop difficile d'installer localement Adjustbox.sty, voir les commentaires ici

@jakobgager J'ai vu ça. Malheureusement, RHEL7 (EPEL7) n'est même pas encore sur la feuille de route (waaaaayyyy hors de mon contrôle).

Pour le moment, je vais simplement utiliser une version corrigée localement qui revient essentiellement à #3578

+1

Si vous utilisez (dans ubuntu 15.04) :

apt-get install --no-install-recommends texlive-latex-extra texlive-fonts-recommended

Vous réduisez la taille du téléchargement à 24 Mo (au lieu de 606 Mo). Il ne télécharge pas certaines documentations (environ 300 Mo)

Merci d'être intervenus à ce sujet, tout le monde, je passe en revue et nettoie les anciens problèmes qui ont été résolus, et celui-ci est mûr pour la clôture.

Il y a eu beaucoup de bonnes discussions sur ce sujet, mais pour résumer :

1. Un message plus détaillé s'affiche désormais lorsque la conversion échoue. Dans la version 4.2.2 du notebook, la suppression du fichier .sty en question sur ma machine génère un message d'erreur qui ressemble à ceci :

2. nous n'avons pas l'intention de fournir la conversion de cahiers en PDF en tant que service Web
3. si un tiers rend un tel service Web disponible, le téléchargement du notebook intégré est explicite sur l'utilisation de LaTeX depuis #7951 - et ressemble à ceci :

4. Quant à la taille des dépendances requises, une solution de contournement a été proposée par @iuridiniz juste au dessus de ce commentaire.

Toute discussion future autour de ces problèmes et de problèmes connexes devrait probablement avoir lieu sur https://github.com/jupyter/nbconvert .

Bon piratage ! :nœud papillon: