Les datadir sont supposés être des dépôts git

[paternal]

Dans patacrep, les datadirs sont n'importe quel dossier, et il n'est nul part mentionné que ces dossiers doivent être gérés par git, et encore moins qu'ils doivent être la racine d'un dépôt git.

Par contre, cette supposition est faite dans patanet : generator/songs.py. À cet endroit, le chemin d'une chanson est défini comme le chemin relatif à la racine du projet git. Plus tard, dans generator/views/songs.py, on construit le chemin absolu de la chanson comme SONGS_LIBRARY_DIR + 'songs' + songs.file_path. Cela est incohérent, et ne fonctionnera pas si SONGS_LIBRARY_DIR n'est pas le dépôt d'un dépôt git.

Ce qu'il faut faire est :

• dans generator/songs.py : supprimer la référence au dépôt git.
  • Pour le chemin, on prend le chemin relatif au datadir.
  • Pour le hash, soit on calcule un hash md5, soit... je ne sais pas. Cette clef n'a l'air d'être utilisée nulle part ailleurs. À quoi sert-elle ?
• dans generator/views/songs.py, on fait, comme c'est le cas, référence au datadir.

Ou alors préciser (et vérifier, et lever une erreur au lancement de l'application) que les datadirs doivent être la racine d'un dépôt git.

Autre question : À quoi correspond SONGS_LIBRARY_DIR ? Si c'est un DATADIR, pourquoi avoir changé le nom ?
Autre question : Est-il prévu d'autoriser plusieurs datadir ? Dans ce cas, il faudrait remplacer SONGS_LIBRARY_DIR par DATADIRS, qui serait alors une liste de répertoires, et modifier ailleurs dans le code toutes les références à SONGS_LIBRARY_DIR.

[oliverpool]

La gestion de plusieurs dossiers contenant des chansons n'est pas encore clairement résolu.
lorsque j'écris dossier, cela peut vouloir dire dépôt git
On y a un peu pensé, mais cela soulève pas mal de problèmes.

Par exemple, cela nécéssite de stocker dans la BDD à quel dossier appartient quelle chanson.
Par ailleurs, que faire si une chanson est présente dans deux dossiers ?
...

bref, je pense qu'on peut se limite à un seul dossier pour l'instant,
mais il faut effectivement faire quelque chose de cohérent concernant la gestion de celui-ci.

[Soundy25]

Je ne sais pas si c'est approprié, mais je suis actuellement dans une réflexion peut-être similaire pour une GED.
Pourquoi ne pas préférer un système de tag qui permet une relation 1 chanson à n tags (genre, style, époque) ?
D'après ce que j'ai compris, il n'y a pas de problématique de hiérarchie ici... (Dossier Parent --> Dossier Enfant --> Dossier Ptt enfant ...

[Luthaf]

Autre question : Est-il prévu d'autoriser plusieurs datadir ?

Oui, c'est ma prochaine tache dans 3 semaines.

Ou alors préciser (et vérifier, et lever une erreur au lancement de l'application) que les datadirs doivent être la racine d'un dépôt git.

Pour l'instant, ils doivent etre des dossiers git car ce n'est que la premiere version. Cela va sans doutes evoluer.

Edit : en fait non, on a besoin de git pour la gestion des versions.

Pour le hash, soit on calcule un hash md5, soit... je ne sais pas. Cette clef n'a l'air d'être utilisée nulle part ailleurs. À quoi sert-elle ?

Il servira plus tard, a effectuer les mises a jour en BDD.

Je ne sais pas si c'est approprié, mais je suis actuellement dans une réflexion peut-être similaire pour une GED.
Pourquoi ne pas préférer un système de tag qui permet une relation 1 chanson à n tags (genre, style, époque) ?

Tu peut develloper un peu ? Je ne vois pas trop ce que tu veux dire.

[paternal]

Un autre problème, en lien avec celui-là (je peux créer un autre ticket si nécessaire) est que si deux chansons ont le même titre, une seule des deux apparait. C'est un comportement non souhaité, car rien n'interdit que deux chansons différentes aient le même titre (exemples).

Je n'ai pas regardé la base de donnée, mais je suppose que la clef qui identifie de manière unique une chanson dans la base est actuellement le titre. Pour corriger cela, il suffit de faire en sorte que cette clef soit le nom du fichier.

Et pour la gestion des datadirs, on peut considérer comme clef le couple (datadir, chemin). Comme ça :

• on se débarrasse de la nécessité du dépôt git ;
• on est sûr que deux chansons correspondant à des fichiers différents apparaissent deux fois dans la base.

Par contre, ça veut dire que si un jour on autorise autre chose qu'un datadir ou un nom de fichier comme source des chansons, cela ne fonctionne plus.

[Soundy25]

Tu peux développer un peu ? Je ne vois pas trop ce que tu veux dire.
Lol, d'où ma réserve...

Je dit en réponse à << cela nécessite de stocker dans la BDD à quel dossier appartient quelle chanson. Par ailleurs, que faire si une chanson est présente dans deux dossiers ?>>

Comme on ne se connait pas et que je ne connais pas le modèle de données, je reformule depuis le tout début quitte à enfoncer des portes ouvertes...
A quoi sert le dossier ?
Si vous parlez de l'archi de l'appli ou des données, mon commentaire n'est peut-être pas bien à propos. Je parle de l'aspect fonctionnel et de l’interfaçage du point... "une chanson est présente dans deux dossiers". Si deux (ou dix) membres proposent le même titre (dans une tonalité identique ou distincte), dans quel "dossier" le titre sera-t-il classé ? Que donnera l'affichage d'une recherche sur ce titre ?

Dans les systèmes GED habituels, les éléments sont stockés dans une arborescences de répertoires à n niveaux, qui sous-entend :

1. un lien hiérarchique entre les répertoires parents et enfants
   Ex : Dans Windows, C:\Windows\Program files ==> "Program files" est l'ENFANT de "Windows" & "Windows" est le PARENT de "Program files".
2. l'impossibilité de stocker deux éléments portant le même nom à un même répertoire.
   Ex : Le répertoire "Program file" ne peut être l'enfant que de "Windows" et pas d'un autre répertoire en même temps, Il n'y a pas de liens symboliques/d'alias dans les systèmes de GED classique (à vérifier). http://fr.wikipedia.org/wiki/Lien_symbolique

Les systèmes de tags (étiquettes en Français) permettent quant à eux d'attribuer plusieurs tags à un même élément… mais ne "hiérarchisent" pas les ressources entre elles.
Ainsi, les 2 titres "Africa" peuvent être tous les deux indéxés/décrits comme suit :
a) id(124); title(africa); artist(Rose Laurens); date(1982); tag_(Variété, Francophone, 80s)
b) id(658); title(africa); artist(Toto); date(1982); tag_(80s, Rock, Anglophone, Groupe, Musique du monde)
*les clés étrangères de ces valeurs, bien sûr... ^^

