8

私はcabal-dev自分が取り組んでいるプロジェクトに挑戦しています。このプロジェクトはライブラリでありcabal-dev、サンドボックスバージョンを構築するのに最適ですが、ワークフローの一部に問題があります...

私はスクリプトを持っています。scratch.hsこれは（前に）何かを試すためcabal-devにロードします。ghciもちろん、作業している機能によって内容はscratch.hs時間とともに変化します。 scratch.hsこれはライブラリコードベースの一部ではなく、作業中の個人的なスクラッチスペースにすぎません。

さて、ghciサンドボックスをロードした状態でセッションを取得するためにcabal-dev ghci、それをロードscratch.hsすることができます。問題は、これが（設計上、そして賢明に）私のユーザーパッケージデータベースを除外することです。したがってscratch.hs、私のライブラリにないパッケージからモジュールを参照する場合build-depends（これは不合理ではありません-結局のところライブラリの一部ではありません）、それらのパッケージはそうではありません表示されないため、次のようなエラーが発生します。

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.

ここで、この場合、scratch.hsインポートしたいのですData.Aeson.Genericがaeson、私のライブラリにはありませんがbuild-depends（かなり適切に）、ユーザーパッケージデータベースにはあります。

では、どうすればこれを回避できますか？これらのカテゴリのいずれかで答えを想像することはできますが、見逃したカテゴリがあるかもしれません。

  1. によって作成されたサンドボックスと組み合わせて、ユーザーパッケージデータベースのパッケージを（選択的に）使用する方法cabal-dev。（おそらく私自身のcabal-dev ghciスタイルのスクリプトをローリングしますか？）

  2. 問題がなくなるようにワークフローを改善する方法についての提案。

パッケージをグローバルにインストールするだけでよいことはわかっていますが、この方法でグローバルパッケージデータベースを汚染することには消極的です（そしてcabal-devこれを明示的に阻止します）。

すべてのアドバイスに感謝します。

4

1 に答える 1

8

最も簡単な解決策は、必要なものをサンドボックスにインストールすることだと思います。たとえば、インタラクティブ スクリプトに aeson が必要な場合:

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

その後、:set -package aesonで動作するはずghciです。

それが不十分で、ユーザー パッケージ データベースから使用したい多くの依存関係がありghci、cabal ファイルが呼び出し用に設定する他のフラグで呼び出される必要がない場合はghc、サンドボックス化されていないghciアクセスで呼び出すことができます。サンドボックスからのパッケージだけでなく、ユーザーおよびグローバル パッケージにも。例 (GHC 7.0.3 の場合):

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

( の末尾のコロンと、GHC_PACKAGE_PATHと の間のスペースの両方に注意してくださいghci。)

于 2011-09-19T16:23:03.010 に答える