Feature/#13 Ajout d'un .gitattributes pour que ça fonctionne sur Windows

Finalement cette modification n'est peut-être pas nécessaire.

En effet, j'ai découvert que la commande docker-compose build jupyter_deno est exécutable depuis un cmd.exe sur windows, sans ouvrir un wsl. Et depuis tout fonctionne parfaitement, même sur le commit 39b55c2463d83e2994b3d35de2db3e81ac4dd0b4 qui n'a pas le .gitattributes.

Ceci dit, ça ne mangerait pas de pain de mettre le .gitattributes.

Je propose donc d'attendre un peu avant d'accepter cette pull request

Si finalement, après test, c'est bien nécessaire.

En effet, sous Windows :

On supprime tous les fichiers dans decoder-leco\poc-data-visualization\oci\deno-jupyter, puis qu'
on fait un checkout de a9344826cc6818b167fae8c5c5aa1e5112cb2ee9, puis
docker-compose build jupyter_deno

On obtient l'erreur suivante :

 => [jupyter_deno add_r_kernel 2/8] WORKDIR /kernels/ops/                                                                                      0.0s
 => [jupyter_deno add_r_kernel 3/8] COPY add-rlang-kernel.sh .                                                                                 0.0s
 => ERROR [jupyter_deno add_r_kernel 4/8] RUN chmod +x ./add-rlang-kernel.sh && ./add-rlang-kernel.sh                                          0.4s
------
 > [jupyter_deno add_r_kernel 4/8] RUN chmod +x ./add-rlang-kernel.sh && ./add-rlang-kernel.sh:
0.374 /bin/sh: 1: ./add-rlang-kernel.sh: not found
------
failed to solve: process "/bin/sh -c chmod +x ./add-rlang-kernel.sh && ./add-rlang-kernel.sh" did not complete successfully: exit code: 127

ANALYSE

En effet, si on fait : git ls-files --eol

On obtient :

i/none  w/none  attr/                   .keep
i/lf    w/crlf  attr/                   Dockerfile
i/lf    w/crlf  attr/                   README.md
i/lf    w/crlf  attr/                   add-rlang-kernel.sh
i/lf    w/crlf  attr/                   register.r.ikernel.previous.sh
i/lf    w/crlf  attr/                   register.r.ikernel.sh
i/none  w/none  attr/                   requirements.rise.txt
i/none  w/none  attr/                   requirements.txt
i/lf    w/crlf  attr/                   rise.Dockerfile
i/lf    w/crlf  attr/                   start.debug.sh
i/lf    w/crlf  attr/                   start.sh

On voit que les fichier .sh ont été checkoutés en CRLF dans la Working Directory (Cf w/crlf) au lieu de LF.

Si on revient au commit : c929f34c5b0ee3596ac1d92a93d60a6d4fff2869

Et qu'on refait la même manip (en supprimant les fichiers pour qu'ils soient effectivement restaurés), on obtient :

i/none  w/none  attr/text=auto          .keep
i/lf    w/crlf  attr/text=auto          Dockerfile
i/lf    w/crlf  attr/text=auto          README.md
i/lf    w/lf    attr/text eol=lf        add-rlang-kernel.sh
i/lf    w/lf    attr/text eol=lf        register.r.ikernel.previous.sh
i/lf    w/lf    attr/text eol=lf        register.r.ikernel.sh
i/none  w/none  attr/text=auto          requirements.rise.txt
i/none  w/none  attr/text=auto          requirements.txt
i/lf    w/crlf  attr/text=auto          rise.Dockerfile
i/lf    w/lf    attr/text eol=lf        start.debug.sh
i/lf    w/lf    attr/text eol=lf        start.sh

Et on arrive alors à builder l'image


 => [jupyter_deno add_r_kernel 6/8] COPY ./register.r.ikernel.sh .                                                 0.0s
 => [jupyter_deno add_r_kernel 7/8] RUN chmod +x ./register.r.ikernel.sh && ./register.r.ikernel.sh              187.0s
 => [jupyter_deno add_r_kernel 8/8] WORKDIR /usr/dataviz/notebooks/decoderleco                                     0.0s
 => [jupyter_deno] exporting to image                                                                              5.2s
 => => exporting layers                                                                                            5.2s
 => => writing image sha256:89b9f7b57911d62eb759291dad9ee166b2c3496376e81f339857098a7726e681                       0.0s
 => => naming to docker.io/decoderleco/deno-jupyter:0.0.1-alpha                                                    0.0s

