Le 6 novembre 2024, j'ai publié la note "Le support des variables d'environments de Mise est limité, je continue à utiliser direnv".

L'issue indiquée dans cette note a été cloturée il y a 3 jours : Use mise tools in env template · Issue #1982.

Voici le contenu de changement de la documentation : https://github.com/jdx/mise/pull/3598/files#diff-e8cfa8083d0343d5a04e010a9348083f7b64035c407faa971074c6f0e8d0d940

Ce qui signifie que je vais pouvoir maintenant utiliser terraform installé via Mise dans le fichier .envrc :

[env]
_.source = { value = "./.envrc.sh", tools = true }

[tools]
terraform="1.9.8"

Après avoir installé la dernière version de Mise, j'ai testé cette configuration dans repository suivant : install-and-configure-mise-skeleton.

Le fichier .envrc suivant a fonctionné :

export HELLO_WORLD=foo3
export NOW=$(date)
export TERRAFORM_VERSION=$(terraform --version | head -n1)

Exemple :

$ mise trust
$ echo $TERRAFORM_VERSION
Terraform v1.9.8

Je n'ai pas trouvé de commande Mise pour recharger les variables d'environnement du dossier courant, sans quitter le dossier. Avec direnv, pour effectuer un rechargement je lançais : direnv allow.

À la place, j'ai trouvé la méthode suivante :

$ source .envrc

Je pense pouvoir maintenant remplacer Direnv par Mise 🤞.

J'utilise souvent le terme "Script Helper". Dans cette note, je vais tenter de le définir.

Un script dit « helper » est un script qui n'est pas essentiel au cœur du projet et qui ne contient pas de code métier. Son rôle est d’automatiser des tâches courantes et réutilisables pour le développeur.

L’écriture de ces scripts permet de centraliser et de versionner leur contenu, tout en réduisant les risques d’erreurs d’exécution.

Dans une note précédente, j'ai donné ma définition et les objectifs d'un "Development kit".
Dans cette note, je souhaite donner ma définition et les objectifs d'un workspace dans un "environnements de développement".

Un workspace est un dossier, qui contient des paramètres de configuration spécifiques — généralement sous la forme de variables d'environnements — qui permettent d'interagir sur une ou plusieurs instances de services, d'un environnement précis.
Généralement ce dossier contient des guides d'instructions pour réaliser des actions spécifiques sur le workspace et des scripts de type "helpers".

Exemple de workspaces :

• staging/remote-workspace/ : un workspace utilisé pour effectuer des actions sur les services déployés en staging sur des serveurs distants ;
• staging/local-workspace/ : un workspace d'installer localement des services dans les mêmes conditions que sur l'environnement staging ;
• development/local-workspace/ : un dossier workspace, qui permet de travailler — contribuer — localement sur le ou les services.

---

Voir aussi :

• Réflexions au sujet des notions d'"environnement", "instance" et "workspace"

J'utilise la fonctionnalité Docker volume mounts dans tous mes projets depuis septembre 2015.

Généralement, sous la forme suivante :

services:
  postgres:
    image: postgres:17
    ...
	volumes:
      - ./volumes/postgres/:/var/lib/postgresql/data/

D'après mes recherches, la fonctionnalité volumes mounts a été introduite dans la version 0.5.0 en juillet 2013.

À cette époque, je crois me souvenir que Docker permettait aussi de créer des volumes anonymes. Je n'ai jamais apprécié les volumes anonymes, car lorsqu'un conteneur était supprimé, il devenait compliqué de retrouver le volume associé.
À cette époque, Docker était nouveau et j'avais très peur de perdre des données, par exemple, les volumes d'une instance PostgreSQL.

J'ai donc décidé qu'il était préférable de renoncer aux volumes anonymes et d'opter systématiquement pour des volume mounts.

Ensuite, peut-être en janvier 2016, Docker a introduit les named volumes, qui permettent de créer des volumes avec des noms précis, par exemple :

services:
  postgres:
    image: postgres:17
    ...
	volumes:
      - postgres:/var/lib/postgresql/data/

volumes:
  postgres:
    name: postgres

$ docker volume ls
DRIVER    VOLUME NAME
local     postgres

Ce volume est physiquement stocké dans le dossier /var/lib/docker/volumes/postgres/_data.

Depuis, j'ai toujours préféré les volumes mounts aux named volumes pour les raisons pratiques suivantes :

• Travaillant souvent sur plusieurs projets, j'utilise les volume mounts pour éviter les collisions. Lorsque j'ai essayé les named volumes, une question s'est posée : quel nom attribuer aux volumes PostgreSQL ? « postgres » ? Mais alors, quel nom donner au volume PostgreSQL dans le projet B ? Avec les volume mounts, ce problème ne se pose pas.
• J'apprécie de savoir qu'en supprimant un projet avec rm -rf ~/git/github.com/stephan-klein/foobar/, cette commande effacera non seulement l'intégralité du projet, mais également ses volumes Docker.
• Avec les mounted volume, je peux facilement consulter le contenu des volumes. Je n'ai pas besoin d'utiliser docker volume inspect pour trouver le chemin du volume.

La stratégie que j'ai choisie basée sur volumes mounts a quelques inconvénients :

