Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Gérer plusieurs datadir #43

Closed
Luthaf opened this issue May 29, 2014 · 15 comments
Closed

Gérer plusieurs datadir #43

Luthaf opened this issue May 29, 2014 · 15 comments
Milestone

Comments

@Luthaf
Copy link
Contributor

Luthaf commented May 29, 2014

Il pourrait être utile d'inclure dans un seul carnet des chants provenant de plusieurs bases de données (songbook-data, mes chants persos, ...). Je propose donc de transformer datadir en une liste, et d'aller chercher les chemins vers les fichiers de chants dans lors de la création de ContentList de la manière suivante :

  • Si le fichier existe dans le premier chemin de datadir, on prend celui-ci ;
  • S'il n'existe pas, on recherche dans les autres valeurs, dans l'ordre ;
  • S'il n'existe toujours pas, on lève l'exception "the regex does not match any file"
@paternal
Copy link
Contributor

J'avais aussi ça en tête.
👍

@paternal paternal added this to the 4.0 milestone May 29, 2014
@jmclem
Copy link
Contributor

jmclem commented May 29, 2014

A-t-on besoin d'un datadir pour les chants? Ne serait-il pas plus simple de mettre pour chaque chant le chemin relatif ou absolu ?

@Luthaf
Copy link
Contributor Author

Luthaf commented May 29, 2014

C'est possible aussi, l'avantage de l'utilisation de datadir permet d'avoir d'autre fichiers en plus des .sg : code LaTeX divers, images, ...

@jmclem
Copy link
Contributor

jmclem commented May 30, 2014

C'est possible aussi, l'avantage de l'utilisation de datadir permet d'avoir d'autre fichiers en plus des .sg : code LaTeX divers, images, ...

pourquoi est-il nécessaire d'avoir un datadir pour ça ?

@paternal
Copy link
Contributor

pourquoi est-il nécessaire d'avoir un datadir pour ça ?

Ça n'est pas nécessaire, mais ça permet ça, et ça peut être assez pratique. En fait, les répertoires des chansons, templates, latex, sont relatifs à datadir (datadir/songs, datadir/latex, datadir/templates). Donc en permettant plusieurs datadir, on permet d'avoir plusieurs de ces répertoires d'un coup.
En particulier, un utilisateur peut installer songbook-data quelque part, et avoir son carnet personnel à côté (avec des chants en plus), et mettre dans datadir ["personnel", "..../songbook-data"]. Comme ça, il peut inclure dans son carnet à la fois des données de songbook-data, sans modifier le dépôt (et gêner les updates ultérieurs), et des données personnelles.

D'autre part, je pensais que datadir pourrait être, au choix (pour alléger la syntaxe dans le premier cas) :

  • une chaîne de caractère : c'est un unique répertoire ;
  • une liste : c'est une liste de répertoires.

Actuellement, on a déjà un peu ça dans la mesure où certains sous-répertoires du répertoire data de songbook-core sont déjà pris en compte. Donc si on implémente la liste des datadir, on pourra simplifier le code pour simplement ajouter songbook_core/data à la fin de la liste fournie par l'utilisateur, plutôt que les modifications actuelles.

@Luthaf
Copy link
Contributor Author

Luthaf commented May 30, 2014

J'ajouterai juste que du point de vue de songbook-core, un datadir (il faudrait trouver une traduction) n'est rien d'autre qu'un dossier qui respecte une certaine hiérarchie. Ce n'est pas nécessairement un dépôt git.

Donc si on implémente la liste des datadir, on pourra simplifier le code pour simplement ajouter songbook_core/data à la fin de la liste fournie par l'utilisateur, plutôt que les modifications actuelles.

En effet ! Et il suffirait d'ajouter des \input@path aux fichiers .tex pour récupérer les fichiers LaTeX.

@jmclem
Copy link
Contributor

jmclem commented May 30, 2014

OK pour la nécessité du datadir; Je me méfie un peu d'une seule stratégie de recherche basée sur l'ordre des datadir et aimerais avoir une possibilité de pointer explicitement un fichier d'un datadir particulier.

Par exemple : j'ai deux datadir, qui contiennent tous deux les chants "Petit papa Noël" et "Jingle Bells". Mais je veux avoir pour l'un la version du premier datadir, pour l'autre celle du second.

@Luthaf
Copy link
Contributor Author

Luthaf commented May 30, 2014

Cela peut être intéressant. Je vois deux manières de l’implémenter :

  • Un champ particulier dans content :
{
"content": [ "my/first/song.sg",
             "all/others/*",
            ["datadir", "/path/to/datadir3/", ["one/song/here.sg",
                                             "another/one.sg" 
                                                 ]
            ]
]
}

Dans ce cas, les deux premiers chants seraient cherches dans les datadirs donnés au début, et résolus dans l'ordre. Le troisième élément ajouterai deux chants d'un autre datadir.

  • En se basant sur une analyse des chansons ajoutées, pour déterminer s'il s'agit de chemins absolus ou relatifs.

Je préfère la première : plus générique, et moins verbeuse s'il y a beaucoup de chants de ce type. Mais plus verbeuse pour un ajout ponctuel.

