 Bonsoir tout le monde, j'ai vous présenter mon talk de Python Canada en version un peu plus courte que ce que ce sera dimanche et en français. So this will happen again in a longer version on Sunday in English. Pour ce soir en français entre nous. Je vais vous présenter non pas l'historique, non pas les problèmes, mais plutôt des... Comment tu es de packaging de nos jours ? De façon simple, c'est de vrai que je suis d'intéressant pour différents publics. Selon votre niveau, ou si vous revenez dans quelques mois, le but c'est que ça dise clairement comment quelque chose fonctionne selon votre besoin. Ça c'est ma compagnie, on fait du web, donc toutes les parties de ça. La spécialité Python mais aussi front-end, web ou natif. On va chez des compagnie pour les aider à faire leurs produits où on développe totalement quelque chose. C'est pas même parler après, si ça vous intéresse, c'est encore une coopérative et différente d'une autre type de compagnie. On va se lancer tout de suite dans des définitions. Quand on parle de packaging, il y a l'idée que j'ai écrit mon code. Imaginez que mon projet est comme ça, j'appelle ça Rainbow. Le but, ça me tient une decommande où je peux pipez l'autre bout d'une autre commande et je veux avoir des couleurs comme ça. C'est un projet qui existe déjà, mais imaginons que je l'ai écrit. Avec mon projet à moi, il y a son code source. Entre autres, classique. Un module Python qu'il y a des sous-modules qu'on appelle un package. Il y a aussi besoin d'un fichier de données qui est utilisé par le termes pour mettre les bons codes selon les types de terminaux. J'ai les tests à côté. J'utilise pas les tests pour ça, ce que j'aime bien. J'utilise stocks aussi. Je reste avec plusieurs versions de Python en même temps. Et puis j'ai mis un readme qui est affiché dans GitHub. Puis j'ai affiché exemple parce que c'est pratique. C'est comme une petite doc, je n'ai pas le temps de faire mieux. Puis ça, c'est à la droite, c'est ce qu'il fait. Donc les couleurs de l'arc-en-ciel. Le but du packaging, c'est de dire de mon code source dans mon dépôt en local, je l'envoyer quelque part, un dépôt centralisé pour que d'autres personnes puissent le télécharger ensuite. Donc cette partie-là, je ne vais pas en parler. Il y a beaucoup de tutos de nos jours. Vous intérez Python dans le texte standard, vous avez PIP. Il y a un truc qui s'appelle Ensure PIP, qui dit au cas où ce n'est pas déjà installé, il y a de quoi pour le bootstrapper. Il y a un installer pour l'installer qui permet de dire, j'installe Python, j'installe PIP, je suis prêt. Je peux créer un environnement virtuel, il y a d'autres docs qui parlent de ça. Je peux utiliser PIP pour installer quelque chose. Non, parce que cette partie-là fait qu'on va séparer les tâches. Package, c'est-à-dire prendre tous ces fichiers et puis en faire une chose, comme un zip que je mets dans un email. Et puis distribuer, c'est le rente disponible sur PyPI, l'index des paquets Python. Puis ensuite, l'autre partie, c'est l'installation. Là, cet exemple pour la première partie, c'est un projet simple. Ensuite, on parlera de projet compliqué, puis à la fin de l'application web complète. Donc pour des projets simples, on a un outil extrêmement sympathique, ça s'appelle Fleet. Là, j'assume que vous n'avez jamais fait ça, vous ne connaissez pas de choses différentes. Dans mon terminal, je commence à faire Fleet in it et j'ai copié ça plus tôt. Il a par exemple détecté que mon module s'appelle Rainbow, ce qu'on fait import rainbow, donc il va m'appeler le paquet distribuable rainbow aussi. Ça me va. C'est quoi mon nom, mon email ? Il faut mettre une home page, ça pourrait être le dépôt, ça pourrait être la documentation quand je l'aurais fait. Là, j'ai mis une valeur demi. Puis on n'oublie pas la licence. Fait que si je n'ai pas trop d'opinion, je peux aller regarder le site web qui est en lien, choosealessons.com, où je choisis la licence qui a le moindre restriction. Avec ça, il y a un fichier écrit qui s'appelle pyproject.2ml. On va regarder son contenu tout de suite. C'est un genre de mélange entre le fichier et le format INI. Il n'y a pas très bien définé, il y a 50 formats INI ou CFG dans la bibliothèque standard de Python. Ça s'appelle config parser pour ceux qui connaissent ça. Mais c'est un peu plus sympathique, c'est plus structuré. Ça, par exemple, c'est une liste. C'est plus une question de, est-ce que j'ai un solidline ou un virgule, point virgule, etc. C'est un type qui est dans le format 2ml. La première ligne, ça, c'est aussi une liste. Et puis on pourrait avoir d'autres choses. Je pense qu'il y a des boléins ou des entiers qu'on n'utilise pas dans ce cas-là. Là, j'ai juste modifié deux ou trois choses. Je peux lire plus de documentation chez Fleet pour me dire, les classifier me permettent d'apparaître dans la recherche par catégorie. Je peux dire, ceci est un outil stable. C'est pour des développeurs. C'est pour tout le monde. C'est un ligne de commande. Ça marche sur Linux. Je n'ai pas le temps de le faire fonctionner avec les terminaux pour Mac. Je peux mettre un tas de métadonnées qui apparaissent ensuite dans la recherche sur pipi.org. J'ai besoin de faire deux autres choses d'après la doc de Fleet. Donc, à l'intérieur de mon module, j'ai écrit une doc string et je mets une version. Donc, une variable magique avec les deux underscores. En général, quand il y a deux underscores, c'est Python qui définit qu'est-ce que ça veut dire. Dans ce cas-là, c'est une convention utilisée par différents outils. Puis, la beauté de la chose, c'est que je modifie la version ici. Ça va changer automatiquement l'artefact, le zip que Fleet va me construire. Avec d'autres outils, il y aurait deux endroits différents. Et puis, la première ligne de la doc string va devenir la description courte du projet. Sur pipi.org, chaque projet a un nom, une version, une description en une ligne et puis une description plus longue. Avec Fleet, on écrit les choses une seule fois. La première ligne de la doc string du module importable devient description courte. Puis, on fait chez readme. Alors, là, c'est readme.md sans breakdown. Ça pourrait être readme.rst, l'autre format populaire chez les pitoneux. Ça va être pris tout seul. Fait que j'ai écrit ici, là, j'ai readme.rst. Alors, je me suis trompé. Ça devrait être readme.md dans mon exemple fictif. Et puis, sur pipi, ça va être transformé en HTML. C'est assez récent. Avant, ça a été obligatoirement rst. Depuis peu, vous pouvez avoir un fichier Mcdown. Ça s'affiche beau dans GitHub et ça s'affiche beau dans pipi. En plus de ça, s'il est invalide, Fleet va me prévenir dire, je ne peux pas prendre ton fichier rst pour être face. Ça va briser plus tard sur pipi et que je suis prévenu en avance. Avec les plus anciens parmi vous, savent qu'on a passé 10 ans à avoir ces problèmes-là. Puis, si on commence aujourd'hui, ça n'existe plus. À partir de cette configuration-là, je peux rouler les commandes tels que FleetBuild. Dans mon terminal, je vois ça. Je dis, ok, je m'as construit une wheel. Tantôt, je donne un exemple qu'on peut distribuer de façon simpliste en zippant tous mes fichiers de code source puis en les envoyant par email. Un fichier wheel, c'est assez semblable. On garde à l'intérieur. Vous voyez le code source de mon module, Rainbows et ce sous-module. On a aussi le fichier de données, le definition.json, qui a besoin d'être là parce que mon module terme, on a besoin. Et puis, distinfo, c'est ça qui fait que, si je fais pip list ou pip install Rainbows, il va me dire Rainbows est déjà installé ou elle veut tu upgrader telle version à telle version, parce que le fichier metadata va contenir toutes les informations structurées que le système de packaging de Python a besoin. Ça, c'est des formats qui sont standardisés. On va faire quelque chose avec, mais vous avez une vingtaine d'outils qui font des choses différentes. Il n'y a pas API qui est capable de dire ce module dépend de celui-là. Il y a GitHub qui va vous dire votre projet dépend de ce projet tiers qui a une faille de dépendance. Vous devriez mettre à jour. Il y a PKG Info qui va dire en local, ceci dépend de ceci et ainsi de suite. Avec tous ces fichiers-là, regarde le contenu du répertoire distinfo. Quand je fais pip install, j'utilise le wheel. Il me dit, est-ce que le wheel est compatible avec mon système ? Dans le monde fichier, il voit que jouer avec Python 3, c'est compatible. Je roule Linux telle version, mais on s'en fiche. C'est un fichier simple. C'est juste du Python. Ça marche partout. C'est une wheel qui s'installe chez tout le monde. Windows, Mac, 32 bits, 64 bits, peu importe. PIP install, à partir de ce fichier-là, qui est sur pipi.org, on peut les importer. Copier les métads donnés à l'endroit où les divers outils savent lire le fichier metadata pour se dire qu'est-ce qu'il est là. Le fichier record est intéressant. Il va contenir la liste de tous les fichiers installés. C'est ça qui permet de désinstaller. Croyez-le ou pas, pendant longtemps, on ne pouvait pas désinstaller de quoi en Python. Il fallait fouiller après les fichiers ou tout effacer à partir de zéro. On va aussi créer une Sdist. Une Sdist, c'est une source distribution. Qu'est-ce que ça contient ? Beaucoup plus de choses. En fait, ça contient tout ce qu'il y est dans mon depot-guide ou mon répertoire que je suis en train de travailler. Le code source, encore une fois, les tests. Ce n'est pas metadata, cette fois-ci. C'est pkginfo, c'est un autre format. Il y a mon pyproject.2ml qui permet d'y requer à partir de la Sdist, comment je fais pour avoir le format installable qui est uniquement ces fichiers-là. Dans la Sdist, j'ai beaucoup plus de choses. Mais on a quand même tous les fichiers, l'essence est là, le rythmie, l'exemple et le filet de JSON. Avec d'autres outils, vous parliez des heures ou des journées parce qu'il faut faire de quoi des encantations magiques pour avoir l'exemple inclus ou le définition.json. Il y a autre chose à la fin toujours. Si j'avais la Sdist sans cette dernière ligne, je faisais pip install cette Sdist ou que mettons debian, package, mon projet. Je ne parle pas de la wheel, debian veut partir du code source, debian veut contrôler le build complet du projet 2.0. Il faut publier une Sdist. Si je n'avais pas le 7.py grec, pip n'est pas encore capable de dire que dans pyproject.2ml, il y a la documentation de les flits pour créer une wheel de mon projet. La Sdist est transformée en wheel. Pour mesure de compatibilité juste pour 2018, Flit nous a créé un setup.py grec qui permet que pip sache installer cette Sdist. Ce que ça va en gros, mon but c'est que si vous débutez, vous dites pas de problème, je vais aller chercher la dog de Flit et puis je vais suivre ça, je vais le reproduire moi-même et là je vais avoir un tas de questions. Je me rends compte que si les tests sont dans le module rainbow, tout ça est dans la wheel. Je vais mettre les tests à côté du package comme ça ils seront dans la Sdist parce que ça fait partie de la source mais pas dans la wheel parce qu'on s'en fiche de les installer. Et puis vous pourrez par vous-même voir la documentation de Flit et puis je n'ai pas mis d'exemple là de la sortie de Flit Publish. On a créé une wheel, on a créé une Sdist. On sait d'avance qu'il y a bien une version, le fichier markdown est correct. Ensuite avec Flit Publish, ces deux fichiers là le targe z qui est la Sdist et puis la wheel, vont se retrouver sur pipi.org. On a fait notre partie du travail, on a fait package et distribute. Pour des projets qui existent, pour des projets qui ont un module écréancé, qui est automatiquement transformé en code machine, capable de l'importer, ou des projets scientifiques qui ont des besoins de build compliqués ou des pré-processeurs comme Citon qui a un genre de hybride entre piton et C qui fait que sans apprendre tous les détails du C, on peut accélérer des modules. Certaines ont besoin de compliqués, ou des projets qui existent, qu'on ne pas le changer de tous leurs outils. Là on va utiliser setup tools. Pour revenir à la définition initiale du projet simple, aussi un projet moins simple. Dans mon code sur, j'ai un module que j'ai écréancé qui fait que s'il est importable il me redéfinit certaines choses en termes.py grec pour que ma commande aille beaucoup plus vite. Ça pourrait être du go, ça pourrait être du rust. Tout ces choses là peuvent être transformées en code machine que piton s'est importé. Là on ajoute une nouvelle étape. C'est le build. On ne peut pas juste copier les fichiers. L'installation n'est pas uniquement. J'ai 4 modules pg grec, un file JSON et le distinfo. Je vais le copier dans le site packages. Il faut builder. La méthode classique c'est de faire une osdiste qui contient le fichier.c et à l'installation j'utilise des biens pour que j'aie les libres et les compilateurs. Pas de problème, pip télécharge la osdiste voie le fichier.c et d'après les instructions dans le setup.py grec crée un fichier.so qui fonctionne. Sur mon collègue avec Max ça marche pas. Il n'a pas le compilateur ou les options ne sont pas compatibles. Une alternative qui est plus moderne c'est de builder dans les wills on comprend on inclut tous les fichiers déjà installables. Au moment du build on prépare une will pour Linux AMD64 qui va contenir un fichier compilé qui fonctionne sur cette os. Avec des outils, des services d'intégration qu'on peut utiliser gratuitement je veux qu'à chaque fois que je fais une release j'ai une machine virtual mac qui me build le fichier.c en so pour les mac et là je publie une will qui a dans le nom de fichier par exemple rainbow 0.2 py grec 3 macOS puis macOS 10.6 ou 10.7 ou la version qui est compatible il y a un tas d'infrastructures que des gens ont fait pour qu'on puisse créer des wills compatibles avec 10 versions différentes de Linux ou macOS récent ou Windows 3060 4 bit donc sur votre projet vous pouvez utiliser ces systèmes branchés sur github pour créer des wills et les publier comme ça c'est directement installable sur les ordinateurs des collègues ou sur les serveurs qui n'ont pas les compilateurs d'installer la will contient les modules natifs par contre il faut écrire ce fameux setup en py pendant longtemps on n'avait que ça avant 1999 on n'avait rien c'est quand même beaucoup mieux le problème c'est que c'est du code piton arbitraire sur n'importe quelle machine qui installe une sd il pourrait se passer de n'importe quoi là-dedans il pourrait y avoir des dépendances qui sont cachées par un if ce n'est pas du tout déterministe ce n'est pas du tout sécurisé et puis selon qui roule ce script donc setup.py grec sd on sait pas c'est quoi le résultat et dans le fichier produit les métadonnées ne vont pas forcément être les mêmes par contre on a quand même donc si vous avez un projet qui existe puis que vous utilisez setup tools parce que c'est le standard actuel il y a quand même des choses nouvelles donc là vous voyez par exemple que je dois ouvrir le fichier with me moi-même pour l'inclure comme ma description long mais ça c'est une nouveauté c'est le long description content type je n'ai pas l'objet d'avoir du rst qui est transformé en html je peux avoir mon remy markdown et pypy va être capable de transformer en html bien rendu c'est une petite nouveauté bon par contre setup.py grec on voit toujours des documentations là-dessus mais des fois il faut mettre deux lignes dans un setup.cfg par exemple si je veux que ma wheel dire qu'elle fonctionne autant sur piton 2 que piton 3 j'ai besoin de deux lignes spéciales dans setup.cfg et puis tout le monde tous les projets du monde depuis 10 ans qui utilisent setup tools ils ont les problèmes de manifest.in si j'avais fait ce script là équivalent pour mon rainbow c'est sûr que ma première version je n'aurais pas eu le exemple pour un py grec c'est dommage ça explique comment utiliser mon projet ou je n'aurais pas eu le definition.json à l'intérieur de mon sdst ça me prend de ok je vais ajouter une ligne qui va dire include package data ou alors j'installe la plugin qui fait qu'automatiquement setup tools va regarder qu'est-ce que j'ai dans mon depot guide fleet fait ça de base depuis 2016 setup tools c'est dit effectivement c'est pas excellent d'écrire des scripts non déterministes pour avoir toutes nos informations c'est que c'est possible d'écrire la plupart des choses dans le fichier cfg donc le fameux format ini là vous voyez long description provient de mon fichier readme il va automatiquement dire si c'est .rst je dis à pipi de le parser comme du rst si c'est md ça va être du markdown je vais mettre mes listes de classifier et puis copier coller ces lignes là d'un projet à l'autre sans vraiment savoir ce que ça veut dire mais entre autres include package data c'est ça qui va me faire avoir mon definition.json dans mon projet sinon ça marche pas même moi il y a 2 mois j'ai pas fait le manifest.in et puis il m'a manqué mes templates Django dans mon petit projet l'avantage c'est que le setup.py donc la partie qui est du code arbitraire c'est juste de lignes ce que setup.tools depuis 2016 peut lire les métadonnées ici ça fait que c'est un chemin vers l'avant et sans doute d'ici l'année prochaine setup.tools sera dans pyproject.tuml comme flit, juste des options différentes et pip dira nice pyproject.tuml je sais comment installer flit ou installer setup.tools ou installer mon outil spécifique à malib scientifique et à partir de ces différents systèmes de build faire une wheel donc ça pour illustrer que flit un outil pour des projets simples setup.tools beaucoup plus de puissance pour des projets plus compliqués ou des projets existants il y a quand même une interface qui converge et pip sera capable de tout installer maintenant je voudrais parler des applis web donc là on n'est plus tout dans le même cas là mon projet contient un type code oui mais je veux le voir sur un ou des serveurs pour qu'ensuite n'importe qui s'y connecte c'est déployer le code de mon projet qui dépend lui-même de 25 autres librairies si j'utilise hero-coup j'ai besoin juste d'écrire quelques fichiers je vous laisserai chercher par vous-même si vous ne connaissez pas mais en gros c'est un système qui fonctionne avec guide push donc en faisant le guide push vers hero-coup ils vont automatiquement installer mes dépendances depuis un fichier requirements ça c'est un format inventé par pip dans un autre fichier run-time.txt je veux telle version de piton puis dans un fichier proc file je dis roule ses commandes quand on déploie et puis roule ses commandes pour avoir mon server web qui est prêt à répondre le problème de ça je me dis ok admettons il y a un fichier de requirements si j'écris juste les choses que moi j'emporte j'ai écrit 5 lignes c'est un petit cms donc j'utilise jango cms et puis le thème bootstrap sauf que ça c'est pas une installation déterministe ces 6 lignes là dépendent en arrière de 18 autres libres je suis comme ok, d'après la doc hero-coup il faut écrire les requirements frozen donc j'installe ces choses là mais par les dépendances qui ont des dépendances ça m'installe en fin de compte une hist longue comme le bras d'un tas de projets, un tas de versions et puis ça je l'appelle requirements.txt je le commis dans mon dépôt et puis hero-coup install avec pip install sauf que ce fichier là il me terrifie je suis plus amé capable de le mettre à jour j'ai une alerte qui me dit jango cms text secator telle version à telle file de sécurité ou telle autre libre à telle nouvelle feature en telle version mais si je mets à jour le jango cms column pour la nouvelle feature est-ce que ça va briser autre chose qui en dépend c'est que le modèle de faire pip install quelque chose, ça met à jour de quoi on sait pas si c'est compatible ou pas puis ensuite pip freeze pour faire ça clairement ça fonctionne pas je vais continuer en 2-3 minutes pour faire ça mon but ce serait d'avoir les deux choses je voudrais que moi je modifie les choses que j'importe directement je veux jango cms 3.4 c'est compatible avec 3.4 je sais que je dois changer mon code pour que ça fonctionne par contre jango cms google map je m'en fiche un outil qui s'appelle pip compile qui dit d'un fichier que les humains modifient je produis un fichier qui contient toutes les dépendances les versions exactes qui dépendent quoi et puis on peut même avoir des haches qui sont la somme de contrôle du fichier installable sdist ou will pour s'assurer que si quelqu'un attaque pipi ou votre réseau vous n'allez pas installer des choses malisseuses sur votre serveur mais avec ça c'est parfait si je supprime une des extensions de jango cms le faire pip compile il va me l'enlever du fichier requirements.txt mais aussi ses dépendances dont rien d'autre ne dépend je vous laisserai lire sa documentation l'outil s'appelle pip tools ça fournit pip compile et pip sync un site un article intéressant qui dit ok c'est quoi ça marche comment je change ma façon de travailler ça fonctionne très bien je mentionne brièvement la première fois que vous convertissez votre fichier de 50 lignes en deux fichiers différents le point in et le texte pip depth tree et un excellent outil pour dire qu'est ce que je dois mettre dans mon fichier point in mon projet doit ajouter jango cms extension extension 2 qui eux même dépendent d'autres choses ça m'intéresse pas les installés je les installe parce que ce sont des dépendances de dépendance pip depth tree je peux voir ok ça est installé à cause de ceci et puis voici me dire il y a des versions qui sont incompatibles il va me permettre de résoudre les conflits de version je mentionne brièvement safety installer le rouler safety check il va vous dire mais à jour ces choses là c'est important dans le futur brièvement ça pourrait être encore mieux je n'ai pas parlé des environnements virtuels je n'ai pas parlé de comment choisir ce que je roule piton 2 ou piton 3 parce que ce n'est pas intégré actuellement on a des outils de virtual env des outils d'installation des outils de build ce n'est pas pareil dans le futur on va avoir quelque chose qui est comme on a en rust ou en javascript on fait npm add enfin yarn add ceci il a la fois ajouté dans le fichier point in pour moi et compilé dans le point texte on pourrait dire ce projet a besoin de piton telle version tout ça pour être intégré il y a des gens qui travaillent à des outils pipon on est un poetry on est un autre qui vont aller plus loin que ce que je vous ai montré aujourd'hui puis ils rendent ça encore plus pratique en gérant tous les aspects du développement lisez ces choses là le packaging user guide et une ressource qui a manqué pendant longtemps ça explique tous les scénarios un peu les 3 types d'app que j'ai mentionné et puis si vous voulez plonger plus en profondeur c'est toi que là ou ces vidéos parle de tas de sujets reliés je vous remercie et je suis prêt à prendre des questions la question est imaginons qu'il y a un projet qui n'est pas packaging il est pas sur pipi, mais il est installé dans un Pogit si je fais pip install dans mon terminal je peux faire pip install guide plus l'adresse est-ce que c'est compatible avec fleet je remontre mon exemple de pip project to ml fait que oui ici j'aurai une liste ici qui serait requires chacrine contient des requirements les requirements ont été inventés par pip mais ont été de plus standardisées donc si j'écris mon projet égal et égal telle version il y a une définition claire de qu'est-ce que ça veut dire j'écris mon projet super à cette version inférieure à tel autre tous les outils ça trahit avec et si j'écris requires guide plus ceci j'ai pas testé ça et en fait c'est une bonne question est-ce que fleet imprémente tous les types de requirements ça ne m'étonnerait pas parce que tous ces outils utilisent en général en coulisses une libre de base c'est pas le packaging c'est que la version savoir que 4.10 c'est plus grand que 4.1 et ainsi de suite c'est un format implanté par une petite libre le fait que les requirements puissent commencer par guide soit c'est une extension de pip dans ce cas là il n'y a pas de chance si ça ne marche pas soit soit ça fonctionne directement c'est une bonne question the question is what are my thoughts on the pip file format which is an alternative to the pip requirements files I've shown pip file format is implemented it's supposed to be a new standard so you should be able to use different tools to manage it in the future pip ant and pip ant wants to be like npm or cargo it's one file that describes I need this to develop like this test runner and this local server and I need this all the time for my app like the basic requirements also the Python version and also handles the virtual environment the format is interesting cause you have these sections like this is a dev requirement don't install it on my server this is a test requirement like install it locally to work and this is like runtime requirements always install them I don't like that it's limited at least in the pip ant implementation you only have like a dev test and runtime and I want more like I want some things only for my continuous integration environment I want something only on my servers but not for tests and not for my coworkers like I use 5 or 6 categories and I can have 6 different files dot i n and then 6 txt and then the pip ant tool itself is still maturing and building its community and I'm waiting for 2020 to give it a go so pip freeze is what you used before you have pip tools like you run pip install one thing in your terminal but you don't know if it's going to break something that's already installed or if it's like you install some Django CMS extension version 3 but you already installed something before that can't work if it's more than version 2 and with current pip nobody tells you this pip does not include a dependency solver it's like the latest install wins so instead of pip install things manually then maybe it works locally maybe you get warnings and then you run pip freeze and you have this big text file I don't know which is depending on which modify an int file and then pip compile frozen txt file will work that's pip file.loc that's what the previous question was about with another tool like there's poetry and there's pip ant you write what you need in a pip file and it gets reified into a longer pip file.loc just like in other languages and it's a nice experience cause you don't change a text file you just say okay pip ant add this thing and add the version that's compatible with what I have like do it for me and that's in the future yeah, I'll be at the Benelux