• Le owner du dossier volumes/, situé dans le répertoire du projet, est root. Cela entraîne fréquemment des problèmes de permissions, par exemple lors de l'exécution des scripts de linter dans le dossier du projet. Pour supprimer le projet, je dois donc utiliser sudo. Je précise que ce problème n'existe pas sous MacOS. Je pense que ce problème pourrait être contourné sous Linux en utilisant podman.
• La commande docker compose down -v ne détruit pas les volumes.

Je suis pleinement conscient que ma méthode basée sur les volume mounts est minoritaire. En revanche, j'observe qu'une grande majorité des développeurs privilégie l'utilisation des named volumes.

Par exemple, cet été, un collègue a repris l'un de mes projets, et l'une des premières choses qu'il a faites a été de migrer ma configuration de volume mounts vers des named volumes pour résoudre un problème de permissions lié à Prettier, eslint ou Jest. En effet, la fonctionnalité ignore de ces outils ne fonctionne pas si NodeJS n'a pas les droits d'accès à un dossier du projet 😔.

Aujourd'hui, je me suis lancé dans la recherche d'une solution me permettant d'utiliser des named volumes tout en évitant les problèmes de collision entre projets.

Je pense que j'ai trouvé une solution satisfaisante 🙂.

Je l'ai décrite et testée dans le repository docker-named-volume-playground.

Ce repository d'exemple contient 2 projets distincts, nommés project_a et project_b.
J'ai instancié deux fois chacun de ces projets. Voici la liste des dossiers :

$ tree
.
├── project_a_instance_1
│   ├── docker-compose.yml
│   └── .envrc
├── project_a_instance_2
│   ├── docker-compose.yml
│   └── .envrc
├── project_b_instance_1
│   ├── docker-compose.yml
│   └── .envrc
├── project_b_instance_2
│   ├── docker-compose.yml
│   └── .envrc
└── README.md

Ce repository illustre l'organisation de plusieurs instances de différents projets sur la workstation du développeur.
Il ne doit pas être utilisé tel quel comme base pour un projet.
Par exemple, le "vrai" repository du projet projet_a se limiterait aux fichiers suivants : docker-compose.yml et .envrc.

Voici le contenu d'un de ces fichiers .envrc :

export PROJECT_NAME="project_a"
export INSTANCE_ID=$(pwd | shasum -a 1 | awk '{print $1}' | cut -c 1-12) # Used to define docker volume path
export COMPOSE_PROJECT_NAME=${PROJECT_NAME}_${INSTANCE_ID}

L'astuce que j'utilise est au niveau de INSTANCE_ID. Cet identifiant est généré de telle manière qu'il soit unique pour chaque instance de projet installée sur la workstation du développeur.
J'ai choisi de générer cet identifiant à partir du chemin complet vers le dossier de l'instance, je le passe dans la commande shasum et je garde les 12 premiers caractères.

J'utilise ensuite la valeur de COMPOSE_PROJECT_NAME dans le docker-compose.yml pour nommer le named volume :

services:
  postgres:
    image: postgres:17
    environment:
      POSTGRES_USER: postgres
      POSTGRES_DB: postgres
      POSTGRES_PASSWORD: password
    ports:
      - 5432
    volumes:
      - postgres:/var/lib/postgresql/data/
    healthcheck:
      test: ["CMD", "sh", "-c", "pg_isready -U $$POSTGRES_USER -h $$(hostname -i)"]
      interval: 10s
      start_period: 30s

volumes:
  postgres:
     name: ${COMPOSE_PROJECT_NAME}_postgres

Exemples de valeurs générées pour l'instance installée dans /home/stephane/git/github.com/stephane-klein/docker-named-volume-playground/project_a_instance_1 :

• INSTANCE_ID=d4cfab7403e2
• COMPOSE_PROJECT_NAME=project_a_d4cfab7403e2
• Nom du container postgresql : project_a_d4cfab7403e2-postgres-1
• Nom du volume postgresql : project_a_a04e7305aa09_postgres

Conclusion

Cette méthode me permet de suivre une pratique plus mainstream — utiliser les named volumes Docker — tout en évitant la collision des noms de volumes.

Je suis conscient que ce billet est un peu long pour expliquer quelque chose de simple, mais je tenais à partager l'historique de ma démarche.

Je pense que je vais dorénavant utiliser cette méthode pour tous mes nouveaux projets.

---

20224-12-10 11h27 : Je tiens à préciser qu'avec la configuration suivante :

services:
  postgres:
    image: postgres:17
    ...
	volumes:
      - postgres:/var/lib/postgresql/data/

volumes:
  postgres:

Quand le nom du volume postgres n'est pas défini, docker-compose le nomme sous la forme ${COMPOSE_PROJECT_NAME}_postgres. Si le projet est stocké dans le dossier foobar, alors le volume sera nommé foobar_postgres.

$ docker volume ls
DRIVER    VOLUME NAME
local     foobar_postgres

Je viens de rencontrer l'outil envdir (à ne pas confondre avec direnv) et son modèle de stockage de variables d'environnement, que je trouve très surprenant !

direnv ou dotenv utilisent de simples fichiers texte pour stocker les variables d'environnements, par exemple :

export POSTGRES_URL="postgres://postgres:password@localhost:5432/postgres"
export SMTP_HOST="127.0.0.1"
export SMTP_PORT="1025"
export MAIL_FROM="noreply@example.com"

