OneFileLLM : agréger dépôts, articles et transcriptions en un seul XML pour le contexte d'un LLM

Le problème : rassembler des sources qui n'ont ni format ni emplacement communs

Un dépôt GitHub, un article arXiv, une transcription YouTube et un PDF local n'ont rien en commun sur le plan technique. Les récupérer demande autant de méthodes que de sources : API REST pour GitHub, téléchargement et extraction de texte pour arXiv, bibliothèque dédiée pour les transcriptions, lecture binaire pour les PDF. OneFileLLM prend cette diversité comme point de départ. La commande accepte en arguments positionnels des chemins locaux, des URL, ou des identifiants préfixés comme arxiv:1706.03762, doi:10.1038/s41586-021-03819-2 ou PMID:35177773, et produit un seul fichier XML structuré, recopié dans le presse-papiers. Le public visé est celui qui prépare manuellement un contexte à coller dans une interface de LLM, ou qui écrit des scripts d'ingestion et préfère un point d'entrée unique à une collection de fonctions maison. Le README résume l'objectif par la formule "Aggregate and structure multi-source data into a single XML file for LLM context".

Une seule commande, plusieurs détecteurs de source

Le mécanisme repose sur une détection du type d'entrée. Une URL GitHub contenant tree/main/whisper est reconnue comme un sous-répertoire d'un dépôt : le README précise que la portion tree/ est analysée et que la requête est envoyée avec un paramètre ref, ce qui permet de viser une branche ou un tag. Une URL d'issue accepte un paramètre state (all par défaut, open ou closed). Les identifiants préfixés (arxiv:, doi:, PMID:) déclenchent une résolution vers la source correspondante. Côté web, un crawler configurable prend le relais avec ses propres options. Toutes ces entrées sont ensuite réunies dans un même document XML. Ce qui distingue l'outil d'un simple script de téléchargement, c'est que la sortie est pensée pour être consommée directement : un seul bloc, délimité, copié automatiquement dans le presse-papiers. Le point de vigilance est que le format de sortie est fixe. Si votre pipeline attend du Markdown ou du JSON, vous devrez convertir le XML en aval.

Installation et exécution : pip, CLI éditable, jeton GitHub

Trois voies d'installation sont documentées. La première consiste à cloner le dépôt puis à lancer pip install -r requirements.txt. La deuxième installe le paquet publié : pip install onefilellm. La troisième, dans la racine du projet, exécute pip install -e ., ce qui installe le paquet en mode éditable et expose la commande onefilellm à la place de python onefilellm.py. Pour les appels à l'API GitHub, le README recommande d'exporter un jeton : export GITHUB_TOKEN="your_personal_access_token". Sans ce jeton, les requêtes restent possibles mais soumises aux limites de l'API non authentifiée. L'outil est aussi utilisable comme bibliothèque : from onefilellm import run, puis run(["./docs/"]). L'aide intégrée se consulte par --help-topic, avec les thèmes basic, aliases, crawling, pipelines, examples et config.

Le crawler web et ses réglages

La partie crawl est de loin la plus paramétrable, ce qui indique où se trouvent les cas difficiles. On y trouve --crawl-max-depth et --crawl-max-pages pour borner l'exploration, --crawl-delay et --crawl-concurrency pour réguler la charge envoyée au site, --crawl-include-pattern et --crawl-exclude-pattern pour filtrer les URL, --crawl-timeout pour la limite d'attente, --crawl-user-agent pour l'identification. Plusieurs options concernent le nettoyage du HTML : --crawl-no-clean-html, --crawl-no-strip-js, --crawl-no-strip-css, --crawl-no-strip-comments. La présence de --crawl-respect-robots, désactivé par défaut sur le plan du nommage, signifie que le respect du fichier robots.txt est un choix explicite. C'est un point à trancher consciemment : le comportement par défaut peut ne pas correspondre à ce que vous attendez d'un outil qui visite des sites tiers. Les PDF sont inclus par défaut (--crawl-no-include-pdfs pour les exclure), et les EPUB sont ignorés sauf désactivation de --crawl-no-ignore-epubs.

Les alias, ou comment mémoriser des ensembles de sources

