KrISS feed 8 - Un simple et superbe (ou stupide) lecteur de flux. Par Tontof
  • Sunday 08 October 2017 - 17:44

    Kenneth Reitz, l’auteur de requests, tente régulièrement de nous refaire le coup du projet star. Ca n’a malheureusement pas très bien marché, et beaucoup de ses projets comme maya, records, crayon, tablib ou awesome n’ont pas vraiment connu de succès.

    Entre alors pipenv, que j’ai testé il y a presque un an, et qui au départ montrait un beau potentiel, mais n’était pas encore très utilisable. J’ai fait quelques suggestions d’amélioration, comme permettre de choisir précisément la version de Python, et je me suis fait envoyé bouler. J’ai donc laissé l’auteur s’enterrer dans sa recherche de gloire passée.

    Le hasard de reddit m’a remis pipenv sous le nez, et j’ai donc redonné sa chance au produit. Surprise, l’outil est maintenant très stable (plus de 2000 commits !) et mes propositions avaient même été intégrées.

    Après ces 3 paragraphes vous vous demandez sans doute quand est-ce que je vais rentrer dans le vif du sujet, donc:

    pipenv reprend les idées de pip, virtualenv, pew et même quelques trucs de npm, yarn, cargo, et essaye d’appliquer tout ça à Python. L’article suppose que vous savez ce que sont ces mots barbares, donc suivez les liens si ce n’est pas le cas.

    pipenv permet donc d’installer des packages Python, d’isoler cette installation et de la rendre reproductible. Mais sans effort.

    En effet, contrairement à la concurrence:

    • La gestion du virtualenv est automatique et transparente
    • Les paquets installés sont sauvegardés dans des fichiers de config, encore une fois de manière automatique et transparente.
    • Les fichiers de config distinguent les dépendances de prod et de dev, et incluent les versions des sous-dépendances.

    Installer pipenv

    Contrairement à pip et virtualenv, pipenv n’est pas fourni avec une installation standard de Python, bien que l’outil soit maintenant recommandé par la doc officielle. Il va donc falloir l’installer. Or pipenv se base sur une version récente de pip, donc il faut d’abord être sûr d’avoir pip à jour.

    Du coup:

    # mise à jour de pip, mais juste au niveau utilisateur pour 
    # pas casser le  system
    python -m pip install pip --upgrade --user

    Puis:

    # installation de pipenv
    python -m pip install pipenv --user

    A moins d’être sous une Debian like type Ubuntu (qui demande un apt install de python-pip avant), tout le monde a pip installé avec une version moderne de Python.

    Voilà, vous devriez avoir la commande pipenv disponible, ou pour ceux qui ont un système mal configuré, python -m pipenv.

    Usage

    Dans le dossier de votre projet:

    pipenv install nom_du_package

    C’est tout.

    Si un virtualenv n’existe pas il sera créé. Sinon il sera utilisé. Les fichiers de configs sont gérés automatiquement, il n’y a rien à faire.

    Si vous voulez lancer une commande dans le virtualenv:

    pipenv run commande

    Exemple:

    pipenv run python

    Va lancer le Python de votre virtualenv.

    Si vous voulez que toutes les commandes soient dans le virtualenv:

    pipenv shell

    Et vous êtes dans un nouveau shell, dans le virtualenv. Ainsi:

    python

    Lancera celui de votre virtualenv.

    On sort du shell avec Ctrl + D.

    Vous pouvez arrêtez de lire l’article ici, c’est l’essentiel de ce qu’il y a à savoir.

    Astuces

    Si vous lancez pour la première fois dans un dossier pipenv avec:

    pipenv --python x.x

    Le virtualenv sera créé avec la version de Python x.x, pourvu qu’elle existe sur votre système. Setter la variable d’env PIPENV_DEFAULT_PYTHON_VERSION a le même effet.

    Installer un package avec pipenv install --dev le marque comme dépendance de développement uniquement, et permet une installation séparée.

    Vous pouvez aussi obtenir quelques infos utiles comme:

    • pipenv --venv: ou est le dossier du virtualenv
    • pipenv graph: un graph de toutes vos dépendances
    • pipenv --py: chemin vers le Python en cours.

    Enfin pipenv utilise pew, donc la magie de pew reste dispo, y compris la gestion de projets :)

    Usage avancé

    Si vous créez un fichier .env dans le dossier de votre projet tels que:

    FOO=1
    BAR=wololo

    pipenv exécutera toutes ses commandes (y compris shell), avec FOO et BAR comme variables d’environnement.

    La commande:

    pipenv lock

    Va créer un lock file. Ce fichier contient toutes les dépendances, et recursivement, les dépendances des dépendances, installées, avec leurs versions. On peut réutiliser ce fichier en prod pour installer une exacte copie de son setup local avec pipenv install. Sans ce fichier, pipenv install se comportera comme pip install.

    Il y a plein d’autres trucs mais on va en rester là.

  • Friday 06 October 2017 - 10:24

    Sous Linux, le dossier utilisateur est blindé de fichiers de configuration. Les fameux .machins. Par exemple le .bashrc pour la config du bash, le .mozilla qui contient toutes vos données Firefox, le .ssh avec toutes vos clés privées, le .local/share/virtualenvs avec les envs virtuels Python créés par pew ou .config/sublime-text-3 pour la configuration de Sublime text, etc.

    Au final, voici tous les fichiers de conf qui sont importants pour moi de près ou de loin:

    ├── .autoenv
    ├── .bashrc
    ├── .config
    │   ├── autostart
    │   ├── Code
    │   ├── copyq
    │   ├── fish
    │   ├── gtg
    │   ├── liferea
    │   ├── pulse
    │   ├── stremio
    │   ├── sublime-text-3
    │   ├── transmission
    │   ├── user-dirs.dirs
    │   ├── user-dirs.locale
    │   ├── variety
    │   ├── VeraCrypt
    │   ├── Zeal
    │   └── zim
    ├── .django-completion.bash
    ├── .editorconfig
    ├── .git-aware-prompt
    ├── .git-completion.bash
    ├── .gitconfig
    ├── .gitignore
    ├── .git-prompt.sh
    ├── .git.scmbrc
    ├── .jupyter
    ├── .lastpass
    ├── .liferea_1.8
    ├── .local
    │   └── share
            ├── gtg
            ├── keyrings
            ├── liferea
            ├── omf
            ├── TowerFall
            ├── virtualenvs
            └── Zeal
    ├── .mozilla
    ├── .netrc
    ├── .oh-my-zsh
    ├── .openambit
    ├── .pypirc
    ├── .scmbrc
    ├── .scm_breeze
    ├── .sshplus
    ├── .vscode
    │   └── extensions
    └── .zshrc
    

    Quand on bidouille, on les change souvent. On les backup aussi, pour pouvoir les porter d’un laptop à un autre, les synchroniser, les uploader sur un serveur ou les récup lors d’une réinstallation. Parce que quand on a tuné ses terminaux et éditeurs aux petits oignons, on a pas envie de recommencer à poil.

    Pour bien faciliter les choses, ils sont éparpillés un peu partout, dans des sous-dossiers différents.

    Et je sais pas quel vil individu a suggéré une fois que faire une partition séparée pour /home était la solution de Skippy à tous les soucis, mais perso, ça me cause plus de bugs qu’autre chose quand on change de versions d’OS.

    Bref, laissez tomber vos vieilles croyances issues de charlatans de sectes. Moi, j’ai vu la lumière (lien de don bitcoin en bas à droite de la page), et elle s’appelle GNU stow.

    Stow est un vieil utilitaire (donc sagesse millénaire des anciens, vous pouvez avoir confiance, prenez ce cristal aussi il est en promo), qui est grosso merdo un ln -s récursive. C’est-à-dire que ça fait des symlinks des fichiers et des dossiers que vous lui passez.

    On peut l’utiliser pour plein de choses, mais l’usage sacré implique le sacrifice d’une vierge à Max, puis de déplacer tous les fichiers de settings qu’on souhaite gérer dans un seul dossier.

    Par exemple, moi j’ai:

    /home/user/church/settings/
    
        ├── .autoenv
        ├── .bashrc
        ├── .config
        │   ├── autostart
        │   ├── Code
        │   ├── copyq
        │   ├── fish
        │   ├── gtg
        ...
    

    Au lieu de les avoir éparpillées partout, toutes les brebis sont maintenant regroupées dans une seule église.

    Il est très important de garder l’organisation des dossiers et des sous-dossiers d’origine. Ici vous voyez que j’ai le dossier Code, qui est le dossier de settings de VSCode. Mais il est DANS un dossier .config, car avant mon regroupement il était dans /home/user/.config/.

    En revanche, il n’est pas du tout nécessaire que .config contienne tous les dossiers qu’il avait précédemment. Seuls ceux qui vous intéressent. Le reste peut rester à sa place initiale, dans le /home/user/.config/.

    Donc je résume:

    • Listez les fichiers et dossiers de settings qui vous intéressent.
    • Déplacez les tous dans un dossier commun en gardant une arborescence similaire.
    • Laissez les fichiers qui ne vous intéressent pas là où ils sont.
    • Priez (une bonne pratique avant toute opération informatique).

    Arrive le messie, Stow.

    D’abord, il faut l’installer, mais comme c’est un outil vénérable, il est dans les dépôts. Sous Ubuntu, le psaume “apt install stow” fera l’affaire.

    Ensuite, on prêche. Je me perds dans mes propres paraboles, mais les voies du seigneur sont impénétrables, contrairement à celles d’Abella Anderson. Bref on demande à stow de traiter récursivement tout le contenu du dossier settings qui est dans /home/user/church afin de le linker vers /home/user/:

    stow -d /home/user/church -t /home/user/ settings

    Stow va prendre récursivement tous les dossiers qui sont dans /home/user/church/settings, et les comparer à ceux dans /home/user. Si ils existent, il va ne rien faire, mais si ils n’existent pas, il va créer un lien vers chacun de ceux manquants. Pour les fichiers, si ils n’existent pas, il va créer un lien, sinon il va vous afficher une erreur, afin de ne pas écraser quelque chose d’important et vous signalez qu’il y un souci.

    Le but de tout ça ?

    Pour votre système et tous vos logiciels, ça ne change rien. Ils vont tomber sur les liens et avoir l’impression que tous les fichiers de configs sont à leur place et vont continuer à fonctionner dans la joie et le gospel.

    Et pour vous, ben vous avez un seul endroit où tous les fichiers importants sont regroupés. Plus besoin de les chercher. Facile à backuper et à restaurer. On peut même tout foutre sous Git.

    Loué soit le sauveur.

    Vive moi.