Contrairement à ces deux outils, pour définir ces quatre variables, le modèle de stockage de envdir nécessite la création de 4 fichiers :

$ tree .
.
├── MAIL_FROM
├── POSTGRES_URL
├── SMTP_HOST
└── SMTP_PORT

1 directory, 4 files

$ cat POSTGRES_URL
postgres://postgres:password@localhost:5432/postgres
$ cat SMTP_HOST
127.0.0.1
$ cat SMTP_PORT
1025
$ cat MAIL_FROM
127.0.0.1

Je trouve ce modèle fort peu pratique. Contrairement à un simple fichier unique, le modèle de envdir présente certaines limitations :

• Organisation : il ne permet pas de structurer librement l'ordre ou de regrouper visuellement les variables.
• Lisibilité : l'ensemble de la configuration est plus difficile à visualiser d'un seul coup d'œil.
• Manipulation : copier ou coller son contenu n'est pas aussi direct qu'avec un fichier texte.
• Documentation : les commentaires ne peuvent pas être inclus pour expliquer les variables.
• Rapidité : la saisie ou la modification de plusieurs variables demande plus de temps, chaque variable étant dans un fichier distinct.

J'ai été particulièrement intrigué par le choix fait par l'auteur de envdir. Sa décision semble vraiment surprenante.

envdir fait partie du projet daemontools, créé en 1990. Ainsi, il est bien plus ancien que dotenv, qui a été lancé autour de 2010, et direnv, qui date de 2014.

Si je me remets dans le contexte des années 1990, je pense que le modèle de envdir a été avant tout motivé par une simplicité d'implémentation plutôt que d'utilisation. En effet, il est plus facile de lister les fichiers d'un répertoire et de charger leur contenu que de développer un parser de fichiers.

Je pense qu'en 2024, envdir n'a plus sa place dans un environnement informatique moderne. Je recommande vivement de le remplacer par des solutions plus récentes, comme devenv ou direnv.

Personnellement, j'utilise direnv dans tous mes projets.

Alexandre a eu un breaking change avec Mise : https://github.com/jdx/mise/issues/3338.

Suite à cela, j'ai découvert que Mise va prévilégier l'utilisation du backend aqua plutôt que Asdf :

we are actively moving tools in the registry away from asdf where possible to backends like aqua and ubi which don't require plugins.

source

J'ai découvert au passage que Mise supporte de plus en plus de backend, par exemple Ubi et vfox.

Je constate qu'il commence à y avoir une profusion de "tooling version management" : Asdf,Mise, aqua, Ubi, vfox !
Je pense bien qu'ils ont chacun leurs histoires, leurs forces, leurs faiblesses… mais j'ai peur que cela me complique mon affaire : comment arriver à un consensus de choix de l'un de ces outils dans une équipe 🫣 ! Chaque développeur aura de bons arguments pour utiliser l'un ou l'autre de ces outils.

Constatant plusieurs fois que le développeur de Mise a fait des breaking changes qui font perdre du temps aux équipes, mon ami et moi nous sommes posés la question si, au final, il ne serait pas judicieux de revenir à Asdf.

D'autre part, au départ, Mise était une simple alternative plus rapide à Asdf, mais avec le temps, Mise prend en charge de plus en plus de fonctionnalités, comme une alternative à direnv , un système d'exécution de tâches, ou mise watch.
Souvent, avec des petits défauts très pénibles, voir par exemple, ma note "Le support des variables d'environments de Mise est limité, je continue à utiliser direnv".

Alexandre s'est ensuite posé la question d'utiliser un jour le projet devenv, un outil qui va encore plus loin, basé sur le système de package Nix.

Le projet devenv me fait un peu peur au premier abord, il gère "tout" :

• Comme Asdf et Mise : l'installation des outils, packages et langages
• Support de scripts "helper"
• Intégration de Docker
• Support de process
• Support du SDK Android

Il fait énormément de choses et je crains que la barrière à l'entrée soit trop haute et fasse fuir beaucoup de développeurs 🤔.

Tout cela me fait un peu penser à Bazel (utilisé par Google), Pants (utilisé par Twitter), Buck (utilisé par Facebook) et Please.
Tous ces outils sont puissants, je les ai étudiés en 2018 sans arrivée à les adopter.

Pour le moment, mes development kit nécessitent les compétences suivantes :

• Comprendre les rudiments d'un terminal Bash ;
• Arriver à installer et à utiliser Mise et direnv ;
• Maitriser Docker ;
• Savoir lire et écrire des scripts Bash de niveau débutant.

Déjà, ces quatre prérequis posent quelques fois des difficultés d'adoption.

#JaiDécouvert l'outil de "version manager" nommé aqua, une alternative à Mise et Asdf codé en Golang.

Ce projet semble avoir débuté en août 2021.

J'ai fait quelques recherches au sujet d'aqua sur Hacker News, j'ai trouvé très peu d'occurrences. J'ai trouvé "Ask HN: Homebrew, Asdf, Nix, or Other?".

Je pense qu'aqua est bien moins populaire que Asdf et Mise.

Au 4 décembre 2024 :

• aqua : 901 stars GitHub
• Mise : 10 400 stars GitHub
• Asdf : 22 200 stars GitHub

Dans la note 2024-11-20_1102, je disais :

Prochaine étape du Projet 17 : Setup les iOS Requirements de Capacitor sur ce serveur Apple Silicon.

