2011-09-15 19 views
8

Tôi đang cố gắng ra cabal-dev cho một dự án tôi đang làm việc; Dự án này là một thư viện, và cabal-dev làm một công việc tuyệt vời của việc xây dựng một phiên bản sandboxed của nó - nhưng tôi đang gặp rắc rối với một phần của công việc của tôi ...Làm thế nào để sử dụng "cabal-dev ghci" với gói không phải hộp cát, không toàn cầu (người dùng?)?

Tôi có một kịch bản, scratch.hs, trong đó (trước cabal-dev) Tôi sẽ tải vào ghci để thử nội dung. Nội dung của scratch.hs thay đổi theo thời gian tùy thuộc vào tính năng tôi đang làm việc, tất nhiên. scratch.hs không phải là một phần của codebase thư viện, nó chỉ là scratchspace cá nhân của tôi trong khi tôi đang làm việc trên nó.

Bây giờ, để nhận được phiên ghci với hộp cát của tôi được tải, tôi chỉ có thể cabal-dev ghci và sau đó tải scratch.hs vào đó. Vấn đề là điều này (theo thiết kế và hợp lý) không bao gồm cơ sở dữ liệu gói người dùng của tôi, vì vậy nếu scratch.hs tham chiếu các mô-đun từ các gói không nằm trong thư viện của tôi build-depends (không phải là không hợp lý - nó không phải là một phần của thư viện) gói không nhìn thấy được, và vì vậy tôi nhận được một lỗi như:

scripts/scratch.hs:8:8: 
    Could not find module `Data.Aeson.Generic': 
     It is a member of the hidden package `aeson-0.3.2.11'. 
     Perhaps you need to add `aeson' to the build-depends in your .cabal file. 
     Use -v to see a list of the files searched for. 
Failed, modules loaded: none. 

ở đâu, trong trường hợp này, scratch.hs muốn nhập Data.Aeson.Generic nhưng aeson không có trong thư viện của tôi build-depends (khá đúng), nhưng trong cơ sở dữ liệu gói người dùng của tôi.

Vậy làm cách nào tôi có thể giải quyết vấn đề này? Tôi có thể tưởng tượng câu trả lời bằng một trong các loại này, nhưng có lẽ có nhiều loại tôi đã bỏ lỡ:

  1. Một cách để (có chọn lọc) sử dụng các gói từ cơ sở dữ liệu gói người dùng của tôi kết hợp với sandbox tạo ra bởi cabal-dev. (Có thể cuộn tập lệnh kiểu số cabal-dev ghci của riêng mình?)

  2. Đề xuất về cách cải thiện luồng công việc của tôi để vấn đề chỉ biến mất.

Tôi biết tôi chỉ có thể cài đặt các gói trên toàn cầu, nhưng tôi không muốn làm ô nhiễm cơ sở dữ liệu gói toàn cầu của tôi theo cách này (và cabal-dev không khuyến khích này rõ ràng).

Rất cám ơn mọi lời khuyên.

+1

Tôi tự hỏi ... bạn có thể: set -package từ bên trong ghci? (Hoặc bất kỳ tên của tùy chọn là chọn cơ sở dữ liệu gói của bạn?) –

+0

* trán tát * - tại sao tôi không nghĩ về điều đó? Có, điều đó hoạt động - cảm ơn. Tôi thậm chí có thể thêm nó vào '.ghci' và có nó xảy ra tự động. Cảm ơn, Daniel! – gimboland

+1

Rất tiếc, hãy nói dối. Không, điều đó không hiệu quả. Nó xuất hiện để làm việc trước đó, nhưng đó là bởi vì bộ thử nghiệm của dự án của tôi sử dụng aeson, do đó, nó được tham chiếu trong tệp .cabal của tôi và do đó được đưa vào hộp cát mặc dù không, có vẻ như, được tải hoàn toàn bởi 'cabal-dev ghci', đó là lý do tại sao tôi cần ': set -package aeson' để tải nó. Nếu tôi loại bỏ điều đó, thì trên thực tế ': set -package aeson' _doesn't_ tải phiên bản cơ sở dữ liệu gói người dùng (" 'không thể thỏa mãn -package aeson'"), vì vậy tôi trở lại nơi tôi đã bắt đầu (ngoại trừ tất cả mọi người đã xem trang này trong 3 giờ qua cho rằng vấn đề được giải quyết). – gimboland

Trả lời

8

Tôi nghĩ giải pháp đơn giản nhất là chỉ cài đặt những thứ bạn cần vào hộp cát. Ví dụ, nếu bạn cần aeson cho kịch bản tương tác của bạn:

~/myproject$ cabal-dev install aeson 
~/myproject$ cabal-dev ghci 

Sau đó :set -package aeson nên làm việc trong ghci.

Nếu đó là không đầy đủ, bạn có rất nhiều phụ thuộc bạn muốn sử dụng từ cơ sở dữ liệu sử dụng gói của bạn, và bạn không cần phải ghci được gọi với những lá cờ khác mà bộ tập tin cabal của bạn cho cách gọi ghc, sau đó bạn có thể gọi không sandboxed ghci với quyền truy cập vào các gói từ sandbox cũng như các gói người dùng và toàn cầu của bạn. Ví dụ (đối với GHC 7.0.3):

~/myproject$ GHC_PACKAGE_PATH=./cabal-dev/packages-7.0.3: ghci 

(Lưu ý cả thư ruột kết ở phần cuối của GHC_PACKAGE_PATH và không gian giữa đó và ghci.)

+0

Tuyệt vời - cảm ơn rất nhiều. Đề nghị thứ hai là làm việc cho tôi. :-) (Bất kỳ ý tưởng gì xảy ra nếu sandbox và người dùng có cùng một gói được cài đặt, btw?) Đề xuất đầu tiên cũng có vẻ tốt (có thể tốt hơn) nhưng không khả thi đối với tôi tại thời điểm này: có lỗi trong 'double-conversion' (một phụ thuộc của' blaze-textual', là một phụ thuộc của 'aeson') ngăn nó được sử dụng với' ghci'; có một workaround nhưng [nó không làm việc với cabal-dev] (https://github.com/mailrank/blaze-textual/issues/4) vì vậy tôi sẽ không thể cài đặt 'aeson' vào sandbox của tôi tại thời điểm này. – gimboland

+0

Hoạt động với tính năng cabal 1.18 cabal quá với một chút thay đổi: 'GHC_PACKAGE_PATH = .cabal-sandbox/x86_64-linux-ghc-7.4.1-packages.conf.d: ghci' –

Các vấn đề liên quan