Haskell Cabal: "gói gián tiếp phụ thuộc vào nhiều phiên bản của cùng một gói"

Question

Sau khi giải phóng ra tất cả các cabal install gói ed của tôi, tôi chạy này phiên sau:

$ cabal update 
Downloading the latest package list from hackage.haskell.org 
james@bast:~/.cabal/packages$ cabal install cabal-dev 
Resolving dependencies... 
Downloading cabal-dev-0.9.1... 
[1 of 1] Compiling Main    (/tmp/cabal-dev-0.9.124882/cabal-dev-0.9.1/Setup.hs, /tmp/cabal-dev-0.9.124882/cabal-dev-0.9.1/dist/setup/Main.o) 
Linking /tmp/cabal-dev-0.9.124882/cabal-dev-0.9.1/dist/setup/setup ... 
Configuring cabal-dev-0.9.1... 
Warning: This package indirectly depends on multiple versions of the same 
package. This is highly likely to cause a compile failure. 
package containers-0.4.2.1 requires array-0.4.0.0 
package Cabal-1.14.0 requires array-0.4.0.0 
package text-0.11.1.13 requires array-0.4.0.0 
package deepseq-1.3.0.0 requires array-0.4.0.0 
package containers-0.4.2.1 requires array-0.4.0.0 
package HTTP-4000.2.2 requires array-0.4.0.0 
package cabal-dev-0.9.1 requires containers-0.4.2.1 
package Cabal-1.14.0 requires containers-0.4.2.1 
package template-haskell-2.7.0.0 requires containers-0.4.2.1 
Building cabal-dev-0.9.1... 
Preprocessing executable 'ghc-pkg-6_8-compat' for cabal-dev-0.9.1... 
<command line>: cannot satisfy -package-id Cabal-1.14.0-4af45d3c8d10dc27db38ae0e7e5a952b: 
    Cabal-1.14.0-4af45d3c8d10dc27db38ae0e7e5a952b is unusable due to missing or recursive dependencies: 
     array-0.4.0.0-46f61f5fd9543ebf309552ef84dccc86 containers-0.4.2.1-98f9aa15f9c08b13673dc9d89385f449 
    (use -v for more information) 
cabal: Error: some packages failed to install: 
cabal-dev-0.9.1 failed during the building phase. The exception was: 
ExitFailure 1 
$ 

Vì vậy, lý do tôi có thể không cài đặt cabal-dev dường như là

• nó "gián tiếp phụ thuộc vào nhiều phiên bản của cùng một gói." Tuy nhiên, cabal không đặt tên gói mà yêu cầu cabal-dev yêu cầu nhiều phiên bản.
• Cabal-1.14.0 có "phụ thuộc bị thiếu hoặc đệ quy", cụ thể bằng cách nào đó liên quan đến array-0.4.0.0 và containers-0.4.2.1.

Một đồ thị của các phụ thuộc nó sẽ liệt kê khẳng định rằng không ai trong số những khiếu nại là đúng (hoặc phụ thuộc nó liệt kê là sai hoặc không đầy đủ):

Vì vậy: tôi thiếu cái gì? Ai hoặc những gì không chính xác: tôi, cabal hoặc một hoặc nhiều gói?

Tôi đang chạy:

$ cabal --version 
cabal-install version 0.10.2 
using version 1.10.1.0 of the Cabal library 
$ ghc --version 
The Glorious Glasgow Haskell Compilation System, version 7.4.1 
$ 

Answer 1

Vấn đề phát sinh khi chúng ta có gói B và C đã được cài đặt nhưng xây dựng đối với các phiên bản khác nhau của D và sau đó chúng tôi cố gắng sử dụng cả hai gói B và C cùng trong gói Một : Vấn đề phụ thuộc kim cương Điều này có thể hoạt động tốt nhưng chỉ khi gói B và C không hiển thị các loại được xác định trong D trong giao diện của chúng. Nếu họ làm như vậy thì gói A sẽ không thể sử dụng các hàm từ B và C cùng nhau vì chúng sẽ không hoạt động cùng loại. Đó là bạn sẽ nhận được một lỗi kiểu.