C'est chose faite 🙂.

Le repository poc-capacitor contient maintenant un script ./scripts/deploy-ios-requirements.sh qui permet d'exécuter ce script de provisioning sur le serveur Scaleway Apple Silicon distant : /provisioning/_ios.sh.

Ensuite, j'ai détaillé les étapes pour :

• Uploader le projet sur le Scaleway Apple Silicon distant
• Démarrer l'émulation d'un iPhone 15
• Compiler et lancer l'application Capacitor dans l'émulateur iPhone 15
• Et visualiser l'émulateur via VNC

Tout cela est détaillé ici : https://github.com/stephane-klein/poc-capacitor/tree/f109fb23dc612f486fad0d55ba939b4679841d06?tab=readme-ov-file#launch-application-on-ios

Dans le projet "Projet 17 - Créer un POC de création d'une app smartphone avec Capacitor" je disais :

• Essayer d'utiliser l'offre Apple Mac mini M1 de Scaleway pour builder l'app pour iOS

Voici mon retour d'expérience d'utilisation de l'offre Scaleway Apple Silicon.

Voici la liste des images MacOS disponibles :

$ scw apple-silicon os list
ID                                    NAME                LABEL               IMAGE URL                                                                       FAMILY   IS BETA  VERSION  XCODE VERSION
59bf09f1-5584-469d-a0f6-55c8fee1ab81  macos-ventura-13.6  macOS Ventura 13.6  https://scw-apple-silicon.s3.fr-par.scw.cloud/scw-console/os/macos-ventura.png  Ventura  false    13.6     14
e08d1e5d-b4b9-402a-9f9a-97732d17e374  macos-sonoma-14.4   macOS Sonoma 14.4   https://scw-apple-silicon.s3.fr-par.scw.cloud/scw-console/os/macos-sonoma.png   Sonoma   false    14.4     15
7a8d85fb-781a-4212-8e47-240ec0c3d23f  macos-sequoia-15.0  macOS Sequoia 15.0  https://scw-apple-silicon.s3.fr-par.scw.cloud/scw-console/os/macos-sequoia.png  Sequoia  true     15.0     16

Voici la liste des types de serveurs disponibles dans la zone fr-par-3 :

$ SCW_DEFAULT_ZONE="fr-par-3" scw apple-silicon server-type list
Name  CPU                 Memory  Disk    Stock       Minimum Lease Duration
M1-M  Apple M1 (8 cores)  8.0 GB  256 GB  high stock  1 days

Et la liste dans la zone fr-par-1 :

$ SCW_DEFAULT_ZONE="fr-par-1" scw apple-silicon server-type list
Name  CPU                      Memory  Disk    Stock       Minimum Lease Duration
M2-M  Apple M2 (8 cores)       16 GB   256 GB  high stock  1 days
M2-L  Apple M2 Pro (10 cores)  16 GB   512 GB  high stock  1 days

Je souhaite installer un serveur de type M1-M à 0,11 € HT / heure, soit 2,64 € HT / jour, 80,3 € HT / mois.

Lors de ma première tentative, j'ai essayé de créer un serveur avec la commande suivante :

$ scw apple-silicon server create name=capacitor zone=fr-par-3 "$SCW_PROJECT_ID" M1-M 7a8d85fb-781a-4212-8e47-240ec0c3d23f
Invalid argument '46ad009f-xxxxxx': arg name must only contain lowercase letters, numbers or dashes

Suite à cette erreur, j'ai créé l'issue siuvante : Reduce"scw apple-silicon server create" helper message ambiguity.

$ scw apple-silicon server create name=capacitor project-id=${SCW_PROJECT_ID}  type=M1-M os-id=7a8d85fb-781a-4212-8e47-240ec0c3d23f zone=fr-par-3

Mais l'OS n'était pas trouvé, je me suis rendu compte que cette image OS n'était pas disponible dans la zone fr-par-3.

$ SCW_DEFAULT_ZONE="fr-par-3" scw apple-silicon os list
ID                                    NAME                LABEL               IMAGE URL                                                                       FAMILY   IS BETA  VERSION  XCODE VERSION
59bf09f1-5584-469d-a0f6-55c8fee1ab81  macos-ventura-13.6  macOS Ventura 13.6  https://scw-apple-silicon.s3.fr-par.scw.cloud/scw-console/os/macos-ventura.png  Ventura  false    13.6     14
e08d1e5d-b4b9-402a-9f9a-97732d17e374  macos-sonoma-14.4   macOS Sonoma 14.4   https://scw-apple-silicon.s3.fr-par.scw.cloud/scw-console/os/macos-sonoma.png   Sonoma   false    14.4     15

Voici finalement la commande de création de serveur qui a fonctionné avec succès :

$ scw apple-silicon server create name=capacitor project-id=$SCW_PROJECT_ID  type=M1-M os-id=e08d1e5d-b4b9-402a-9f9a-97732d17e374 zone=fr-par-3
ID              bb34d8ef-6305-4104-801c-1cf1b6b0f99f
Type            M1-M
Name            capacitor
ProjectID       46ad009f-xxxx
OrganizationID  215d7434-xxxx
IP              51.xxx.xxx.xxx
VncURL          vnc://m1:xxxx@51.xxx.xxx.121:5900
SSHUsername     m1
SudoPassword    xxxxxxx
Os              ID            e08d1e5d-b4b9-402a-9f9a-97732d17e374
Name          macos-sonoma-14.4
Label         macOS Sonoma 14.4
ImageURL      https://scw-apple-silicon.s3.fr-par.scw.cloud/scw-console/os/macos-sonoma.png
Family        Sonoma
IsBeta        false
Version       14.4
XcodeVersion  15

