Dimitri Merejkowsky a écrit 19 commentaires

Est-ce bien pertinent d'ajouter une aussi grosse lib si ce n'est que pour utiliser une infime part de ses fonctionnalités ?

Clairement, non :)

Une forge qui mérite d'être mentionnée: sr.ht

Ce n'est pas encore ouvert au public cela dit.

La particularité de cette forge c'est que tout se passe par e-mail.

Vous pouvez lire les explications de l'auteur sur son blog:

• e-mail driven git
• Git is already distributed

Je trouve que c'est une approche vraiment intéressante.

Pour ceux qui ne l'auraient pas vue je recommande la vidéo de sa conférence au FOSDEM.

En go il y fzf, un "fuzzy finder" qui a l'avantage d'être utilisable à fois dans le terminal et dans (neo)vim.

Un article de blog qui m'avait bien plu à l'époque:

Get rid of syslog (or a journald log filter in ~100 lines of Python)

pyruse m'a l'air d'une solution bien plus flexible pour ce genre d'usage.

Merci de partager ton projet en tout cas :)

pour quelle raison ne pas les avoir réutilisés

Comme expliqué dans le commentaire ci-dessus: Quelle est la genèse du project , à l'origine il n'était pas prévu de ré-implémenter qisrc, c'était juste du code pour les scripts d'intégrations continue.

Ensuite, les frustrations autour de repo nous ont convaincus qu'il fallait changer d'outil, et j'ai profité de l'opportunité de recoder le projet "du début".

Qu'apporte tsrc que n'a pas qisrc ?

• qisrc est couplé à qibuild, qui est un framework de gestion de projets C++
• qisrc est intégré à Gerrit, alors que tsrc s'intègre à GitLab
• tsrc a un code beaucoup plus simple (7 fois moins de lignes que qisrc), et n'a gardé que l'essentiel des fonctionnalités.

Le fait que ça soit écrit par la même personne y est sûrement pour quelque chose :)

C'est pas le même workflow, pour employer un anglicisme.

Avec submodule, tu as un dépôt parent et tu figes les commits des dépôts fils.

C'est pratique quand tu veux re-compiler une lib dont tu as modifié les sources, ou quand tu veux factoriser du code entre plusieurs dépôts (les projets coreutils du gnu contiennent souvent un submodule gnulib, par exemple)

Avec tsrc, tous les projets sont au même niveau, et tu vas t'arranger pour avoir des branches ou des tags cohérents.

Par exemple, la branche 'master' de 'foo' sera toujours compatible avec la branche 'master' de 'bar', et donc
'tsrc sync' te laissera dans un état cohérent. Ou bien, si tu veux reproduire un bug de la version 42, tu peux faire tsrc foreach git reset --v0.42

Note également que l'approche "figer les commits des dépendances" fonctionne aussi dans tsrc depuis la version 0.2, puisque tu peux spécifier des 'fixed_ref' dans le fichier manifest.

Que signifie tsrc?

Le t est pour Tanker (cf https://tanker.io)
Le src est pour source, effectivement.

Quelle est la genèse de ce projet ?

Tout a commencé quand nous avons revu en profondeur les scripts utilisé pour l'intégration continue.

À l'époque, il y a avait des bouts de scripts .sh et .bat. pour cloner les dépôts sur les machines de la ferme de compilation, compiler et lancer les tests.

Pour des raisons de simplicité de maintenance, nous avons décidé d'exporter de les ré-écrire en Python.

Ensuite, nous avons découvert qu'il était souhaitable que les développeurs puissent facilement reproduire ce qui se passe pendant l'intégration continue sur leur propres machines.

Du coup, nous avons décidé d'exposer une partie des fonctionnalités des scripts de build (la gestion des sources, en l’occurrence) dans dans un outil en ligne de commande utilisable également par les développeurs de l'équipe.

En parlant avec d'autres développeurs, nous nous sommes rendu compte qu'il y avait une demande sur ce genre d'outils et avons décidé de le partager avec la communauté.

Cela sonne comme si on demandait Tes sources ?

C'est voulu :)

Qui a trouvé ce nom tsrc?

Moi ;)

Certes, mais nous assurons aussi la compatibilité sur Windows 7 et 8, le WSL (sauf erreur) ne marche que sur Windows 10.

D'autre part, nous essayons de minimiser le nombre d'outils à installer sur Windows (à la fois pour les développeurs et notre ferme de compilation), pour des questions d'efficacité et de maintenance.

(Tu serais surpris du nombre de développeurs Windows/C++ pour qui installer Python3 en plus de Visual Studio est déjà vu comme une contrainte :P )

Quelques éléments de réponse dans la faq.

En gros:

• Pas de support de Windows
• Comportement parfois surprenant et/ou destructif

Et une majorité de l'équipe préfère le mécanisme de merge requests à celui du fonctionnement par revue de patches individuels.

et on fait les ajustements nécessaires sur la partie build

C'est justement ça qu'on a pas envie de faire (voir ci-dessous)

Pourquoi pas monorepo ?

Version courte: pour des raisons historiques, d'intégration, et aussi un peu philosophiques.

Version longue:

• Raison historique: Avant, on avait nos dépendances C++ (les fichiers .so, .a, .dylib et tous leur headers) pré-compilées dans un gros dépôt git. Du coup comme le dépôt était gros toutes les opérations (git status, par exemple) prenait du temps. Du coup c'était pratique d'avoir un deuxième dépôts avec juste nos sources à nous. (Depuis on est passé à conan

• Intégration: nous utilisons gitlab-ci. Si tu as un seul dépôt qui mélange C++ et Javascript par exemple, il va falloir regarder quelle portion du code a été changée. (Lancer le build et les tests en C++ est long, et lancer tous les linters et les analyseurs statiques Javascript est long aussi: tu as envie de lancer uniquement ce qui concerne ce qui a changé. Du coup si t'es un peu obligé de hacker gitlab-ci pour rajouter ce genre de fonctionnalité.

• La dernière raison est plus subtile. L'idée c'est qu'on veut avoir un système qui tienne la route même avec beaucoup de projets et beaucoup de développeurs. La solution du mono-repo fonctionne mais demande du travail spécifique (les problème d'intégration continue et de performance des gestionnaires de code ne sont que des exemples parmi d'autres). Du coup la solution que nous choisissons se rapproche des modes de développement open-source (pensez à Gnome ou KDE et leur myriade de projets séparés), ce qui nous permet à la fois de bénéficier des outils existants, mais aussi de partager nos problèmes (et nos solutions) avec le reste de la communauté open source.

Arf. J'avais regardé ROS y a longtemps mais à l'époque la gestion des sources était très couplée au reste de l'écosystème ROS.

Tu sais si ça marche bien sous Windows aussi ? C'est une contrainte importante pour nous…

Ensuite après avoir lu la totalité de la news, je ne comprends pas quel est le problème de coder dans différents
langages et pourquoi cet outil résout ce problème.

Je vais essayer de clarifier en donnant plus de détails.

Chez Tanker nous avons plusieurs dépôts:

• Un client lourd en C++
• Des serveurs en Go
• Un SDK Javascript
• Des applications web (toujours en Javascript)
• De la documentation (avec mkdocs)
• Des scripts de déploiement et d'intégration continue (en Python)

Comme l'équipe maîtrise tous ces langages, il est pratique pour chaque développeur d'avoir toutes les sources en même temps sur sa machine.

De même, lorsqu'un nouveau projet est créé, il est pratique de lancer tsrc sync pour cloner le nouveau projet plutôt que d'aller chercher l'URL sur GitLab.

De plus, tsrc s'assure que les chemins relatifs entre projets sont toujours les mêmes.

Cela simplifie beaucoup de choses, notamment en Go, ou le langage impose des contraintes sur l'arborescence des fichiers, ou pour les scripts de déploiement (par exemple quand on veut générer la documentation avant de la déployer).

Enfin, avant chaque déploiement, nous pouvons lancer tsrc foreach -- git tag v0.2.0, ce qui nous permettra plus tard de savoir exactement le contenu de toutes les sources ayant participé à la génération de nos artefacts.

J’espère avoir été plus clair.

L'idée était de pouvoir conserver la configuration de ce workspace en un seul
fichier simple à lire et modifier. Le fichier de conf peut ensuite être
lui-même versionné dans git, afin de pouvoir reconstruire un environnement
cohérent versionné.

C'est exactement le fonctionnement de tsrc, oui. Le fichier en question (manifest.yml) est versionné dans le dépôt "manifest".

Est-il possible de spécifier une branche ou un tag au repo git qu'on veut cloner dans le workspace
La gestion des branches est implémentée depuis peu:
https://github.com/TankerApp/tsrc/pull/7

Pour les tags je vais ouvrir une issue sur github, il y a plusieurs façons d'aborder le problème.

Vous acceptez les contributions du coup?

Bien sûr. Tout le développement se fait en toute transparence sur github :)

CMake gère ça de base. Quand tu fais un include_directories() il va rajouter une dépendance vers les headers.
Il va aussi utiliser gcc -M pour se rendre compte que b.c dépend de a.h

est ce que ce gestionnaire est capable de gérer les dépendances déjà décrit en c++ avec les includes ?

Je comprends pas bien la question. Pour utiliser une librarie tierce en qibuild, le mieux c'est d'en faire un paquet binaire qu'on ajoute à une toolchain. Voir ici:
http://doc.aldebaran.lan/doc/next/qibuild/beginner/qitoolchain/tutorial.html

En gros y a juste un fichier cmake à écrire qui a cette tête la:

set(_root "${CMAKE_CURRENT_LIST_DIR}/../../..")
get_filename_component(_root ${_root} ABSOLUTE)

set(FOO_LIBRARIES
  ${_root}/lib/libfoo.so
  CACHE INTERNAL "" FORCE
)

set(FOO_INCLUDE_DIRS
  ${_root}/include
  CACHE INTERNAL "" FORCE
)

# qi_persistent_set(FOO_DEPENDS "BAR")
export_lib(FOO)

Effectivement qibuild et catkin ont beaucoup de points communs. Voici de la documentation expliquant les différences:
http://doc.aldebaran.com/qibuild/beginner/qibuild/other/ros.html

La principale force de qibuild est qu'il est distro-agnostique (on peut utiliser des paquets précompilés sur n'importe quelle distro), et qu'il a un vrai support de Mac et Windows (y compris Visual Studio)