> В переводе на русский, если ваш проект содержит ссылку на проект abanamat с Control.Abanamat, который использует Funck.Russian из проекта funcking-i18n, то вы не можете выполнить ":m Funck.Russian" напрямую - надо переходить в другой проект. Таким образом, для понимания работы требуется больше движений, чем надо.
Окей, я попробую объяснить поподробнее, задавайте вопросы по ходу дела, если что всё ещё не понятно.
v2-build работает таким образом, что библиотека определённой версии может быть одновременно установлена в нескольких вариантах (instances). Эти варианты отличаются друг от друга хэшами -- зависимостей и флагов сборки.
Как следствие, по дефолту все библиотеки, установленные в ~/.cabal/store не видно из ghci, потому что ему непонятно, вариант с каким хэшем загружать. То есть ~/.cabal/store работает, как бинарный кэш зависимостей.
Однако, если у нас сконфигурированный проект, то все версии и все хэши зависимостей фиксированы. То есть мы можем взять "срез" кэша (package environment) и скормить его ghci.
Это и делает строчка 'write-ghc-environment-files: always' в cabal.project в примере выше. Если она есть, v2-build после удачного завершения запишет в корень проекта .ghc.environment файл, который выглядит примерно вот так:
Как следствие, по дефолту все библиотеки, установленные в ~/.cabal/store не видно из ghci, потому что ему непонятно, вариант с каким хэшем загружать. То есть ~/.cabal/store работает, как бинарный кэш зависимостей.
Это неверно для проекта - каталога, в котором либо cabal.project, либо project.cabal.
> Это неверно для проекта - каталога, в котором либо cabal.project, > либо project.cabal.
Это a) cabal-специфичные файлы, про которые ghci не знает b) хэши зависимых библиотек в них всё равно не содержатся, и пока проект не собран (что может повлечь за собой установку зависимостей) они неизвестны.
Возможно, вы имеете в виду, что v2-build генерирует .ghc.environment файл автоматически. До (ещё не вышедшей) версии 3.0 это так и есть, но такое поведение много кому не нравится, и начиная с 3.0 надо прописывать 'write-ghc-environment-files: always' в cabal.project или ~/.cabal/config.
Прикольно. Получается, с современным Cabal можно и локальные пакеты в cabal.project указывать и ghci вызывать без cabal repl (хотя не удивлюсь, если cabal repl теперь не тормозит). И с .ghc.environment можно собирать проект при помощи GHC, не дожидаясь проверок конфигурации cabal-а. Спасибо за информацию.
import Funck.Russian разве не работает?
Reply
Reply
$ cat repl-test.cabal
cabal-version: >=1.10
name: repl-test
version: 0.1.0.0
license-file: LICENSE
build-type: Simple
executable repl-test
main-is: Main.hs
build-depends: base >=4.12 && <4.13, hedis
default-language: Haskell2010
$ cat cabal.project
packages: .
write-ghc-environment-files: always
$ cabal v2-build
[...]
$ ghci
GHCi, version 8.6.4: http://www.haskell.org/ghc/ :? for help
Loaded package environment from /path/to/.ghc.environment.x86_64-linux-8.6.4
Loaded GHCi configuration from /path/to/.ghci
Prelude> import Network.Socket
Prelude Network.Socket>
Можно ещё сказать v2-exec ghci.
Reply
Что происходит? Почему "можно ещё сказать v2-exec ghci"? Это единственное, что можно ещё сказать? Почему это можно?
Вот прямо обидеть охота.
Reply
дела, если что всё ещё не понятно.
v2-build работает таким образом, что библиотека определённой
версии может быть одновременно установлена в нескольких
вариантах (instances). Эти варианты отличаются друг от друга
хэшами -- зависимостей и флагов сборки.
Как следствие, по дефолту все библиотеки, установленные в
~/.cabal/store не видно из ghci, потому что ему непонятно,
вариант с каким хэшем загружать. То есть ~/.cabal/store работает,
как бинарный кэш зависимостей.
Однако, если у нас сконфигурированный проект, то все версии и все
хэши зависимостей фиксированы. То есть мы можем взять "срез"
кэша (package environment) и скормить его ghci.
Это и делает строчка 'write-ghc-environment-files: always' в
cabal.project в примере выше. Если она есть, v2-build после
удачного завершения запишет в корень проекта .ghc.environment
файл, который выглядит примерно вот так:
$ cat .ghc.environment.x86_64-linux-8.6.5 ( ... )
Reply
Как следствие, по дефолту все библиотеки, установленные в
~/.cabal/store не видно из ghci, потому что ему непонятно,
вариант с каким хэшем загружать. То есть ~/.cabal/store работает,
как бинарный кэш зависимостей.
Это неверно для проекта - каталога, в котором либо cabal.project, либо project.cabal.
Reply
> либо project.cabal.
Это a) cabal-специфичные файлы, про которые ghci не знает b) хэши
зависимых библиотек в них всё равно не содержатся, и пока проект не
собран (что может повлечь за собой установку зависимостей) они
неизвестны.
Возможно, вы имеете в виду, что v2-build генерирует .ghc.environment
файл автоматически. До (ещё не вышедшей) версии 3.0 это так и есть, но
такое поведение много кому не нравится, и начиная с 3.0 надо
прописывать 'write-ghc-environment-files: always' в cabal.project или
~/.cabal/config.
Reply
Reply
В .ghci в корне проекта:
:set -XConstraintKinds
:set -XDataKinds
[...]
:set -XTypeOperators
:set -Wall
:set -ipath/to/src
:load Main
И в .ghcid что-нибудь вроде:
--command "ghci -fno-code -j4 +RTS -A128m"
Получается быстрая автоматическая проверка типов на каждое сохранение.
Reply
Leave a comment