CompatibleServerTypes:
[M1-M M2-M M2-L]
Status             starting
CreatedAt          now
UpdatedAt          now
DeletableAt        23 hours from now
DeletionScheduled  false
Zone               fr-par-3

Voici le serveur créé :

$ scw apple-silicon server list
ID                                    TYPE  NAME       PROJECT ID
bb34d8ef-6305-xxxxx  M1-M  capacitor  46ad009f-54bc-4125-xxxxxx

Le serveur est passé en ready après environ 1min.

$ scw apple-silicon server get bb34d8ef-6305-xxxxxxx
...

CompatibleServerTypes:
[M1-M M2-M M2-L]
Status             ready
...
DeletableAt        23 hours from now
DeletionScheduled  false
...

Je peux me connecter directement en ssh au serveur :

$ ssh m1@xxx.xxx.xx.xxx
Last login: Wed Nov 20 16:22:10 2024
m1@bb34d8ef-6305-4104-801c-1cf1b6b0f99f ~ % uname -a
Darwin bb34d8ef-6305-4104-801c-1cf1b6b0f99f 23.4.0 Darwin Kernel Version 23.4.0: Fri Mar 15 00:12:41 PDT 2024; root:xnu-10063.101.17~1/RELEASE_ARM64_T8103 arm64

Je peux aussi me connecter au serveur via VNC (lien vers la documentation à ce sujet).

Installation des dépendances sous Fedora :

$ sudo dnf install -y remmina remmina-plugins-vnc

J'utilise le client VNC nommé Remmina.

$ remmina -c vnc://m1:xxxxx@51.xxxx.xxx.xxxx:5900

Les paramètres vnc et le mot de passe de l'user m1 sont disponibles dans la sortie de :

$ scw apple-silicon server get bb34d8ef-6305-xxxxxxx -o json
{
  "id": "bb34d8ef-6305-4104-xxxx-xxxxxxxxx",
  ...
  "vnc_url": "vnc://m1:xxxx@xxx.xxx.xxx.xxx:5900",
  "ssh_username": "m1",
  "sudo_password": "bTgkdiVUs7yT",
  ...
}

Il est possible de coller le mot de passe via la fonctionnalité « Envoyer le contenu du presse-papiers comme une saisie au clavier » de Remmina :

Attention, la réinstallation d'un serveur Apple Silicon prend au moins 45min.

J'ai implémenté des scritps de déploiement d'un Apple Silicon dans le POC : poc-capacitor.

Prochaine étape du Projet 17 : Setup les iOS Requirements de Capacitor sur ce serveur Apple Silicon.

#iteration Projet 17 - Créer un POC de création d'une app smartphone avec Capacitor.

---

Dans la note 2024-11-19_1029, je disais :

Pour utiliser Capacitor, j'ai besoin d'installer certains éléments.

In order to develop Android applications using Capacitor, you will need two additional dependencies:

• Android Studio
• An Android SDK installation

Je me demande si Android Studio est optionnel ou non.

La réponse est non, Android Studio n'est pas nécessaire, ni pour compiler l'application, ni pour la lancer dans un émulateur Android. Android SDK est suffisant.

J'ai utilisé le plugin Mise https://github.com/Syquel/mise-android-sdk pour installer les "Android Requirements" de Capacitor. Les instructions détaillées pour Fedora sont listées dans le README.md du repository : https://github.com/stephane-klein/poc-capacitor/tree/4238e80f84a248fdb9e5bb86c10bea8b9f0fdade.

Dans le Projet 17 - Créer un POC de création d'une app smartphone avec Capacitor, il semble que j'ai besoin d'installer Android Studio.

J'ai exploré la méthode Asdf / Mise, mais j'ai rencontré des difficultés : 2024-11-19_1029 et 2024-11-19_1102.

J'ai ensuite constaté ici que RPM Fusion ne propose pas de package Android Studio. J'ai ensuite cherché sur Fedora COPR, mais j'ai trouvé uniquement de très vieux packages.

J'ai lu ici qu'Android Studio est disponible via Flatpak sur Flathub : https://flathub.org/apps/com.google.AndroidStudio. Je n'avais pas pensé à Flatpak 🙊.

Après réflexion, je trouve cela totalement logique que Android Studio soit distribué via Flatpak.

Voici le repository GitHub de ce package : https://github.com/flathub/com.google.AndroidStudio. Il semble être bien maintenu par Alessandro Scarozza « Senior Android Developer, Android Studio Flatpak Mantainer and old Debian Linux user ».

Le package contient la version 2024.2.1.11 d'Android Studio, j'ai vérifié, elle correspond bien à la dernière version disponible sur https://developer.android.com/studio.

Voici ce que donne l'installation :

$ flatpak install com.google.AndroidStudio
Looking for matches…
Remotes found with refs similar to ‘com.google.AndroidStudio’:

   1) ‘flathub’ (system)
   2) ‘flathub’ (user)

Which do you want to use (0 to abort)? [0-2]: 1

