2013-03-03 17 views
48

Biorąc pod uwagę zestaw pakietów cabal, czy istnieje sposób automatycznego obliczania podzbioru niezależnych pakietów? Innymi słowy, podzbiór pakietów, które wystarczą, aby je wszystkie zainstalować.Niezależny podzbiór pakietów cabal set

Dla [network,parsec] odpowiedź brzmi: [network] ponieważ jest to network zależne od .

Dla [network,containers] odpowiedź jest [network,containers] ponieważ:

  • network nie zależy containers
  • wszystko network s zależnościami nie zależy containers
  • containers nie zależy network
  • wszystkich containers s zależności nie zależą od network

Nie jest trudno znaleźć odpowiedź na 2 paczki. Co jest naprawdę interesujące, to znaleźć niezależny zestaw dla [containers, directory, filepath, lens, xml, http-conduit, regex-posix, monad-control, unordered-containers, glib, hashable, hspec, split, aeson, attoparsec, stm, QuickCheck].


Od odpowiedzi spodziewam jakąś funkcję na podstawie cabal biblioteki jak ∷ [Packages] → IO [Packages].

+2

Wygląda na to, że 'Distribution.Client.PackageIndex.dependencyClosure' jest tym, czego potrzebujesz. –

+0

Masz na myśli ['Distribution.Simple.PackageIndex.dependencyClosure'] (http://hackage.haskell.org/packages/archive/Cabal/latest/doc/html/Distribution-Simple-PackageIndex.html#v:dependencyClosure) ? –

+1

Wersja cabit-install Git ('Distribution.Client. *') Również jest teraz biblioteką. –

Odpowiedz

1

Cabal przechodzi do modelu bardziej podobnego do NPM, co znacznie uprości rozwiązanie zależności. Każdy zainstalowany pakiet zachowa lokalną kopię swoich zależności, zajmując niewiele miejsca na dysku, co będzie przyczyną problemów związanych z instalowaniem wielu globalnych pakietów z wzajemnie wykluczającymi się wymaganiami dotyczącymi wersji pakietów.

W tym modelu podzbiór pakietów wymagany do zainstalowania zestawu pakietów == tego zestawu. Chociaż jedna z nich może być zależna od drugiej, każda zainstalowana kopia zachowa swoją własną lokalną kopię swoich zależności, więc Cabal nie będzie już rozważać zależności zainstalowanej w ten sposób.

+0

Gdzie (a -> b) oznacza "a" zależy od 'b'., co dzieje się, gdy instalujesz' a' gdzie (a -> b-0.9) i 'd' gdzie (d -> b-1,5)."a" i "d" obnażają typy typu b, ale typy zmieniły się z b-0.9 na b-1.5? Wiem, jak GHC sobie z tym poradzi, po prostu nie współpracują ze sobą, ponieważ są różnymi typami, faktycznie nawet gdy są zaimplementowane, ten sam ghc pozostaje bezpieczny i traktuje je jako różne, ponieważ pochodzą z różnych wersji. W jaki sposób NPM radzi sobie z tym problemem? – Davorak

+0

Mam nadzieję, że zaangażowane klasy danych Haskell/Node.js są używane tylko przez zależności niskiego poziomu, a nie przez całą aplikację. W Node.js klasy można definiować lokalnie, więc nie powinno to stanowić problemu, chyba że aplikacja próbuje komunikować obiekty z różnymi bibliotekami o różnych definicjach klas. To samo dotyczy Haskella, jak sądzę. – mcandre