jeudi 17 janvier 2019

Environnement de developpemt Python et Ubuntu 18.10 : un calvaire ?

Évitons les longues introductions, le problème est le suivant :
paradoxalement, installer un environnement de développement Python3 +  pip3 + pipenv (outils de packaging Python recommandé officiellement) sur Ubuntu 18.10 est un véritable calvaire !!!

Voici les étapes logiques pour l'installation (python3 est déjà pré-installé par défaut sur Ubuntu 18.10) :

1. Installons pip pour python3 (le paquet python-pip est valable pour python2)
$ sudo apt install python3-pip
$ pip3 -V
pip 9.0.1 from /usr/lib/python3/dist-packages (python 3.6)
C'est un bon début.

2. Maintenant, utilisons pip3 pour installer pipenv :
$ pip3 install --user pipenv
ou :
$ python3 -m pip install pipenv --user
Collecting pipenv
  Using cached https://files.pythonhosted.org/packages/13/b4/3ffa55f77161cff9a5220f162670f7c5eb00df52e00939e203f601b0f579/pipenv-2018.11.26-py3-none-any.whl
Collecting pip>=9.0.1 (from pipenv)
  Using cached https://files.pythonhosted.org/packages/c2/d7/90f34cb0d83a6c5631cf71dfe64cc1054598c843a92b400e55675cc2ac37/pip-18.1-py2.py3-none-any.whl
Collecting setuptools>=36.2.1 (from pipenv)
  Using cached https://files.pythonhosted.org/packages/37/06/754589caf971b0d2d48f151c2586f62902d93dc908e2fd9b9b9f6aa3c9dd/setuptools-40.6.3-py2.py3-none-any.whl
Collecting virtualenv (from pipenv)
  Using cached https://files.pythonhosted.org/packages/6a/d1/e0d142ce7b8a5c76adbfad01d853bca84c7c0240e35577498e20bc2ade7d/virtualenv-16.2.0-py2.py3-none-any.whl
Collecting virtualenv-clone>=0.2.5 (from pipenv)
  Using cached https://files.pythonhosted.org/packages/5b/66/6b0265b0f70222ebf8947989092546492b4ef280f560ddf92b80e9d7172a/virtualenv_clone-0.5.0-py2.py3-none-any.whl
Collecting certifi (from pipenv)
  Using cached https://files.pythonhosted.org/packages/9f/e0/accfc1b56b57e9750eba272e24c4dddeac86852c2bebd1236674d7887e8a/certifi-2018.11.29-py2.py3-none-any.whl
Installing collected packages: pip, setuptools, virtualenv, virtualenv-clone, certifi, pipenv
Successfully installed certifi-2018.11.29 pip-18.1 pipenv-2018.11.26 setuptools-40.6.3 virtualenv-16.2.0 virtualenv-clone-0.5.0

Malheureusement, et comme on pourrait s'en douter, le résultat est le même, pip3 est cassé.


3. Mais lorsqu'on tente de relancer pip3 :
$ pip3 -V
Traceback (most recent call last):
  File "/usr/bin/pip3", line 9, in <module>
    from pip import main
ImportError: cannot import name 'main'
Et là, le calvaire commence...


Pour régler ce problème "proprement", on peut faire un :
$ python3 -m pip uninstall pip && sudo apt install python3-pip --reinstall
Ce qui va supprimer pip, puis le réinstaller via apt. Mais le problème reste entier, puisqu'à chaque fois que l'on tentera d'installer pipenv via pip3, nous nous retrouverons avec la même erreur.

De plus, pipenv est inutilisable en l'état, puisque le PATH semble ne pas être configuré correctement et donc le shell ne trouve pas la commande pipenv.
Pour régler cela, il convient d'ajouter une ligne comme la suivante au fichier ~/.bashrc :
export PATH="${HOME}/.local/bin:$PATH"
Bon, d'une certaine manière, si nous acceptons de faire le deuil de pip3, nous avons au moins  un pipenv fonctionnel 👍