L'avantage du tag, c'est qu'il permet également de proposer un système de recherche & de navigation intuitif. En cliquant sur le tag "80s", je m'attends à voir la liste de tous les titres tagués avec "80s".

[paternal]

@Soundy25 Le fait qu'une chanson = un fichier placé quelque part dans l'arborescence est du au fait que patanet n'est pas un projet isolé : il utilise la bibliothèque patacrep, créée plusieurs années plus tôt, et qui elle fonctionne en assemblant plusieurs fichiers de chansons pour en faire un carnet de chants. Le choix a également été fait de faire un système qui s'appuie sur les fichiers de chansons de patadata, et qui bénéficie de ses améliorations.

Stocker les chants purement dans une base de données (sans arborescence de fichiers) aurait peut-être été le choix fait si patanet avait été créée ex-nihilo, mais ça n'est pas le cas, et changer de paradigme nécessiterait pas mal de boulot. Après, on peut aussi imaginer d'autres altenatives (pour conserver patacrep) :

• inverser le paradigme : on considère que c'est la BDD de patanet qui est la référence des chansons, et des fichiers sont créés (avec comme nom de fichier un hash quelconque). Il faut alors gérer l'intégration des modifications de patadata ;
• Se débarrasser complètement des fichiers, et faire une classe dérivant de SongRenderer, dont la méthode render() ne produise pas un \input{...}, mais inclue directement le contenu du fichier. Mais avec ça, on se désolidarise encore plus de patadata.
• On peut aussi envisager de conserver la méthode actuelle, en ajoutant des tags aux chansons. Côté patacrep, cela pourrait être fait simplement en ajoutant un argument tags à la commande \beginsong (par exemple \beginsong{Africa}[by={Rose Laurens},tags={Variété, Francophone, 80s}]).

Je pense que si patanet avait été créée ex-nihilo, comme un projet indépendant, la solution pure BDD aurait été meilleure. Mais vu l'histoire, et le lien avec patacrep et patadata, la solution actuelle est loin d'être mauvaise.

Ainsi, les 2 titres "Africa" peuvent être tous les deux indéxés/décrits comme suit :

Avoir plusieurs chansons ayant le même nom n'est pour moi pas un problème, puisque le nom du fichier n'est, pour pataweb, qu'une clef utilisée en interne, et pour patacrep, qu'un moyen de désigner la chanson, mais qui n'apparait pas dans le carnet final. Ainsi, on peut nommer nos fichiers africa1.sg et africa2.sg, ou <titre>-<auteur>.sg, ou un hash quelconque, ou n'importe quoi d'autre, sans que cela ait de répercussion sur l'utilisateur final (puisqu'encore une fois, utiliser des fichiers n'interdit pas d'utiliser aussi des tags).

[Soundy25]

Très bien, merci Paternal pour ce retour aux racines du projet... ^^

[Luthaf]

Les datadirs sont des dépôts git pour gerer le versionnement des fichiers de chants tout en permettant une édition en ligne des paroles/accords.

Ou alors préciser (et vérifier, et lever une erreur au lancement de l'application) que les datadirs doivent être la racine d'un dépôt git.

Je pense que c'est en effet le mieux à faire dans ce cas. Il faudra de toute manière faire des vérifications sur les datadirs si on en a plusieurs, on effectuera cette verification en même temps.