TL;DR: pyright, extension opensource pour VSCodium ajoutant le support de python.
Y'a longtemps, j'avais parlé de VSCode en ces termes :
Pis un jour j'ai appris que Microsoft avait sorti VSCode. Je me suis dit lol, et parce que je suis une moule de mauvaise foi, j'ai refusé de l'essayer par principe parce que Microsoft bouhcaca, toussa toussa.
Pis un jour, Sam et Max on fait un article dessus. Suite à ma lecture, j'ai décidé de lui laisser sa chance. Et depuis, c'est mon éditeur de développement par défaut.
3.5 ans plus tard, janvier 2022 2023.
Je fais principalement du développement web python containerisé dans les nuages. J'ai du terraform pour gérer l'infra. Je fais aussi aussi du C et des makefile pour le firmware d'un objet connecté (il est possible que je fasse un usage trèèèèèèèèèèèèès créatif de docker pour compiler les différentes partie du firmware en parallèles dans des containeurs dont j'orchestre le lancement avec des makefiles générés par mon ./configure.py maison. Ça parait moche, mais ça permet d'éliminer les problèmes de maispourtantchezmoiçabuild©, ça marche n'importe où il y a docker + make, soit virtuellement partout, et ça fait un excellent cache de compilation).
VScode continue de satisfaire à mes besoins. Il est simple, léger, a plein d'extensions pour l’adapter à mes besoins. Malheureusement, en 2021, Microsoft a décidé d'arrêté le développement de l'extension opensource ajoutant le support de python pour le remplacer par une extension propriétaire, pylance. Par flemme et inertie, au taf, je suis passé sur l'extension proprio parce qu'elle est proposée par défaut >_<. Il faut dire qu'elle fait excellemment bien le taf et que ma flemme est manifestement supérieure à mes convictions libristes.
Mais à la maison, j'utilise le fork libre, VScodium qui n'inclut pas les trucs caca de Microsoft ou les trucs propriétaires. Et du coup, pas pylance. À l'époque, j'avais pas trouvé/réussi à faire marcher/aimer une extension supportant python, et du coup me limitait au fonctionnalités de base de l'éditeur : coloration syntaxique et auto-complétion sur les symboles présent dans le fichier. C'est, hum, frugal. C'est là que l'on se rend compte que les outils intelligents font gagner beaucoup de temps et diminuent la charge mentale sur les petits trucs à la cons (auto-formatage, linting, auto-imports, refacto, …). Mais d'un autre côté, ça me force à mieux écrire mon code, faire davantage attention à ce que je fais, et aussi passer beauuuuuucoup plus de temps dans la doc pour retrouver le nom de cette fonction à la c** et du coup découvrir des trucs que j'avais ratés parce que ça fait longtemps que j'étais pas allé voir la doc pour les trucs de base :D.
Là, j'ai profité de la réinstallation de mes laptops sous Arch Linux (NixOS c'est révélé être beaucoup trop ennuyeux pour moi. ça marche excellemment bien mais c'est pas fun :( ) pour voir ce qu'il se proposé en terme d'extension python pour VSCodium.
C'est ainsi que je suis tombé sur pyright. C'est toujours du Microsoft, c'est pour l'instant opensource et maintenu, et j'ai enfin une bonne auto-complétion <3.
J'ai quand même peur qu'à terme Microsoft délaisse VSCode, le propriétarisme ou le rende payant, et que l'écosystème gravitant autour en pâtisse. Tout ça me donne envie de commencer à chercher des alternatives au cas où les choses tournent mal.
Aurais-tu des recommandations d'EDI (Éditeur De texte Intelligent©, à ne pas confondre avec l'IDE) ?
Mes besoins :
- taper du texte, beaucoup, dans pleins de langages et formats différents. Pour ça, il doit pouvoir m'assister avec les fonctionnalités suivantes :
- coloration syntaxique, avec un moyen simple pour utiliser ce thème là
- auto-complétion intelligente (retrouver les méthodes des objets, assister sur les imports, …)
- linting lors de l’édition ou de la sauvegarde
- formatage lors de la sauvegarde
- et ce pour les langages et technos suivants :
- python (gros plus si il arrive à être intelligent avec django, et ses templates et spécificités)
- dockerfile
- terraform
- c, avec des includes à des endroits totalement improbables dont notamment monté depuis des containers dockers (c** de lib pour les PRU TI disponible uniquement sous linux mais que malheureusement on bosse sur des macbook, et que c'est une solution finalement assez simple pour que ça marche facilement chez tout le monde sans abîmer les gonades)
- makefile. Vous ne pouvez pas savoir à quel point j'aime torturer cet outil pour lui faire faire des trucs totalement inattendus <3. Le truc, c'est que j'indente avec 4 espaces et que lui veut absolument des indentions. Certains éditeurs peuvent être désagréablement compliqués à configurer pour gérer ce cas
- javascript, autres joyeusetés du web tel que css et html
- les formats de données habituels tels que json, xml ou yaml
- csv. De gros csv de plusieurs centaine de milliers de lignes
- tout ça n'a pas besoin d'être fourni par défaut, mais doit pouvoir facilement s'installer/se configurer
- pouvoir partitionner et manipuler facilement l'espace d'édition pour avoir plusieurs fichiers ouvert en même temps
- sobre. Si ce n'est pas du code ou une arborescence de fichier, ça n'a pas besoin d'être visible à l'écran si je ne lui demande pas
- libre / opensource
- graphique. j'aime bien neovim, mais j'arrive pas à l'utiliser sur les trucs un peu conséquent. flemme de gravir la courbe d'apprentissage et de consacrer le temps nécessaire à être réellement productif avec
- disponible facilement sur Mac et Arch
- léger et s'adapte à mes besoins plutôt que l'inverse. PyCharm marche plutôt bien, mais qu'est-ce qu'il est lourd et contraignant :(
- dont le développement et l'écosystème sont à priori pérennes pour les prochaines années histoire de ne pas venir te ré-embêter trop vite avec mes demandes à la con
- ne demande pas 3 mains à 7 doigts (désolé emacs)
Je n'ai pas de besoin particulier en terme d’assistance au build, à l’exécution ou au debug; préférant utiliser des terminaux pour ces choses là.
En tapant cette liste, je me rend compte que je suis bien exigeant. Mais que veux-tu, il faut ce qu'il faut pour bien travailler :)
Désolé pour ce pavé. À la base je voulais juste poster un lien, mais je me suis un peu emporté >_<
# Un peu hors sujet : makefile et docker
Posté par Sébastien Maccagnoni (site web personnel) . Évalué à 3.
Pas une réponse à ton interrogation, mais en lisant ton message et ta parenthèse sur docker, je n’ai pu m’empêcher de penser que Dagger ou Earthly pourraient t’intéresser…
[^] # Re: Un peu hors sujet : makefile et docker
Posté par jtremesay (site web personnel) . Évalué à 2.
Pour l'instant, je vais garder mon bricolage qui marche, mais je garde les liens sous le coude pour un réfacto futur.
[^] # Re: Un peu hors sujet : makefile et docker
Posté par abriotde . Évalué à 1.
Je ne conaissais pas et je trouve ça top. Dagger parrait plus simple dans son approche (je n'ai pas dis son implémentation) mais earthly me parrait bien plus puissant.
[^] # Re: Un peu hors sujet : makefile et docker
Posté par jtremesay (site web personnel) . Évalué à 2.
c’est marrant, j’ai eu l’impression inverse.
Earthly me parait plus simple et plus limité dans son expressivité, et je pense que j’aurais encore besoin de mon
./configure.pymaison pour générer les earthfile.Alors que dagger couplé à devrait me permettre d’exprimer tous ce que je veux mais au prix d’un code plus complexe
[^] # Re: Un peu hors sujet : makefile et docker
Posté par Sébastien Maccagnoni (site web personnel) . Évalué à 1.
Je pas comprendre : le Earthfile tu le fais une fois pour toutes et il décrit tout ce dont tu as besoin pour tes builds.
Mais en fait je ne comprends pas pourquoi tu as un
./configure.pypour faire des makefiles, parce que là aussi ton makefile est censé ne pas bouger (ou à la marge)…[^] # Re: Un peu hors sujet : makefile et docker
Posté par Sébastien Maccagnoni (site web personnel) . Évalué à 1.
Earthly est bien plus simple à mettre en œuvre.
Dagger est bien plus flexible, mais au prix de beaucoup plus de gymnastique intellectuelle.
# Kate
Posté par raphj . Évalué à 10. Dernière modification le 26 janvier 2023 à 01:33.
Tiens, cette question me dit quelque chose, je crois qu'elle est sortie il n'y a pas trop trop longtemps ici sur LinuxFr :-)
Kate a tout ça (mais j'ai pas tout testé, notamment les trucs de reformatage / formatage à la saisie, je n'en ai jamais ressentis le besoin au delà de "indenter après une accolade ou des deux-points et cesser à la fermeture du bloc").
Y compris les fonctionnalités IDEesques grâce à sa prise en charge de LSP, mais ce n'est pas parfait, faut mettre un peu les mains dans le cambouis pour faire marcher ça (il faut aller chercher les serveurs LSP des différents langages que tu utilises toi-même et adapter la configuration de Kate en conséquence). Je confirme que ça marche bien pour JavaScript, Java, PHP, C et C++, je ne fais pas trop de Python en ce moment mais je suppose que ça se fait bien aussi.
J'ai utiliser VSCodium un temps mais il n'y a rien à faire, ma mémoire musculaire (bien ancrée depuis 2008…) et la légèreté de Kate me font revenir à cet éditeur que je trouve par ailleurs très plaisant, en plus des questions d'open core et côté fourre-tout d'extensions qui me plaisent moyen. Je l'ouvre à l'occasion pour des besoins spécifiques, mais ce n'est pas arrivé depuis près d'un an.
Finalement je fais vraiment beaucoup de chose depuis le terminal…
[^] # Re: Kate
Posté par jtremesay (site web personnel) . Évalué à 3.
J'ai pas vu / j'ai oublié :-/
Il faudra que j'aile voir ça. Ça fait des années que je ne l'ai pas lancé !
[^] # Re: Kate
Posté par jtremesay (site web personnel) . Évalué à 1.
Il est pas disponible dans les dépots homebrew pour mac :(
[^] # Re: Kate
Posté par raphj . Évalué à 2.
Pas de problème :-)
Il y a des exécutables fournis là apparemment : https://kate-editor.org/get-it/
Je crois l'avoir lancé une fois sur un Mac mais je ne suis plus très sûr. Je sais que KDE travaille à faire fonctionner leurs softs sur Mac.
[^] # Re: Kate
Posté par Pinaraf . Évalué à 2.
Y'a un ".dmg", ça marche plus sur MacOS ?
https://binary-factory.kde.org/view/MacOS/job/Kate_Release_macos/
[^] # Re: Kate
Posté par jtremesay (site web personnel) . Évalué à 1.
aucune idée, je n’ai jamais utilisé ces choses là. Je préfère utiliser un gestionnaire de paquet qui me permet de gérer facilement l’ensemble que de gérer tout ça à la main.
[^] # Re: Kate
Posté par Glandos . Évalué à 3.
Ouais, mais du coup… c'est pas fun !
# Include c
Posté par barmic 🦦 . Évalué à 3. Dernière modification le 26 janvier 2023 à 06:09.
Histoire de réduire potentiellement les contraintes sur l'éditeur, ça peut pas se résoudre avec les ctags ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Include c
Posté par jtremesay (site web personnel) . Évalué à 2.
Si, très probablement
# Vim
Posté par Goffi (site web personnel, Mastodon) . Évalué à 6. Dernière modification le 26 janvier 2023 à 10:00.
Pour info PyRight fonctionne très bien avec (neo)vim via Conquer of Completion/CoC :
https://github.com/neoclide/coc.nvim
https://github.com/fannheyward/coc-pyright
Et l'auteur de coc-pyright est réactif : je lui ai demandé de faire une exception pour ne pas avoir d'erreur quand le double
dashunderscore__est utilisé pour ignorer des arguments, quand le simple est utilisé pour gettext, et il l'a fait rapidement (du coup ça ne doit pas être dans pyright avec VSCodium).[^] # Re: Vim
Posté par Goffi (site web personnel, Mastodon) . Évalué à 2.
Il fallait bien entendu lire double souligné (underscore) et non dash.
[^] # Re: Vim
Posté par gUI (Mastodon) . Évalué à 3.
Corrigé
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Vim
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 3.
Oui, vim est très bon, je l'utilise encore comme IDE avec coc pour gérer LSP et vimspector pour le debugger avec DAP:
https://linuxfr.org/users/trim/journaux/transformer-vim-en-ide-avec-lsp-et-dap
Il n'y a pas besoin de 21 doigts, mais il y a quand même pas mal de raccourcis à découvrir et qui sont très pratique (comme les multiples registre pour le copier/coller, les goto avec gd gr…).
Il est aussi utilisable avec la souris :)
[^] # Re: Vim
Posté par oau . Évalué à 3.
Vim c'est bien
[^] # Re: Vim
Posté par Guillaume Denry (site web personnel) . Évalué à -8.
Le problème, c'est d'appeler "éditeur" un logiciel qui ne permet pas d'éditer le fichier ouvert sauf à forcément appuyer sur une touche avant.
[^] # Re: Vim
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 4.
Parce-que vous faites de l’édition de texte informatiquement (pas juste mentalement) sans appuyer sur de touche (ou de dalle) ?
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Vim
Posté par Guillaume Denry (site web personnel) . Évalué à 1.
Si je veux écrire "a", j'ai pas besoin d'écrire "ia", par exemple :)
[^] # Re: Vim
Posté par Psychofox (Mastodon) . Évalué à 5.
Ben ça tombe bien tu n'écris pas ia.
On ne se plaint pas quand on utilise un éditeur comme code/codiumd de devoir utiliser son pointeur de souris pour aller dans la zone de texte ou appuyer n fois sur tab quand on est dans le menu ou un des panneaux latéral. Alors que c'est exactement pareil.
[^] # Re: Vim
Posté par Guillaume Denry (site web personnel) . Évalué à 2.
Code ? Quelle horreur :)
Non je parle d'un éditeur où après l'avoir lancé, tu peux commencer à éditer directement ton fichier. Quelque chose comme……
(ok j'arrête, ça a assez duré)
[^] # Re: Vim
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
Au lieu d'ouvrir des menus tu cherches des combinaisons de touche pour faire la moindre action. Ah non, « éditer » pour toi c'est taper tout le texte en une fois sans erreur …mais ensuite enregistrer et fermer c'est quelle partition il faut jouer ?
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Vim
Posté par Guillaume Denry (site web personnel) . Évalué à 2.
J'ai l'impression que tu trolles là non ?
[^] # Re: Vim
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 1.
Un peu oui :) Mais dans l'esprit « écrire "ia" pour écrire "a" » puis « commencer à éditer directement ton fichier » qui laisse penser que éditer c'est écrire "a" (ou une prose d'une traite, mais pas déplacer des blocs de texte) etc.
Mea Culpa, je n'ai pas vu la dernière ligne …parce-que du coup il n'était pas forcément nécessaire que je réponde et même en le faisant indiquer plus clairement quand on cesse d'être sérieux.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Vim
Posté par Psychofox (Mastodon) . Évalué à 4. Dernière modification le 06 février 2023 à 09:40.
Oui mais avec celui-là il faut utiliser ses pieds sur le clavier en plus de ses mains pour avoir assez de doigts pour les combinaisons de touches. Ce n'est pas très comfortable.
[^] # Re: Vim
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
3 ou 2 pieds ? Ou comme Ganesh/Kali/Shiva/etc., avoir plusieurs bras. Toute façon, sans le clavier qui va bien, c'est un peu n'importe quoi…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# emacs...
Posté par Olivier LEMAIRE (site web personnel) . Évalué à 6.
emacs avec doom
https://github.com/doomemacs/doomemacs
https://docs.doomemacs.org/latest/modules/lang/python/#/description/module-flags
https://github.com/emacs-lsp/lsp-pyright
Franchement, j'utilise emacs depuis au moins 6 ans, après avoir utilisé vim pendant 10 ans et je ne regrette pas du tout mon choix… C'est plus si vrai cette histoire de gymnastique digitale pour utiliser emacs. Une fois que tu connais alt+x, 10 doigts sont largement suffisant.
L'intégration de lsp est vraiment pas mal et tu as du coup ton linter.
Les logiciels de traitement de texte sont à la rédaction ce que la 2CV est à l'automobile, une vieille voiture dont on se souvient avec nostalgie mais technologiquement dépassée
[^] # Re: emacs...
Posté par fredzz (site web personnel) . Évalué à 3.
+1 pour doom emacs
Pour activer pyright, il suffit de cette ligne dans le fichier packages.el
# Emacs
Posté par flagos . Évalué à 6. Dernière modification le 26 janvier 2023 à 09:45.
En vrai, tout ce que tu écris crie pour Emacs.
Bon évidemment je te garantis pas que tous tes points vont passer sans souci sur Emacs comme ton theme, tes histoires d'indentation dans les makefile auxquel je n'ai rien compris et je n'ai aucune envie de m'y intéresser :-).
Bref, il semble que tu cherches un truc comme VSCode, mais sans Microsoft, perenne, sans fioriture, interface customisable. Il me semble que ce que tu cherches, c'est Emacs.
Tu peux essayer de démarrer sur une distribution Emacs pour commencer, ca peut te faire gagner pas mal de temps pour commencer, et si tu es conquis tu pars d'une config from scratch que tu customises.
[^] # Re: Emacs
Posté par jtremesay (site web personnel) . Évalué à 3.
Je sais qu’emacs a tout ce que je demande et même plus, mais jusque là je n’ai pas réussi à l’aimer :-/
Tu as des recommendations ? La seule que je connais est spacemacs.
[^] # Re: Emacs
Posté par flagos . Évalué à 3.
Doom Emacs, spacemacs, Prelude, Graphene, Nano Emacs (peut être pas adapte celui la).
Honnêtement il y en a beaucoup, d'autres que moi seront mieux te conseiller (j'ai commence a l’époque de XEmacs, c'est dire). J'ai tout de meme entendu beaucoup de bien de Doom Emacs, la doc semble être au top: https://docs.doomemacs.org/latest/#/intro
[^] # Re: Emacs
Posté par Lutin . Évalué à 2.
La courbe d'apprentissage pour emacs est encore plus rude que celle pour (neo)vim.
[^] # Re: Emacs
Posté par jtremesay (site web personnel) . Évalué à 3.
Et c’est la raison pour laquelle j’avais préféré apprendre les rudiments de vim que de emacs à l’époque parce que je voulais juste éditer des fichiers de config dans la console.
Mais maintenant que mon usage a évolué, ça pourrait valoir le coup que je me prenne la tête avec.
[^] # Re: Emacs
Posté par Elfir3 . Évalué à 2.
Beaucoup de monde utilise evil-mode qui est une couche qui te permet d'utiliser emacs avec le même paradigme que vim. Spacemacs et doom-emacs l'intègrent par défaut si mes souvenirs sont bons. Je ne peux par contre pas t'en dire plus, n'était pas utilisateur.
[^] # Re: Emacs
Posté par Psychofox (Mastodon) . Évalué à 3.
Le problème de emacs c'est que tu fais tourner un OS dans un OS.
[^] # Re: Emacs
Posté par jtremesay (site web personnel) . Évalué à 4.
C’est pour ça que certains ont décidés de se passer d’OS et de directement faire tourner Emacs
https://github.com/a-schaefers/systemE
[^] # Re: Emacs
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
Ça tombe bien, il bosse sur des conteneurs…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# EDI
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2. Dernière modification le 27 janvier 2023 à 19:01.
Heureusement qu'il y avait la parenthèse …parce-que j'ai d'abord cru qu'on parlait des normes EDI (dont on a reparlé récemment…) Mais du coup, à force d'entendre parler de tpgtahc j'ai eu l'impression que c'est ce que la parenthèse a tenté de nous glisser.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# simple léger rapide…
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
À la première lecture, ça m'avait un peu titillée mais je n'ai pas voulu pinailler vu qu'il s'agissait d'un cas personnel.
Mais je vois à l'instant que tout le monde n'est pas de cet avis malgré leur grand amour. S'il y en a qui peuvent l'aider, ne pas hésiter.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: simple léger rapide…
Posté par Psychofox (Mastodon) . Évalué à 3.
vscode est plutôt à l'opposé de ce que je considére léger.
Je n'ai jamais rencontré une appli electron légère en fait.
[^] # Re: simple léger rapide…
Posté par flagos . Évalué à 2.
1 password ?
[^] # Re: simple léger rapide…
Posté par Psychofox (Mastodon) . Évalué à 5. Dernière modification le 28 janvier 2023 à 21:38.
Je ne l'ai pas essayée.
Peut-être que tu trouves que ton pc n'a aucun mal à la faire tourner. Mais si tu compares ses empreintes disques, cpu et mémoire comparée à une appli similaire utilisant un toolkit natif de ton OS, qu'en et-il réellement?
Exemple Balena Etcher ne fait pas ramer ma becane pour mettre une image sur une sdcard ou un disque usb. Mais son empreinte est complètement démesurée comparé à dd ou le gazillion de gui qui existent pour dd et faire tourner ça dans electron n'apporte absolument rien en terme de service rendu.
[^] # Re: simple léger rapide…
Posté par flagos . Évalué à 2.
Je connaissais pas Balena Etcher. Je suis d'accord que le gain n'est pas évident si il s'agit d'un sélecteur de fichier + un appel a dd.
Dans le cas de 1p, c'est pas evident a dire, le process ne stop pas vraiment et il y en a plusieurs qui tourne. Lorsqu'on ouvre une nouvelle fenetre de l'app, on tape 50MB de ram et le cpu reste a moins de 1% une fois l'app stabilisée. C'est franchement honnête je trouve. J'imagine que derrière ce choix il y aussi la volonté d’éviter que le code soit différent par plateforme, pour auditer le code source ca doit faciliter les choses.
Mais je suis d'accord que c'est un peu l'exception dans un ocean d'horreurs, 1p ont juste bien bosse sur leur app. Ca veut dire que si on maîtrise le framework il est possible de faire une app en electron qui ne soit pas une usine a gaz. Ce n'est peut etre juste le framework le problème…
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.