Ce que je vais me résigner à faire pour l'instant, car je voulais simplement coder en python3 et non faire du débug sur apt, pip3, pipenv, ou je ne sais quel composant du système.

Ce que je trouve vraiment dommage, c'est qu'une opération en apparence aussi simple qu'installer un module python via les outils prévus pour, pose finalement plus de problèmes qu'il n'en résout.

D'autant que les différentes documentations officielles et non-officielles nous proposent des instructions d'installation parfois très différentes les unes des autres, sans pour autant fournir une solution totalement satisfaisante sous Ubuntu 18.10 (homebrew, dépôt git, sources...).

Ce qui me gêne encore plus est le fait que toute cette opération semble apparemment fonctionner sans aucun embûche sur MacOS, et ça c'est quand-même un peu craignos pour Ubuntu, même si la responsabilité dans cette histoire semble compliquée à attribuer avec certitude...

EDIT :


Une solution par Matthew Brown :
# Install pip and pipenv
sudo apt install python3-pip python3-dev
pip3 install --user pipenv

# Add pipenv (and other python scripts) to PATH
echo "PATH=$HOME/.local/bin:$PATH" >> ~/.bashrc
source ~/.bashrc
Problème résolu !! 🎆
Apparemment le problème venait donc bien du PATH.

Notons que la version de pip3 a effectivement changé, maintenant que le système va bien chercher le bon dans le home de l'utilisateur  :
$ pip3 -V
pip 18.1 from /home/$USER/.local/lib/python3.6/site-packages/pip (python 3.6)
Merci Matthew ;)

lundi 29 septembre 2014

Ticketing OpenSource & gestion de demandes

Dans le cadre de mes divers projets, je suis amené à devoir répondre à de nombreuses demandes, très variées et hétérogènes, pour des demandeurs différents, dans des contextes différents.

La plupart de ces demandes me sont adressées sur l'une de mes nombreuses adresses email, ce qui, en plus de ne garantit aucunement que ces demandes seront bien traitées à temps, à pour autre effet de bord de remplir inutilement mes boîtes mail, rendant de fait encore plus compliqué (/impossible) de retrouver les dites demandes et donc de les traiter.


À terme, cela revient à omettre (in)volontairement un certain nombre de demandes qui pour certaines restent importantes, donc à recevoir des relances qui elles mêmes s'entassent dans des boîtes mails qui à leur tour... Vous saisissez le souci ? C'est bien un serpent qui se mord la queue...


Il y a un certain temps, je me suis penché sur des moyens plus ou moins détournés afin de régler ce problème récurrent.
Listes de taches, post-it, tableau Veleda, etc. Mais aucune de ces solutions n'était suffisante ni acceptable, en partie parce qu'elles ne permettaient pas de déléguer facilement certaines tâches ou d'assurer le suivi de l'ensemble.

Je me suis donc posé la question sous un autre angle : ce problème revenait en fait à gérer une liste de demandes, certes pas des demandes de résolution de bug mais on se rapprochait de la solution.
Après réflexion, un bugtracker ne suffisait pas à régler le problème car trop spécifique. Mais un logiciel de gestion de tickets généraliste le ferait parfaitement !

C'est ainsi que je me suis mis à la recherche de tels logiciels. Connaissant certaines références en logiciels libres, et après quelques recherches, voici une petite liste des candidats potentiels :
  • OTRS : un vieux de la vielle mais toujours d'actualité, référence du marché ; plutôt pour les grosses structures
  • osTicket : deuxième fleuron du marché, peut-être moins austère que le précédent ; adapté aux grosses structures
  • Brimir : basé sur RubyOnRails ; adapté aux petits structures
  • Jutda Helpdesk : également appelé django-helpdesk du nom du fameux framework python sur lequel il est bâti ; adapté aux petits structures
  • RT (Request Tracker) : autre solution

Ces outils permettent entre autres les commodités suivantes:
  • recueil des demandes sous forme de tickets
  • suivi de toutes les demandes, avec statistiques
  • création automatique de tickets à réception d'email
  • assignation du ticket à la personne compétente
  • intégration du demandeur au processus de résolution de sa demande
  • workflows & automatisation
  • ...