com.google.AndroidStudio permissions:
    ipc                   network       pulseaudio      ssh-auth      x11      devices      multiarch      file access [1]
    dbus access [2]

    [1] home
    [2] com.canonical.AppMenu.Registrar, org.freedesktop.Notifications, org.freedesktop.secrets


        ID                                        Branch           Op           Remote            Download
 1. [✓] com.google.AndroidStudio.Locale           stable           i            flathub           5,6 Ko / 57,2 Ko
 2. [✓] com.google.AndroidStudio                  stable           i            flathub           1,3 Go / 1,3 Go

Installation complete.

#iteration Projet 17 - Créer un POC de création d'une app smartphone avec Capacitor.

---

Pour utiliser Capacitor, j'ai besoin d'installer certains éléments.

In order to develop Android applications using Capacitor, you will need two additional dependencies:

• Android Studio
• An Android SDK installation

Je me demande si Android Studio est optionnel ou non.

J'aimerais installer ces deux services avec Mise.

J'ai trouvé des Asdf plugins pour Android SDK :

• https://github.com/Syquel/mise-android-sdk (créé le 2024-03-03)
• https://github.com/huffduff/asdf-android-sdk (créé le 2024-10-10)
• https://github.com/arcticShadow/asdf-android (créé le 2024-11-13)

#JeMeDemande quel plugin utiliser, quelles sont leurs différences.

Pour essayer d'avoir une réponse, j'ai posté les issues suivantes :

• What are the differences with other existing plugins?
• What are the differences with other existing plugins?

---

Alexandre m'a informé qu'il a utilisé avec succès le plugin https://github.com/Syquel/mise-android-sdk/, il a même créé une issue https://github.com/Syquel/mise-android-sdk/issues/10 qui a été traité 🙂.

---

La suite : 2024-11-19_1102.

J'ai décidé d'utiliser la fonctionnalité "mise env._source" pendant quelques semaines pour me faire une opinion.

-- (from)

J'ai déjà rencontré un problème : il n'est pas possible de lancer des outils installés via Mise dans un script lancé par _.source.

Voici un exemple, j'ai ce fichier .envrc.sh :

export SERVER1_IP=$(terraform output --json | jq -r '.server1_public_ip | .value')

Terraform est installé avec Mise :

[env]
_.source = "./.envrc.sh"

[tools]
terraform="1.9.8"

Quand je lance mise set, j'ai cette erreur :

$ mise set
.envrc.sh: line 6: terraform: command not found

J'ai trouvé une issue pour traiter cette limitation : "Use mise tools in env template".

En attendant que cette issue soit implémentée, j'ai décidé de continuer d'utiliser direnv.

---

2024-12-19 : suite à la cloture de l'issue indiquée dans cette note, j'ai publié la note Je pense maintenant pouvoir remplacer Direnv par Mise 🤞.

Depuis avril 2019, j'utilise direnv dans pratiquement tous mes projets de développement informatique.

Ce matin je me suis demandé si avec les nouvelles fonctionnalités de gestion des variables d'environnement de Mise, je pouvais simplifier mes development kit 🤔.

Comme vous pouvez le voir dans install-and-configure-direnv-with-mise-skeleton, actuellement mes development kit contiennent deux étapes de modifications de .bash_profile ou .zshrc. Exemple avec Zsh :

• Une étape pour configurer Mise :

$ echo 'eval "$(~/.local/bin/mise activate zsh)"' >> ~/.zshrc
$ source ~/.zsrhrc

• Seconde étape pour configurer direnv :

$ echo -e "\neval \"\$(direnv hook zsh)\"" >> ~/.zshrc
$ source ~/.zsrhrc

Voici la version simplifiée de ce skeleton basé sur "mise env._source", avec une étape de configuration en moins :

https://github.com/stephane-klein/install-and-configure-mise-skeleton

Voici le contenu du fichier .mise.toml :

[env]
_.source = "./.envrc.sh"

et le contenu de .envrc.sh :

export HELLO_WORLD=foo

J'ai fait le choix de nommer ce fichier .envrc.sh plutôt que .envrc afin d'éviter des problèmes de compatibilité pour les utilisateurs qui ont direnv installé.

J'ai vérifié que les variables d'environnements "parents" sont bien conservées en cas de changement de variable d'environnement par Mise dans un sous dossier.

#JeMeDemande si je vais rencontrer des régressions par rapport à direnv 🤔.

J'ai décidé d'utiliser la fonctionnalité "mise env._source" pendant quelques semaines pour me faire une opinion.

Update : voir 2024-11-06_2109.

Voici un dépôt GitHub qui contient les instructions que j'indiquais dans mes development kit, avant 2024, pour installer et configurer direnv, sous MacOS.

https://github.com/stephane-klein/install-and-configure-direnv-with-asdf-skeleton

Dans ce skeleton, direnv est installé avec asdf, voir le fichier racine ./.tool-versions

---

Et voici un exemple de skeleton, que j'utilise depuis novembre 2023, basé sur Mise :

https://github.com/stephane-klein/install-and-configure-direnv-with-mise-skeleton

Dans ce second skeleton, direnv est installé avec Mise, voir le fichier racine ./.mise.toml.

Dans cette note, je souhaite expliquer pourquoi j'utilise et j'aime utiliser direnv.