Để chọn một ví dụ cụ thể, giả sử gói D là tối ưu và chúng tôi đã cài đặt cả hai phiên bản 0,91.1 và 0.9.0.4. Giả sử B là utf8-string và C là regex-base. Giả sử gói A là chương trình biên tập viên Yi. Vì vậy, điểm là, tại một số nơi trong mã trong Yi chúng tôi muốn vượt qua một bytestring sản xuất như là kết quả của UTF-8 giải mã như đầu vào cho một trong các chức năng regex. Nhưng điều này không hoạt động vì các hàm trong gói utf8-string đang sử dụng kiểu ByteString từ bytestring-0.9.0.1 trong khi các hàm regex trong gói regex đang sử dụng kiểu ByteString từ bytestring-0.9.0.4. Vì vậy, chúng tôi nhận được một lỗi loại khi chúng tôi cố gắng để biên dịch Yi:

thể không đối sánh với dự kiến ​​loại bytestring-0.9.0.4:Data.ByteString.ByteString' against inferred type bytestring-0.9.0.1: Data.ByteString.ByteString'

As far as GHC biết, hai loại là hoàn toàn không liên quan!

Điều này rõ ràng là cực kỳ khó chịu. Cũng không có giải pháp dễ dàng. Trong ví dụ này, chúng tôi giả định rằng các gói B và C đã được xây dựng, vì vậy thực sự không có cách nào để sử dụng hai gói một cách hợp lý mà không cần xây dựng lại chúng với một phiên bản gói D. Trong trường hợp này, giải pháp hiển nhiên là để xây dựng lại B để sử dụng D-1.1 thay vì D-1.0. Vấn đề với việc xây dựng lại một gói của khóa học là nó phá vỡ tất cả các gói khác đã được xây dựng chống lại nó. Nó không phải là rõ ràng rằng bạn muốn một người quản lý gói để đi tự động xây dựng lại rất nhiều gói dường như không liên quan.

Về lâu dài, giải pháp tốt nhất có vẻ là làm những gì Nix làm.Trong ví dụ trên, thay vì thay thế gói B được xây dựng dựa trên D-1.0 với B được xây dựng dựa trên D-1.1, Nix sẽ thêm một phiên bản B khác được xây dựng dựa vào D-1.1. Vì vậy, trường hợp ban đầu của B sẽ không thay đổi và không có gì sẽ phá vỡ. Đó là cách tiếp cận chức năng: chúng ta không bao giờ biến đổi các giá trị (các gói đã cài đặt), chúng ta chỉ tạo các giá trị mới và thu gom rác cũ khi chúng không còn cần thiết nữa.

Trong thực tế, có nghĩa là chúng tôi phải xác định các gói đã cài đặt bằng cách sử dụng một số băm của gói và băm của tất cả các gói phụ thuộc. jhc đã thực hiện điều này và có những bước tiến để thực hiện điều gì đó tương tự cho GHC, mặc dù nhắm vào việc theo dõi các thay đổi API/ABI nhiều hơn. Đối với quản lý gói dựa trên nguồn sane, tôi nghĩ đó là hướng đi đúng đắn.

Tôi nên lưu ý rằng đây không phải là vấn đề mới. Bạn đã có thể xây dựng vấn đề này kể từ khi ghc bắt đầu cho phép nhiều phiên bản của cùng một gói được cài đặt cùng một lúc. Chúng tôi chỉ chú ý đến nó thường xuyên hơn nhiều vì chúng tôi chia nhỏ gói cơ sở và cho phép các gói chia nhỏ đó được nâng cấp.

Trạng thái hiện tại của trò chơi là Cabal cảnh báo về sự cố này nhưng không thực sự giúp bạn giải quyết. Đối với ví dụ trên, chúng tôi sẽ nhận được:

$ cabal configure 
Configuring A-1.0... 
Warning: This package indirectly depends on multiple versions of 
the same package. This is highly likely to cause a compile failure. 
package B-1.0 requires D-1.0 
package C-1.0 requires D-1.1