Donc il faut bien intégrer la feature/#13_sh_lf pour que ça fonctionne sur Windows.

@JeanGarf vu pour les tests que tu as faits, afin de comprendre ce qui se produisait sur ta machine Windows.

Trois choses:

Comme je l'avais un peu rapidement fait remarqué, lorsque l'on installe git sur windows, il y a une option qui est active par défaut, pour faire la conversion des EOL de windows à Linux et réciproquement, justement pour que les utilisateurs de Git ne rencontrent pas cette erreur que tu as eue. Je suppose donc que tu n'as pas laissé cette configuration active. J'imagine
La configuration de git, doit pour moi rester quelque chose que chaque utilisateur fait, à sa guise: introduire une configuration git des EOL ne peut qu'être ambiguë. La configuration que tu as spécifiée déterminée comme celle convenant à ta machine, doit aller dans ton ~/.gitconfig , et tu peux l'y ajouter comme ceci dans git bash for windows :

# https://git-scm.com/docs/git-config#Documentation/git-config.txt-coreattributesFile

mkdir -p ~/.jg.config/ici/je/choisis/de/mettre/ma/config.git/
git config --global core.attributesFile ~/.jg.config/ici/je/choisis/de/mettre/ma/config.git/attributes

cat <<EOF >~/.jg.config/ici/je/choisis/de/mettre/ma/config.git/attributes

#
# Text files
#

# Set default behavior to automatically normalize line endings.
# In git repository, it is stored as LF, but when checkouting, it becomes CRLF on Windows and LF on Linux
* text=auto

# Force batch scripts to always use CRLF line endings so that if a repo is accessed
# in Windows via a file share from Linux, the scripts will work.
*.{cmd,[cC][mM][dD]} text eol=crlf
*.{bat,[bB][aA][tT]} text eol=crlf
*.{ps1,[pP][sS]1}    text eol=crlf

# Force bash scripts to always use LF line endings so that if a repo is accessed
# in Unix via a file share from Windows, the scripts will work.
*.sh text eol=lf
EOF

# et cette config de git attributes te restera personnelle et s'appliquera par défaut à tout les repos que tu vas git clone

Enfin:
- surtout pour tout ce qui est conteneurs, ce sera un requirement que l'utilisateur fasse tourner dans un linux, si windows, ce devra être WSL, ou une VM Linux avec un autre technologie de virtualisation. Windows ne fait qu'apporter des problèmes avec les conteneurs, et je n'ai jamais vu un seul projet où ils fassent le support windows pour Docker. D'ailleurs sans même Docker, je crois que je n'ai jamais vu un seul projet avec n repo où ils aient dedans un .gitattributes
- de plus je suis en train de terminer de multiples automatisations pour pouvoir obtenir le déploiement complet dans une VM à la fois virtualbox et dans un cloud: Pierre ira directement dans son browser pour utiliser Jupyter, et ceux qui veulent absolument déployer eux-mêmes auront n moyen qui créera automatiquement la VM ils n'auront qu'à installer VirtualBox ce qui est très simple, pour ceux qui insistent pour déployer sur leurs propres machines on prem.

Pour toutes ces raisons, pas de fichier gitattributes dans ce repo.

Tu indiques :

il y a une option qui est active par défaut, pour faire la conversion des EOL de windows à Linux et réciproquement, justement pour que les utilisateurs de Git ne rencontrent pas cette erreur que tu as eue. Je suppose donc que tu n'as pas laissé cette configuration active. J'imagine

Si tu penses à autocrlf, c'est bien à true sur mon poste.

D'ailleurs sans même Docker, je crois que je n'ai jamais vu un seul projet avec n repo où ils aient dedans un .gitattributes

Et pourtant, même sur la documentation de GitHub (https://docs.github.com/en/get-started/getting-started-with-git/configuring-git-to-handle-line-endings) on trouve ceci :

When you commit this file to a repository, it overrides the core.autocrlf setting for all repository contributors. This ensures consistent behavior for all users, regardless of their Git settings and environment.

Or il me semble que c'est un de nos objectifs.

Je trouverais ça dommage de ne pas faciliter la vie des utilisateurs Windows qui sont somme toute... assez nombreux.

decoder-leco / poc-data-visualization

Feature/#13 Ajout d'un .gitattributes pour que ça fonctionne sur Windows #19