2010-11-30 45 views
7

J'ai plusieurs modules CPAN qui utilisent largement la métaprogrammation pour réduire la plaque de chaudière et faciliter le refactoring. La conséquence de ceci est cependant qu'il y a beaucoup de paquets qui sont créés par programmation, donc il n'y a jamais une ligne package X::Y::Z; dans le code source pour trouver CPAN (et ensuite utiliser pour ajouter l'espace de noms à votre liste de premier arrivé de espaces de noms réservés). Donc, ma question est de savoir s'il existe un moyen privilégié pour informer le CPAN de ces paquets créés à l'exécution. Voici les options que je suis en train d'examiner:Comment savoir CPAN (Perl) sur les paquets créés avec la méta-programmation?

  • rechercher manuellement vers le bas tous les paquets et créer un fichier pm factice pour CPAN à l'index.
  • Recherchez manuellement puis mettez à jour Build.PL pour les inclure dans la liste provides.
  • Ajouter un code aux routines méta-programmation pour garder une trace des paquets sont utilisés, et ajouter un crochet dans la build dist mettre à jour le provides ou d'une autre section de META.yaml

La dernière option est actuellement ce Je penche vers. J'aimerais savoir s'il y a des problèmes avec cette approche, ou de meilleurs moyens de garder le CPAN à jour avec la liste complète des paquets.

Répondre

4

Si je vous lis correctement, il s'agit d'un non-problème, à condition que vous n'obstruiez pas d'autres espaces de noms. Il n'y a pas de pré-requis pour déclarer chaque espace de noms créé, seulement l'espace de noms de base de votre distribution et les fichiers associés à la distribution. Si vous souhaitez "réserver" certains espaces de noms, au lieu de créer des fichiers .pm vierges, regardez plutôt la création de fichiers .pod et de document.

+0

Au moins dans le cas de mon pire délinquant 'List :: Gen' aucun des paquets créés à l'exécution ne contient des fonctions qu'un utilisateur final devrait jamais appeler directement. Il n'est donc pas vraiment logique de leur fournir la documentation de l'utilisateur final. Je sais qu'il n'est pas nécessaire de déclarer tous les noms de paquets, mais je me suis dit que le fait de laisser PAUSE en parler était la «meilleure» pratique. –

+0

Tous les PAUSE se soucient de ce que les fichiers appropriés (META.yml/.json, MANIFEST, etc) sont présents et correctement formatés. Une fois que vous avez un espace de noms, ce que vous y faites est votre préoccupation et non les autres, à moins qu'ils n'aient la permission de contribuer dans votre espace de noms. Tant que vous expliquez dans votre documentation que les espaces de noms sont générés automatiquement, vous avez fait votre part. – squeeks

+0

=> en êtes-vous sûr? Selon le blog de brian d foy (http://www.effectiveperlprogramming.com/blog/884): Lorsque PAUSE vous attribue un espace de noms en tant que responsable principal, vous ne "possédez" que cet espace de noms. Bien que les espaces de noms Perl semblent être hiérarchiques, ils ne le sont pas. Autrement dit, rien dans Perl ne se soucie de l'espace de noms que vous utilisez ou de celui dont votre paquet hérite. Les espaces de noms XML :: Simple n'hérite pas de XML en raison de son nom. De la même manière, vous n'avez aucune autorisation sur Foo :: Bar :: Baz simplement parce que PAUSE vous a assigné des permissions sur Foo :: Bar. –