Linux? - Page 180

squalyl (./5369) :
le package que je compile utilise deja virtualenv, c'est cool ce truc.
un makefile fait ce que tu decris (que j'ai decouvert tout seul a la dure ) et quelques trucs de plus.

il s'agit de 'elffile', un parseur de fichier elf, qui a ete laisse tombe par son auteur.
j'ai fait un fork, corrige plusieurs bugs, et vais tenter de le faire accepter par pypi.

https://github.com/slorquet/elffile2

il faudrait que je contacte l'auteur, mais il repond pas aux bugs reports, ca part mal ^^

si tu dois faire un truc compatible Python 2 et 3, utilise six, c'est de loin la solution la plus simple ^^

petite anecdote du soir : je décide d'utiliser "palimpsest" pour gérer une grappe RAID.

le soft est "préinstallé" sur ma distrib, cool !

par contre au moment de créer le volume, ko. Ouais, mdadm (la ligne de commande correspondante) n'est pas installée

six: deux fois trois? #tricouic#

squalyl (./5373) :
six: deux fois trois? #tricouic#

Une petite lib qui permet d'avoir assez facilement un même code qui soit compatible 2 et 3. Pour peu que ton IDE te signale les incompatibilités avec les versions choisies, ça va assez vite.

Quand même, cette histoire de Python 2 et 3 incompatibles mais-on-veut-continuer-à-faire-des-trucs-qui-marchent-avec-les-deux c'est un sacré bordel. Je me souviens qu'on avait beaucoup critiqué PHP et les changements fondamentaux qui avaient été décidés entre 4 et 5, mais au moins on a pas eu à se trainer des programmes compatibles dans les deux sens pendant des années... :/

squalyl (./5367) :
mais je m'interesse a la construction d'un egg qui doit etre teste avec
2.6 2.7
3.0 3.1 3.2
donc ca va un peu au dela du besoin standard

On n'installe pas des jeux de version de développement avec les outils de gestion des paquets de la distrib.
Le bon outil pour ça, c'est pythonz.

VERSIONS="2.6 2.7 3.0 3.1 3.2"
sudo apt-get install build-essential zlib1g-dev libbz2-dev libssl-dev libreadline-dev libncurses5-dev libsqlite3-dev libgdbm-dev libdb-dev libexpat-dev libpcap-dev liblzma-dev libpcre3-dev python-pip
sudo pip install pythonz
mkdir envs
for i in $VERSIONS; do
  pythonz install $i
  virtualenv -p $(pythonz locate $i) envs/python$i
done

Puis-je te recommander tox pour ton intégration ?

Zeph (./5375) :
Quand même, cette histoire de Python 2 et 3 incompatibles mais-on-veut-continuer-à-faire-des-trucs-qui-marchent-avec-les-deux c'est un sacré bordel. Je me souviens qu'on avait beaucoup critiqué PHP et les changements fondamentaux qui avaient été décidés entre 4 et 5, mais au moins on a pas eu à se trainer des programmes compatibles dans les deux sens pendant des années... :/

La compatibilité est juste une possibilité offerte, elle n'est pas obligatoire. Tout ce que ça dit, c'est : « si tu le souhaites, tu peux faire un seul programme qui fonctionne à la fois sur python 2 et 3 - pour cela, il suffit de ne pas utiliser telle et telle fonctionnalité ».

Je n'y vois pas de mal. Au moins, pour les libs qui veulent rester disponibles sur les deux versions, ça évite de devoir maintenir deux bases de code séparées pendant des années. Pour les autres programmes, ben… osef.

merci, je vais regarder pythonz.

Argh, une installation via curl

Tu as un probleme avec curl?

Pour des outils de développement c'est pas choquant. J'installe certaines de mes libs en git clone, c'est dire. Quand tu as besoin de faire des tests de régression sur une version très précise qui n'est pas packagée, tu n'as pas forcément le choix.
Pour éviter le sudo, tu peux simplement activer un virtualenv avant de lancer les quelques commandes du ./5376, et pythonz se mettra dedans.

Sinon, tu peux aussi déléguer toute l'installation et les environnements à travis-ci si tu veux. C'est ce que je fais pour django-hvad. Ça permet de créer toute une matrice d'environnements - jette un œil à la liste des configurations en bas de page.
Si par hasard tu utilises github, l'intégration avec travis est excellente, en gros ça lance le jeu de tests à chaque commit et ça indique si le commit passe les tests ou pas directement dans github. Il existe des outils similaires sur la plupart des autres hébergeurs de code, et sinon tu peux faire pareil sur ton propre serveur en utilisant tox et des git hooks.

Sous Mac, homebrew fonctionne avec un repo github aussi (bon après tu ne le sais pas forcément puisque tu tapes des trucs du genre "brew install subversion-1.8")

vous êtes des malades, j'ai aucune intention d'utiliser des outils aussi compliqués

portage aussi peux utiliser git

./5377 : je pense justement que cette apparente presque-compatibilité a fait croire qu'on pouvait facilement utiliser Python 2 et 3 en même temps, et du même coup considérablement ralenti la pénétration de Python 3 (pas besoin de mettre à jour, puisque la majorité des programmes continuent à tourner avec Python 2). C'est un breaking change, et ne pas tenter de le dissimuler aurait pu éviter de faire autant traîner la migration.

Godzil (./5380) :
Tu as un probleme avec curl?

Oui. C'est le bordel quand ta machine n'est pas connectée à internet

Zeph (./5385) :
./5377 : je pense justement que cette apparente presque-compatibilité a fait croire qu'on pouvait facilement utiliser Python 2 et 3 en même temps, et du même coup considérablement ralenti la pénétration de Python 3 (pas besoin de mettre à jour, puisque la majorité des programmes continuent à tourner avec Python 2). C'est un breaking change, et ne pas tenter de le dissimuler aurait pu éviter de faire autant traîner la migration.

Ça a clairement ralenti la migration, on est d'accord.

Mais faire un truc totalement incompatible aurait totalement pu tuer Python comme Perl 6 a tué Perl (sérieusement, qui fait encore du Perl à l'heure actuelle ?). Ok, ça aura pris 10 ans, mais au moins la popularité de Python continue à augmenter. À l'heure actuelle, quasiment tous les développements sont compatibles Python 3.

(sérieusement, qui fait encore du Perl à l'heure actuelle ?)

Pour les déploiements à grande échelle, il a en effet largement été remplacé par le Python, lequel a également grignoté sur Java pour l'apprentissage.

Perl reste le principal langage de script de plusieurs de mes collègues et moi, mais nous sommes loin de faire des scripts tous les jours.

Oui, c'est sûr, ceux qui ne connaissent que Perl continuent à en faire mais à part ça…

Perl est mort parce que c'est un langage de merde avec une syntaxe gerbante, c'est une mort largement méritée, rien à voir avec la version 6

On peut facilement faire des choses horribles en Perl (et en PHP, un de ses plus proches dérivés), mais ce n'est pas une obligation

Franchement, j'ai regardé 2-3 fois les scripts perls vestigiaux qu'on a au boulot (le but étant de s'en débarasser), et c'est quand même parfois assez affolant
Genre le coup de la valeur de retour d'un exécutable externe qui est décalée de 8 bits à gauche…
Comme je n'ai jamais vraiment fait de perl, je ne permettrai pas de juger de la syntaxe ou autre, mais bon, rien que les noms de pseudo-variables crpytiques, ça me donne pas franchement envie

Le Perl est quand même connu pour être un langage en write-only

Apparemment, c'est génial pour faire des manipulations de chaines ou de fichiers (yen a eu de postés ici meme des scripts perl), c'est d'une imbitabilité absolument splendide, c'est le seul souvenir que j'en ai

ps -> je m'excuse pour le ton désagréable que j'ai eu lors de la conversation d'hier.

Folco (./5393) :
Apparemment, c'est génial pour faire des manipulations de chaines ou de fichiers (yen a eu de postés ici meme des scripts perl), c'est d'une imbitabilité absolument splendide, c'est le seul souvenir que j'en ai

Bof, Python (et probablement Ruby) permet la même chose, au prix d'une syntaxe est un peu plus longue (et beaucoup plus lisible).
C'était le cas quand Perl était à peu près le seul sur le marché du langage de script, mais ce n'est plus le cas maintenant ^^

C'est d'une "imbitabilité absolument splendide", http://trac.godzil.net/gcc4ti/attachment/ticket/3/fixrefs.pl ?
Faire la même chose en Python, PHP, Ruby (les trois ayant repris les puissantes regexes de Perl, forcément) serait assez similaire, faire la même chose en C++ serait probablement nettement moins lisible, car beaucoup plus long et répétitif...

L'énorme permissivité de la syntaxe de Perl permet de faire de véritables horreurs (même classe que les gagnants de l'IOCCC, il y a même des trucs pires), mais les utilisateurs d'un vrai langage de programmation (*) ne sont jamais obligés de faire n'importe quoi, et heureusement.

*: par "vrai langage de programmation", je veux exclure les langages fait fondamentalement exprès pour être bizarres, comme INTERCAL

Je trouve ça totalement illisible
Déjà, je ne comprends pas le principe d'avoir des variables qui commencent par $, # ou @, comme si une table de hash devait être traitée différemment des autres structures de données.
Il y a souvent un compromis à faire entre raccourcis pour les usages courants (par exemple pouvoir noter {} au lieu de dict() en Python) et syntaxe purement généraliste sans privilégier les trucs les plus courants, mais je trouve que Perl est allé trop loin dans le premier cas

flanker (./5397) :
Déjà, je ne comprends pas le principe d'avoir des variables qui commencent par $, # ou @, comme si une table de hash devait être traitée différemment des autres structures de données.

C'est hérité du BASIC, voyons
pour les ergoteurs : oui je sais qu'en BASIC, le caractère qui spécifie le type est à la fin, et que ça fait longtemps que ce n'est plus obligatoire

./5397> oué, et encore, pour la lisibilité, de plus en plus je préfère expliciter dans mon code.