PS : au passage, je me rend compte que la syntaxe pour content basée sur des listes n'est pas totalement satisfaisante si je veux passer un paramètre supplémentaire, ici /path/to/datadir3/. Il faudrait voir comment cela sera géré par les plugins de ContentList

@paternal
Copy link
Contributor

Plutôt que datadir, je préfère quelque chose de plus léger, et simple, comme cwd. Je trouve ton exemple peu clair, dans la mesure où le fichier est inclus est /path/to/datadir3/, puis songs, puis one/song/here.sg (il y a un songs qui a été ajouté, et peu utile en fait).
Avec un mot-clef cwd, la signification est simplement : ajouter le dossier au début du chemin inclus. Ainsi :

{
  "content": [
    "my/first/song.sg",
    "all/others/*",
    ["cwd", "/path/to/directory/", [
      "one/song/here.sg", "another/one.sg" 
      ] ]
    ]
}

inclus les chansons /path/to/directory/one/song/here.sg, etc.

Ceci n'exclut absolument pas de permettre, en plus, des chemins absolus dans les chansons, ce qui est, je pense, déjà permis vu l'implémentation qui est faite.

PS : au passage, je me rend compte que la syntaxe pour content basée sur des listes n'est pas totalement satisfaisante si je veux passer un paramètre supplémentaire, ici /path/to/datadir3/. Il faudrait voir comment cela sera géré par les plugins de ContentList

Aucun problème pour l'implémentation des plugins que j'ai en tête.

PS : J'aurai de temps courant juin pour implémenter pas mal de choses de ma todo liste.

@paternal paternal mentioned this issue May 30, 2014
@Luthaf
Copy link
Contributor Author

Luthaf commented Jun 1, 2014

Il y a deux problèmes ici :

  • La gestion de plusieurs datadir
  • La gestion de chants en dehors des datadir

Je me suis attaqué au premier, et j'ai une petite question à ce propos : lorsque l'utilisateur passe une valeur à datadir par la ligne de commande, que fait-on de ce valeur ? Je pense que le plus simple est de placer cette valeur au début de la liste des datadir : ainsi les chants sont pris en priorité dans ce datadir, mais les autres (définis dans le .sb) servent quand même pour trouver les chants qui manqueraient dans le datadir passé en ligne de commande.

@paternal
Copy link
Contributor

paternal commented Jun 1, 2014

Je me suis attaqué au premier, et j'ai une petite question à ce propos : lorsque l'utilisateur passe une valeur à datadir par la ligne de commande, que fait-on de ce valeur ? Je pense que le plus simple est de placer cette valeur au début de la liste des datadir : ainsi les chants sont pris en priorité dans ce datadir, mais les autres (définis dans le .sb) servent quand même pour trouver les chants qui manqueraient dans le datadir passé en ligne de commande.

Ça me paraît bien.

Une autre manière de voir les choses pour le type de contenu datadir (ta proposition ["datadir", "/path/to/datadir3/", ["one/song/here.sg", "another/one.sg" ]) : en faisant ça, on duplique de l'information de manière inutile : on a déjà défini que /path/to/datadir3 était un datadir ; si on le met à nouveau dans le contenu de type datadir, on n'a fait que dupliquer de l'information sans rien ajouter d'utile. C'est pour cela que je proposais, si on veut ajouter plusieurs chants qui ont une base commune, d'utiliser le type cwd, qui lui est indépendant d'un quelconque datadir, et donc ne duplique pas d'information.
Et encore une fois, pour les chemins absolus, je pense que c'est déjà pris en compte : pas besoin de changer quoi que ce soit (ou alors, je pense qu'il faudrait faire en sorte que ça soit pris en compte sans syntaxe spéciale).

@Luthaf
Copy link
Contributor Author

Luthaf commented Jun 1, 2014

Et encore une fois, pour les chemins absolus, je pense que c'est déjà pris en compte : pas besoin de changer quoi que ce soit (ou alors, je pense qu'il faudrait faire en sorte que ça soit pris en compte sans syntaxe spéciale).

Il faut juste modifier un poil ici. Pour le moment, on suppose qu'il s'agit d'une regex, et on y ajoute le datadir.

C'est pour cela que je proposais, si on veut ajouter plusieurs chants qui ont une base commune, d'utiliser le type cwd, qui lui est indépendant d'un quelconque datadir, et donc ne duplique pas d'information.

Ça me va parfaitement.

@paternal
Copy link
Contributor

paternal commented Jun 2, 2014

Il faut juste modifier un poil ici. Pour le moment, on suppose qu'il s'agit d'une regex, et on y ajoute le datadir.

Je viens d'essayer : ça fonctionne déjà. En fait, un os.path.join(chemin1, chemin2)chemin2 est un chemin absolu renvoie juste chemin2.

@Luthaf
Copy link
Contributor Author

Luthaf commented Jun 2, 2014

Ok, c'est cool ca ! Je termine la gestion de datadirs multiples, puis je te laisse la main avec ContentList.

@paternal
Copy link
Contributor

Fait : #45

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants