2017-07-30 6 views
0

Il y a quelques modules que j'ai écrits que je veux souvent copier dans d'autres projets pour réutiliser le code. Cependant, si je copie simplement les modules, alors si jamais je veux les améliorer, je devrais mettre à jour toutes les copies dans les différents dépôts git pour les projets qui les utilisent.Réutilisation du code Haskell dans plusieurs projets

Il semble que je devrais créer une sorte de bibliothèque. Comment puis-je configurer mes projets de telle sorte que je n'ai besoin de mettre à jour ces modules qu'une seule fois, et que tous les dépôts qui en dépendent auront accès à la nouvelle version?

+0

Qu'est-ce que vous utilisez pour créer votre code? Pile ou Cabale? – arrowd

+0

Vous pouvez créer des liens (si votre système de fichiers le supporte) vers les fichiers, de sorte que le mettre à jour à un endroit signifie également qu'il est mis à jour à d'autres endroits. –

+0

@arrowd Cabal, bien que cela puisse changer je suppose –

Répondre

6

Regroupez les modules dans des packages (ou éventuellement créez des packages à module unique). Si vous ne l'avez pas déjà fait, read the Cabal user guide. Chaque paquet, comme n'importe quel autre code, devrait être sous contrôle de version (git, darcs, peu importe) bien que ce ne soit pas strictement nécessaire pour votre besoin.

Disons que vous avez un tel paquet, foo, contenant les modules Common.Foo et Common.Foo.Types, à savoir que vous avez un dossier contenant Common/Foo.hs et Common/Foo/Types.hs et un fichier foo.cabal avec exposed-modules: Common.Foo Common.Foo.Types.

Les projets dans lesquels vous souhaitez utiliser Common.Foo devrait alors également être des paquets cabale et, en dehors de la import Common.Foo évidente dans les fichiers source Haskell, devrait avoir un fichier .cabal avec build-depends: foo.

Ensuite, chaque fois que vous avez changé les modules du paquet foo, vous pouvez taper cabal install --force-reinstalls (à l'intérieur foo répertoire s). Cela mettra à jour le registre de package local et lorsque vous aurez cabal configure et cabal build un autre projet utilisant foo, il aura accès aux modifications.

Il faut aussi considérer en fait publishing your package on Hackage (bien sûr, assurez-vous de donner réellement un clair, descriptif nom!), Alors vous aurez même pas à vous soucier de la source et la compilation lorsque vous passez à une autre machine - cabale peut le faire pour vous.


Le --force-reinstalls est seulement nécessaire une fois que vous avez aussi install ed l'un des paquets qui dépendent de foo. Après avoir réinstallé foo, vous devez ensuite puis également les reconstruire - c'est un peu un défaut dans la façon dont les registres d'installation cabal s'installe. Ce sera become unnecessary dans le futur.

+0

Donc le paquet dépendant sera capable de trouver 'foo' parce qu'il est entré dans ce" registre de paquet local "? –

+0

C o r r e c t. – leftaroundabout

+0

Peut-être saisis-tu l'occasion de mentionner "pile"? – SwiftsNamesake

2

En plus de @ leftroundabout d'excellente réponse, il y a une autre façon d'ajouter des dépendances locales à l'aide stack en ajoutant le chemin de votre stack.yaml:

flags: {} 
packages: 
- '.' 
- location: path/to/my/incredible/haskell/goodies 
- location: 
    git: url/to/my/fp/repository 
    commit: [commit-hash] 
    extra-dep: true 
[etc., etc.] 

En supposant que vous ne l'avez pas entendu parler de cet outil déjà (qui principalement résout le problème infâme cabale-enfer), je recommande fortement de le vérifier.