2012-01-10 1 views
5

Encontré el comportamiento de cabal al instalar paquetes de enloquecimiento. Por ejemplo, correr"cabal install ___" rompe paquetes instalados previamente

cabal install funsat 

instaladas las versiones antiguas de array, time, random, quickcheck y bitset, rompiendo paquetes como monadiccp, hoogle, heist, snap, etc.

Se trabaja para volver atrás y cabal install monadiccp , etc., pero ¿cómo puedo evitar el comportamiento predeterminado de los paquetes instalados de cabal shaking? Cualquier gestor de paquetes Linux razonable, como aptitude o zypper sería pregunte si quería romper paquetes ya instalados, al instalar un paquete nuevo.

¿Alguien ha inventado una secuencia de comandos? Gracias por adelantado.

+1

http://ivanmiljenovic.wordpress.com/2010/03/15/repeat-after-me-cabal-is-not-a-package-manager/ –

+0

@ MatveyB.Aksenov, lo que Obtuve de esa página (a) cabal/= cabal-install, ya lo sabía, pero no me importa tanto (b) uso el administrador de paquetes del sistema (c) si no tiene paquetes del sistema, cambie a gentoo. (c) no es realmente una opción para mí, desafortunadamente. – gatoatigrado

Respuesta

8

Recomiendo cabal-dev, que mantiene un conjunto separado de paquetes instalados para cada proyecto en el que trabaja. Eso no resuelve el mal comportamiento de cabal-install en general, pero significa que tales fallas están más aisladas de lo que estarían de otra manera, y le permite arreglarlas más fácilmente simplemente haciendo cabal-dev clean && cabal-dev install.

El beneficio adicional de compilaciones reproducibles también es bueno.

Es cierto que esto no es una solución para su problema específico, pero disminuye el dolor cabal-install en general.


Sobre la base de la respuesta de Daniel Fischer, aquí hay un contenedor para cabal que aborta una instalación si sería instalar un paquete:

cabal() { 
    if [ "$1" = "install" ]; then 
    local out=$(command cabal --dry-run -v2 "[email protected]" 2>&1) 
    if echo "$out" | egrep -c '\((reinstall|new version)\)' >/dev/null; then 
     echo "$out" 
     return 1 
    fi 
    fi 
    command cabal "[email protected]" 
} 

tu caso es distinto; Solo lo he probado a la ligera y causa un retraso molesto en la puesta en marcha, ya que todas las dependencias deben calcularse dos veces. Pero debería aliviar un poco de tedio si quieres estar seguro.

+0

+1 No sabía nada de esto, gracias ... Supongo que este sería el equivalente de Haskell del virtualenv de Python. –

+0

genial, aunque para zsh, elimine local (y agregue un recordatorio de cómo instalar de todos modos - http://pastebin.com/PGYWqdKA). parece funcionar para el ejemplo de funsat (detención de la instalación) y permitió la instalación de 'repa', que no rompió nada. ¡¡así que gracias!! – gatoatigrado

+0

también es bueno saber sobre 'command', ahora puedo sacar algunos hacks de otras funciones de shell. – gatoatigrado

5

Solución: siempre consulte con --dry-run primero. Si Cabal reinstalaría cualquier paquete, ten cuidado.

2

Este es un problema conocido (consulte this slide deck, comenzando con la diapositiva 22). La versión de Darcs de cabal-install (darcs get http://darcs.haskell.org/cabal) ahora muestra una advertencia cuando instalar un paquete romperá su sistema. Ejemplo:

$ cabal --version 
cabal-install version 0.13.3 
using version 1.13.3 of the Cabal library 
$ cabal install monadiccp 
[...] 
$ cabal install funsat 
Resolving dependencies... 
In order, the following would be installed: 
mtl-1.1.1.1 (new version) 
syb-0.3.6 (new package) 
array-0.2.0.0 (new version) 
containers-0.2.0.1 (new version) 
bimap-0.2.4 (new package) 
deepseq-1.2.0.1 (reinstall) changes: array-0.3.0.2 -> 0.2.0.0 
fgl-5.4.2.2 (new package) 
text-0.11.1.12 (reinstall) changes: array-0.3.0.2 -> 0.2.0.0 
parsec-3.1.2 (reinstall) changes: mtl-2.0.1.0 -> 1.1.1.1 
parse-dimacs-1.2 (new package) 
time-1.1.4 (new version) 
random-1.0.0.3 (reinstall) changes: time-1.2.0.3 -> 1.1.4 
QuickCheck-1.2.0.1 -base3 (new package) 
bitset-0.6 (new package) 
funsat-0.6.1 (new package) 
cabal: The install plan contains reinstalls which can break your GHC 
installation. 
You can use the --avoid-reinstalls option to try to avoid this or try 
to ghc-pkg unregister the version of the package version to see its effect 
on reverse dependencies. If you know what you are doing you can use 
the --override-reinstall-check option to override this reinstall check.
Cuestiones relacionadas