2013-01-05 9 views
9

Lavorare con Cabal è così estenuante, ho in mano una copia del mio ultimo file .cabal funzionante in modo che quando alcuni altri pacchetti (in particolare eseguibili come hakyll, che richiede sempre una reinstallazione) siano interrotti, posso ricaricarlo dall'ultimo salvataggio .c'è una soluzione alternativa per la reinstallazione della Cabal?

Ma ancora non fanno alcune cose più facile perché non posso installare alcuni pacchetti senza installare completamente i miei pacchetti in ordine diverso (es. Il pacchetto che rompe gli altri dovrebbe essere installato prima di altri, ecc)

ad esempio, ecco cosa succede quando provo ad installare cabal-dev (che è un pacchetto molto importante per me):

➜ ~ cabal install cabal-dev 
Resolving dependencies... 
In order, the following would be installed: 
bytestring-0.9.2.1 (new version) 
containers-0.4.2.1 (new version) 
template-haskell-2.8.0.0 (reinstall) changes: containers-0.5.0.0 -> 0.4.2.1 
text-0.11.2.3 (reinstall) changes: bytestring-0.10.0.0 -> 0.9.2.1 
transformers-0.2.2.0 (new version) 
mtl-2.0.1.0 (new version) 
parsec-3.1.3 (reinstall) changes: bytestring-0.10.0.0 -> 0.9.2.1, mtl-2.1.2 -> 
2.0.1.0 
unix-2.3.2.0 (new version) 
directory-1.0.0.3 (new version) 
network-2.3.2.0 (new version) 
HTTP-4000.2.6 (reinstall) changes: bytestring-0.10.0.0 -> 0.9.2.1, mtl-2.1.2 
-> 2.0.1.0, network-2.4.0.1 -> 2.3.2.0 
process-1.1.0.2 (reinstall) changes: directory-1.2.0.0 -> 1.0.0.3, 
unix-2.6.0.0 -> 2.3.2.0 
Cabal-1.14.0 (new version) 
tar-0.3.2.0 (new package) 
zlib-0.5.4.0 (reinstall) changes: bytestring-0.10.0.0 -> 0.9.2.1 
cabal-dev-0.9.1 (new package) 
cabal: The following packages are likely to be broken by the reinstalls: 
shakespeare-1.0.2 
hamlet-1.1.2 
hakyll-3.5.2.0 
lens-3.7.1.2 
ghc-7.6.1 
haddock-2.13.1 
data-lens-template-2.1.7 
cmdargs-0.10.1 
hoogle-4.2.14 
QuickCheck-2.5.1.1 
Extra-1.46 
ipprint-0.4.2 
xml-1.3.12 
texmath-0.6.1.1 
pandoc-1.9.4.5 
wai-1.3.0.1 
warp-1.3.6 
tagsoup-0.12.8 
snap-server-0.9.2.4 
snap-core-0.9.2.2 
regex-tdfa-1.1.8 
Unixutils-1.52 
network-2.4.0.1 
simple-sendfile-0.2.10 
network-conduit-0.6.2.1 
citeproc-hs-0.3.6 
language-lua-0.1.4 
json-0.7 
highlighting-kate-0.5.3.3 
ddc-base-0.3.1.1 
ddc-driver-0.3.1.3 
ddc-core-simpl-0.3.1.1 
ddc-core-llvm-0.3.1.1 
ddc-build-0.3.1.3 
ddc-core-salt-0.3.1.1 
ddc-core-eval-0.3.1.1 
ddc-core-0.3.1.1 
http-types-0.7.3.0.1 
hexpat-0.20.3 
hashable-1.2.0.2 
vault-0.2.0.3 
unordered-containers-0.2.3.0 
uniplate-1.6.10 
case-insensitive-0.4.0.4 
enumerator-0.4.19 
zlib-enum-0.2.3 
blaze-builder-enumerator-0.2.0.5 
attoparsec-enumerator-0.3.1 
conduit-0.5.5 
blaze-builder-conduit-0.5.0.3 
blaze-markup-0.5.1.4 
blaze-html-0.5.1.3 
blaze-builder-0.3.1.0 
attoparsec-0.10.3.0 
haskell98-2.0.0.2 
Cabal-1.16.0 
bin-package-db-0.0.0.0 
zlib-bindings-0.1.1.2 
zip-archive-0.1.2.1 
Use --force-reinstalls if you want to install anyway. 

E unica soluzione per questo è di installare cabala-dev prima che alcuni altri pacchetti in tale elenco. Ma penso che anche se lo farò, non è garantito che alcuni altri pacchetti non saranno in conflitto.

Ora mi chiedo come stai gestendo i conflitti nell'installazione della tua cabala e se c'è una soluzione per questo. Non riesco a installare tutte le librerie di cui ho bisogno con Cabal. Qualsiasi aiuto sarà apprezzato.

+0

L'ironia è che questo è il tipo di problema che cabal-dev è progettato per funzionare. Per installare cabal-dev è necessario prima installare cabal dev. Qualcuno ha un sistema operativo pigramente valutato in giro? – AndrewC

risposta

7

Il problema in questo caso non è Cabala o cabala-install (1), it's cabal-dev:

if impl(ghc >= 6.12) 
    Build-depends: 
    containers >= 0.3 && < 0.5 

Così con GHC-7.6.1, si rifiuta di usare il pacchetto containers che è venuto con esso : molto brutto.

-- Require this specific version that came with GHC 6.10 because 
-- of packaging problems with containers-0.2 
if impl(ghc == 6.10) 
    Build-depends: 
    containers == 0.2.0.1 

if impl(ghc == 6.8) 
    Build-depends: 
    containers == 0.1.0.2 

Build-depends: 
    bytestring >= 0.9 && < 0.10, 

non accetta la versione bytestring sia

directory >= 1.0 && < 1.3, 
    filepath >= 1.1 && < 1.4, 
    Cabal >= 1.10.0.0 && < 1.15, 

né la versione Cabal

HTTP >= 4000.0.9 && < 4000.3, 
    mtl >= 1.1 && < 2.1, 

che probabilmente non sarà felice con la versione mtl avete

network >= 2.2 && < 2.4, 

o network

pretty >= 1.0 && < 1.2, 
    process >= 1.0 && < 1.2, 
    tar >= 0.3 && < 0.4, 
    zlib >= 0.5 && < 0.6, 
    transformers >= 0.2 && < 0.3, 

o transformers

-- Template haskell is special: the compiler will die if a 
    -- version other than the one that is shipped with the compiler 
    -- is used. Here, we don't constrain the version and hope that 
    -- there will be only one. 
    template-haskell 

Secondo this, GHC-7.6.1 dovrebbe essere felice con la versione GitHub, in modo da clonare e costruire quella.

(1) Ebbene, parte della confusione è perché il hackage page non mostra tutte le dipendenze per cabal-dev, solo quelli per ghc-pkg-6_8-compat, cioè base e cabal, quindi non è ovvio che cabal-dev-0.9.1 non funziona con ghc-7.6.

+0

Non tutto questo è stato risolto nella versione principale? –

+0

Non ho idea, qual è la versione principale, il repository? Se è stato risolto, perché non hanno ancora caricato una versione fissa per hackage? –

+0

Quello su GitHub. Ad esempio, la dipendenza dei contenitori [è rilassata nella linea principale] (https://github.com/creswick/cabal-dev/blob/master/cabal-dev.cabal): 'contenitori> = 0.3 && <0.6'. –

Problemi correlati