Je suis toujours en train d'essayer de créer des development kit me permettant de travailler dans un environnements de développement toujours plus agréable.

J'ai découvert direnv en 2017 et j'ai commencé à l'utiliser dans un projet en avril 2019.

direnv s'utilise dans un shell, il charge et décharge automatiquement les variables d'environnement spécifiées dans un fichier .envrc lorsqu'on entre et quitte un répertoire.

Exemple :

Voici les use cases listées sur le site officiel de direnv :

• Load 12factor apps environment variables
• Create per-project isolated development environments
• Load secrets for deployment

Voici quelques exemples concrets de mon utilisation de direnv :

• chargement automatique des paramètres de configuration et secret pour :
  • la cli de Scaleway
  • terraform
  • Grizzly

source .secret

export SCW_DEFAULT_ORGANIZATION_ID="...." # Get it, in https://console.scaleway.com/organization/settings
export SCW_ACCESS_KEY="..."

# This variable environments are used by Grafana Grizzly
export GRAFANA_URL=http://grafana.$(terraform output --json | jq -r '.server3_public_ip | .value').nip.io
export GRAFANA_USER=admin
export GRAFANA_TOKEN=password

• dans un projet Javascript :

export POSTGRES_ADMIN_URL="postgres://postgres:password@localhost:5432/myapp"
export POSTGRES_URL="postgres://webapp:password@localhost:5432/myapp"
export SMTP_HOST="127.0.0.1"
export SMTP_PORT="1025"
export SECRET="secret"
export APP_HOSTNAME="localhost"
export MAIL_FROM="noreply@example.com"

Les fichiers .envrc sont des scripts shell, il est possible comme dans l'exemple au-dessus, d'utiliser source .secret pour charger un autre fichier.

Je versionne toujours le fichier .envrc, tandis que j'ignore (.gitignore) les fichiers .secret contenant des informations sensibles qui ne doivent pas être publiés dans le repository git.

Après avoir installé un development kit, j'indique à l'utilisateur les instructions à suivre pour installer les éléments de base du projet, comme Mise, Docker…, et la mise en place des secrets.

Mon objectif est ensuite de permettre à l'utilisateur de l'environnement de développement d'interagir avec des « scripts helpers » sans nécessiter de configuration préalable, simplement en entrant ou sortant des dossiers. Les dossiers sont utilisés comme « workspace contexte ».

Voir aussi : development kit skeleton d'installation de direnv

Je pense que je m'intéresse au sujet des "development environment" ou development kit depuis 1999.

À l'époque, même si je ne connaissais pas encore ces concepts, j'en ressentais déjà le besoin.

Par exemple, lorsque j'ai voulu contribuer au projet KDE, je cherchais des solutions et des bonnes pratiques pour organiser ma station de travail de manière à pouvoir compiler et installer KDE sans risquer de casser mon environnement de bureau.
Malheureusement, je n'y suis pas parvenu 😔.

Avec le recul, je réalise que ces pratiques étaient souvent transmises de manière informelle, principalement par des échanges oraux ou via des messages sur IRC. En somme, il s'agissait d'un véritable "bouche-à-oreille" numérique.

Je pense que la majorité des développeurs devaient faire face aux mêmes difficultés. Je pense aussi qu’ils devaient prendre beaucoup de temps à trouver leur propre méthode, année après année.

J’en ai eu une fois la confirmation. En 2002, je suis allé au FOSDEM, pour rencontrer entre autres David Faure, un core développeur français de KDE.

J’ai échangé avec lui et il m’a montré de nombreuses astuces qu’il utilisait… je n’ai pas tout compris, je n’ai pas réussi à les retenir…

J’en ai conclu que les développeurs avaient sans doute chacun leurs propres méthodes de développement non documentées.

Question qui me vient alors à l’esprit : alors qu'ils contribuent à des logiciels libres et partagent leur code source, pourquoi les développeurs ne partagent-ils pas aussi leurs environnements de développement ?

Je viens de réfléchir à l'usage des termes "development environment" et "development kit".

Je pense que le dépôt gitlab-development-kit est un "development kit" qui permet d'installer et configurer un "development environment" pour travailler sur le projet GitLab.

Je suis en train d'implémenter un repository playground privé pour un client et je me demande comment bien nommer les choses.

Je souhaite implémenter dans ce playground, des dossiers qui permettent d'interagir avec différents types d'instance.

Je me suis interrogé sur les notions de « environnement » et « d'instance ». Je connais ces termes, mais j'ai souhaité étudier leur différence avec précision.

Environnement :

• Article Wiktionary français : environnement

(Informatique) Ensemble des matériels et logiciels sur lesquels sont exécutés les programmes d'une application.

• "On travaille dans un environnement Linux."

• Article Wiktionary français : environment

(Informatique) Environnement.

• "The primary prompt is changed to help us remember that this session is inside a chroot environment."

• Article Wikipedia anglais : Runtime environment

In computer programming, a runtime system or runtime environment is a sub-system that exists in the computer where a program is created, as well as in the computers where the program is intended to be run.

• Article Wikipedia anglais : Deployment environment

In software deployment, an environment or tier is a computer system or set of systems in which a computer program or software component is deployed and executed. In simple cases, such as developing and immediately executing a program on the same machine, there may be a single environment, but in industrial use, the development environment (where changes are originally made) and production environment (what end users use) are separated, often with several stages in between. This structured release management process allows phased deployment (rollout), testing, and rollback in case of problems.

Instance :

• Article Wiktionary Français : instance

(Réseaux informatiques) Copie d’un logiciel fournissant un service sur un réseau.

• "PeerTube est un logiciel. Ce logiciel, des personnes spécialisées (disons… Bernadette, l’université X et le club de karaté Y) peuvent l’installer sur un serveur. Cela donnera une « instance », c’est à dire un hébergement de PeerTube. Concrètement, héberger une instance crée un site web (disons BernadetTube.fr, UniversiTube.org ou KarateTube.net) sur lequel on peut regarder des vidéos et créer un compte pour interagir ou uploader ses propres contenus."

• Article Wikipedia Anglais : instance

• Instance (computer science), referring to any running process or to an object as an instance of a class.
• Instance can refer to a single virtual machine in a virtualized or cloud computing environment that provides operating-system-level virtualization.

ChatGPT me dit :

Dans un contexte DevOps, les termes environment et instance font référence à des concepts distincts :

• Un environment regroupe les ressources et la configuration nécessaires pour une étape spécifique du cycle de vie de développement.
• Une instance est une unité d'exécution de l'application, isolée, et potentiellement en plusieurs exemplaires au sein d'un même environnement.

---

À la suite de cette réflexion, j'ai implémenté un exemple de repository contenant plusieurs workspaces, permettant d'interagir avec des instances de différents types d'environnement.

Repository : project-workspaces-skeleton

Je l'ai organisé de la façon suivante :

$ tree
├── development
│   ├── local-workspace
│   │   └── README.md
│   └── remote-workspace
│       └── README.md
├── production
│   ├── local-workspace
│   │   └── README.md
│   └── remote-workspace
│       └── README.md
├── README.md
└── staging
    ├── local-workspace
    │   └── README.md
    └── remote-workspace
        └── README.md

Voici quelques extraits du contenu des README.md.

development/local-workspace/README.md :

Local development environment workspace

Introduction

This workspace allows you locally launch the equivalent of remote development environment instances (applications, databases, etc.), within the GitOps paradigm.

This workspace provides scripts for injecting and initializing a database with demo data, or for copying the contents of remote instances to the local database.

This workspace is the right place if you want to work (fix bug, improve…) in isolation (without disturbing your colleagues) on development-type configuration changes.

This workspace is also useful for tinkering to better understand how this environment works.

Workspace configuration

...

production/remote-workspace/README.md :

Remote production environment workspace

Be careful when using scripts in this workspace, as you risk breaking production instances!

Introduction

This workspace allows you to interact with remote production environment instances (applications, databases, etc.) within the GitOps paradigm.

This workspace is designed, among other things, to store the configuration of production instances.
It includes scripts for deploying this configuration to remote instances and analysing the differences between the theoretical or desired configuration and that actually deployed.
With Git, these configurations are versioned, making it possible to track changes made over time on these instances.
Furthermore, this paradigm allows modifications to be proposed in the form of Pull Requests, simplifying collaborative work.

Workspace configuration

...

Je pense que ce skeleton va me servir de base pour de futurs repository de projets.

Je garde trace dans cette notes de deux plugins Asdf / Mise que j'ai utilisé avec succès ces deux derniers jours.

Le premier, pour installer la cli de Hasura : asdf-hasura

$ mise plugin add hasura-cli https://github.com/gurukulkarni/asdf-hasura.git

Contenu de .mise.toml :

[tools]
hasura-cli = "2.43.0"

$ mise install
$ hasura version
INFO hasura cli                                    version=v2.43.0

Le second, pour installer Gitleaks : asdf-gitleaks

$ mise plugin add gitleaks https://github.com/jmcvetta/asdf-gitleaks.git

Contenu de .mise.toml :

[tools]
gitleaks = "8.21.2"

$ mise install
$ gitleaks --version
gitleaks version 8.21.2

J'ai commencé à migré un projet de asdf vers rtx (ancien nom de Mise).

Cela fait des mois que je me demande comment nommer le repository #Git « chapeau », « umbrella » qui est le starting point d'une boite ou d'un projet.

J'ai trouvé une réponse chez GitLab, {compagny_name}-development-kit : https://gitlab.com/gitlab-org/gitlab-development-kit.

Ce repository est un "development kit".

#JaiDécouvert direnv : Automating development environment set-up with Direnv.

Ubi est un "tooling version management".

Dépôt GitHub : https://github.com/houseabsolute/ubi

Mise est un "tooling version management", il permet d'installer la plupart des outils nécessaire au bon fonctionnement d'un development environment. Il permet de "pin" les versions précises de ces outils.

Avec direnv et Docker, Mise fait parti des briques de fondactions que j'utilise pour créer mes development kit.

Site officiel : https://mise.jdx.dev

Alternative à Asdf et aqua

https://github.com/asdf-vm/asdf

Voir aussi les alternatives : Mise et aqua.

vfox est un tooling version management implémenté en Golang.

Dépôt GitHub : https://github.com/version-fox/vfox

Outil de gestion de development kit, créé en novembre 2022, basé sur Nix.

Quelques outils utiles aux development kit.

Les "Version Managers" :

• Asdf (en Bash)
• Mise (en Rust)
• aqua (en Golang)
• Ubi (en Rust)
• vfox (en Golang)