Un alias est un nom associé à une ou plusieurs sources. La commande --alias-add mcp "https://github.com/anthropics/mcp" crée un raccourci simple ; --alias-add modern-web "https://github.com/facebook/react https://reactjs.org/docs/ https://github.com/vercel/next.js" en crée un qui combine trois sources. Les accolades ouvrent la voie à des alias paramétrés : --alias-add gh-search "https://github.com/search?q={}" puis l'appel avec la valeur à substituer. Les alias se gèrent par --alias-remove, --alias-list et --alias-list-core. L'intérêt pratique est de figer une combinaison de sources qu'on réutilise souvent, sans retaper les URL. La contrepartie est un état local persistant : les alias ne sont pas définis dans un fichier versionné avec le projet, ce qui complique leur reproduction sur une autre machine ou en intégration continue.

Ce que l'outil ne fait pas

Le README ne décrit aucune stratégie de découpage en jetons ni de gestion de fenêtre de contexte, alors que le sujet tiktoken figure parmi les topics du dépôt. L'utilisateur doit donc estimer lui-même si le XML produit tient dans la fenêtre du modèle visé. Autre limite : la sortie est monolithique. Chaque exécution reconstruit l'ensemble du document, sans mécanisme visible de mise à jour incrémentale d'une source déjà collectée. Si vous suivez un dépôt actif, vous recollectez tout à chaque fois. Enfin, la dépendance à Sci-Hub, mentionnée dans la description du dépôt, place l'outil dans une zone juridiquement incertaine selon les pays. Le README ne fournit aucun avertissement à ce sujet, ce qui est une lacune : un lecteur qui découvre l'outil par sa description n'a aucun élément pour évaluer ce point.

Face à un pipeline maison ou à un serveur MCP

L'alternative la plus directe n'est pas un autre outil mais un assemblage de scripts : appels à l'API GitHub, extraction PDF, récupération de transcriptions, chacun écrivant dans un fichier, puis une concaténation finale. Cette approche demande plus de code mais donne un contrôle total sur le format et permet de mettre en cache source par source. Un serveur MCP constitue une autre voie : au lieu de produire un fichier à coller, il expose les sources comme des outils que le modèle appelle à la demande. La différence d'architecture est nette. OneFileLLM matérialise un instantané complet avant l'échange avec le modèle ; un serveur MCP laisse le modèle choisir ce qu'il va chercher pendant l'échange. Le premier est plus simple à auditer, puisqu'on peut relire le XML avant de l'envoyer. Le second évite de transporter du contenu inutile. Le dépôt cite d'ailleurs des sources MCP dans ses exemples, sans trancher entre les deux approches.

Licence, maintenance et coût de mise à jour

Le projet est publié sous licence MIT, ce qui autorise la réutilisation, la modification et la redistribution y compris dans un contexte commercial, à condition de conserver l'avis de licence. Aucune version publiée n'est référencée dans les informations disponibles, donc le suivi des changements repose sur l'historique du dépôt plutôt que sur des notes de version. Le coût de mise à jour se concentre sur un point : les sites sources changent leurs formats et leurs API, et chaque changement demande une adaptation du code de collecte. Un utilisateur qui s'appuie sur plusieurs types de sources doit s'attendre à ce que la partie la plus fragile soit celle qu'il ne contrôle pas. La présence d'un paquet pip publié simplifie la mise à jour, mais elle crée aussi un décalage possible entre la version installée et celle du dépôt.

Conclusion éditoriale

OneFileLLM convient à qui doit régulièrement constituer un contexte à partir de sources dispersées et veut une seule commande plutôt qu'une chaîne de scripts. Il ne convient pas si vous avez besoin d'un contexte incrémental ou d'un graphe de dépendances : la sortie est un XML monolithique, régénéré à chaque appel. Avant d'adopter, vérifiez deux points précis : que la variable GITHUB_TOKEN est bien exportée, sinon les appels à l'API GitHub seront limités, et que le comportement de --crawl-respect-robots correspond à ce que vous attendez de vos propres crawls.

Sources officielles

1. Issues
2. jimmc414/onefilellm on GitHub
3. License: MIT
4. README