La gestion des demandes est une excellente pratique, mais elle ne se suffit pas à elle-seule dans une démarche de recherche d'efficacité, surtout pour du travail collaboratif.

Alliée à un bon gestionnaire de projets comme Redmine, ou OpenProject, la mise en place d'un gestionnaire de tickets devrait solutionner avantageusement cet épineux problème d'organisation.

Maestro s'il vous plait !

Lorsque vous êtes en charge d'un certain nombre de serveur (cela s'applique dès deux serveurs en fait) vous devenez coutumier du fait de devoir répéter inlassablement les mêmes tâche
s, opérations, commandes entre chaque serveur à la chaîne durant des heures.

Par exemple, mise à jour du système, installation de ssh / byobu / Docker / (...), configuration de votre .vimrc, déploiement de services et applications diverses...

Et franchement, pour un feignant perfectionniste comme moi, ça devient vite insupportable !
Sans compter les risques d'erreurs lors de la modification à la chaîne de fichiers de configuration, qui peut donner des résultats allant de l'art moderne à la catastrophe.

En fait tout cela repose sur deux besoins distincts mais complémentaires :
  • gestion de la configuration cohérente des machines
  • envoi de commandes vers un parc entier simultanément
Ces deux besoins sont rassemblés au sein du concept buzzword d'"orchestration".

Jusqu'ici, j'avais en tête des noms de solutions d'orchestration comme Puppet ou Chef.
Pour être honnête, après rapide coup d'œil à leurs doc respectives, je fus pris de violentes nausées devant la complexité de mise en place et la courbe d'apprentissage de ces deux solutions leaders du marché.
De plus, elles sont codées en Ruby, et comme je ne connais pas ce langage, les choses se compliquent en cas de besoin de customisation. Ah, si seulement ils étaient en Python...
Bon, il y a bien Juju, la solution d'orchestration maison de Canonical qui semble très aguicheuse, mais je n'ai pas encore eu le temps de m'y pencher.

Devant ce constat accablant, je devais donc me résigner à attendre de plus favorables hospices...


Ce dimanche soir, je décidais de regarder le film Salt gentimement propose par Netflix, avec Angelina Jolie dans le rôle de l'espionne-agent-double-mais-non-en-fait.

Et puis je me couche pour attaquer la semaine en forme.
Mais 1 heure plus tard, je me réveille sans raison apparente, et ai l'idée de lire quelques GNU/Linux Mag en retard avant de retomber dans les bras de Morphée.

Et là, par une synchronicité comme seule la Vie peut en inventer, je me retrouve nez à nez avec la couverture du GNU/Linux Mag #166 avec au centre "ORCHESTRATION ENFIN SIMPLE avec SALT !".
Comme quoi, il suffisait de demander ! L'agent Évelyne Salt à réponse à tout.
L'article de Émile <iMil> Heitor tombe comme souvent à pique, et me fait découvrir avec son humour légendaire un monde de possibilités insoupçonnées...

Salt est écrit en Python, il est extrêmement simple et puissant et semble répondre à tous les besoins en terme d'orchestration et de gestion de parc de serveurs. Il s'interface par ailleurs facilement avec Fabric, lui aussi écrit en Python.

Que demander de plus ? Y'a plus qu'à tester, et bientôt à moi la gestion de serveurs les doigts de pied en éventail...

Plan de sauvegarde minimaliste


http://www.thorandco.fr/?p=767

vendredi 26 septembre 2014

mercredi 27 août 2014

Sans commentaire...


ou comment supprimer les commentaires des fichiers log/config

grep -v '^#'

sed...

Afficher 1 ligne sur 2


Il peut parfois être utile d'afficher une ligne sur deux d'un fichier.

  • À partir de la première ligne (lignes impaires)
sed -n 'p;n'
  • À partir de la deuxième ligne (lignes paires)
sed -n 'n;p'
Page très utile :