Verschiedene Programmiersprachen verwenden unterschiedliche Verpackungssysteme.Dependency-Hölle in Kabalen. Es ist wirklich eine Hölle
In ihren verschiedenen Ansatz, Java Maven
sieht aus wie die beste Wette für mich, da es unterschiedliche Version von JAR-Dateien in separat versionierten Ordnern verwaltet und daher gibt es keine Möglichkeit, wird in widersprüchlichen Versionen einer Bibliothek enden.
Als nächstes kommt Python. Pythons pip
legt seine Pakete in /usr/local/lib/python/dist-packages/site-packages
. Wenn es einen Versionskonflikt gibt, kann man dessen virtualenv
verwenden und damit leben.
Nodejs unterstützt die Installation von Paketen in lokalen Ordnern und globalen Ordnern. Bis zu diesem Zeitpunkt hatte ich nie einen Abhängigkeitskonflikt in den globalen Bibliotheken.
Dann wurde ich vom Haskell-Stil fasziniert und fing an, cabal
zu verwenden. Zuerst installierte ich meine Bibliotheken innerhalb /home/user1/.cabal
. Als dann das Paketsystem kaputt ging, schlug mir ein Freund vor, zwei Ordner zu entfernen - /home/user1/.cabal && /home/user1/.ghc
. Nun, meine erste Verwirrung entstand, warum Cabal Bibliotheksdateien in zwei Ordnern sitzen .cabal && .ghc
. Ich säuberte die Bibliotheksordner, ~/.ghc and ~/.cabal
, und tat cabal install
von einer Paketquelle für cabal-db-0.1.12
. Jetzt gab es einen neuen Fehler und ich war überrascht, weil ich alle lokalen Repositories bereinigt hatte. Der Fehler war,
Configuring Cabal-1.22.2.0...
Building Cabal-1.22.2.0...
Installed Cabal-1.22.2.0
cabal: Error: some packages failed to install:
ansi-terminal-0.6.2.1 failed during the configure step. The exception was:
user error (The package 'ansi-terminal' requires Cabal library version -any &&
>=1.6 but no suitable version is installed.)
Dann habe ich versucht, die sicherste Wette - sandbox
für cabal-db
. Es funktionierte. Dann wiederholte ich das Sandboxing für ein weiteres Paket, ghc-pkg-autofix. Ich habe,
cd ghc-pkg-autofix-0.2.0.1
cabal sandbox init
cabal install
Und für Sandkasten, wo es absolut keine externen Abhängigkeiten gibt es wieder Fehler,
cabal: Could not resolve dependencies:
trying: ghc-pkg-autofix-0.2.0.1 (user goal)
trying: Cabal-1.22.2.0 (dependency of ghc-pkg-autofix-0.2.0.1)
next goal: process (dependency of ghc-pkg-autofix-0.2.0.1)
rejecting: process-1.2.0.0/installed-06c..., 1.2.3.0, 1.2.2.0, 1.2.1.0,
1.2.0.0, 1.1.0.2, 1.1.0.1, 1.1.0.0 (conflict: ghc-pkg-autofix => process>=1.0
&& <1.1)
rejecting: process-1.0.1.5, 1.0.1.4, 1.0.1.3, 1.0.1.2, 1.0.1.1, 1.0.0.0
(conflict: Cabal => process>=1.1.0.1 && <1.3)
Dependency tree exhaustively searched.
Note: when using a sandbox, all packages are required to have consistent
dependencies. Try reinstalling/unregistering the offending packages or
recreating the sandbox.
Bin ich etwas falsch (oder), diese Art von Abhängigkeitskonflikten zu tun sind recht häufig in Kabale? Ich sehe, die Verwaltung von Abhängigkeiten in anderen Sprachen ist viel einfacher.
Hinweis: Ich benutze cabal-install version 1.22.0.0
& & The Glorious Glasgow Haskell Compilation System, version 7.8.4
nein es ist nicht üblich - aber sehr häufig für Anfänger. In der Tat ist der einfachste Weg für Anfänger, eine saubere Umgebung einzurichten und Sandboxes zu benutzen. Es gibt [ein nettes Tutorial, wie es hier geht] (http://www.stackage.org/install) (Sie müssen die Stackage-Teile nicht verwenden, wenn Sie nicht möchten - wenn Sie GHC 7.10 haben .1 du kannst eigentlich nicht AFAIK) - übrigens: hast du cabal-1.22 absichtlich benutzt (zB mit GHC 7.10.1?), Weil ich die haskell-plattform jetzt nicht benutzen würde) – Carsten
btw: nur neugierig - wie geht maven mit der situation um Paket X hängt von A-Vers1 und Y von a-Vers2 ab (nicht kompatibel) und Sie wollen sowohl X als auch Y verwenden? – Carsten
Im 'M2_HOME' Repository erstellt Maven zwei Ordner wie' A/1.0.0/* 'und' A/2.0.0/* '. Da das globale Repository verschiedene Ordner verwendet, die auf verschiedenen Versionen basieren, können verschiedene Versionen desselben Archetyps/Jars an einer Stelle in Ihrem System gespeichert werden. –