Просуммирую опыт.

[thesz]

Современное состояние дел с программированием на Haskell чрезвычайно и требует скорейшего вмешательства высших сил

Comments

[monocalibro]

Как Вы думаете, можно ли в принципе обойтись без cabal для достаточно компактного проекта, используя, например, stack? и есть ли какие-то другие варианты.

[thesz]

Stack это кабал, вид в профиль. Те же самые проблемы.

Моё мнение - надо разбивать на подпроекты как можно позже. А то неудобство появляется очень быстро.

[monocalibro]

Понятно, спасибо. Или ограничивать аппетиты минимальным использованием библиотек.

[rdia]

stack реализован на базе cabal (конфигурационные файлы проекта для stack - это, собственно [имя проекта].cabal и однострочный stack.yaml).

Собственно, stack - это как "стабильные" Linux дистрибутивы (lst), созданные поверх unstable репозитария cabal'а (hackage).

[vshabanov]

Я до сих пор работаю по старинке. Все пакеты ставлю глобально (cabal v1-install) из Makefile-а (который заодно умеет и GHC с cabal-ом поставить) и использую обычный ghci без cabal repl. Обновляю раз год, после выхода багфиксов к очередному релизу GHC

[helvegr]

> Получается какое-то безумие -- есть верхняя граница зависимостей -- не могу использовать библиотеку с новыми версиями её зависимостей. Нет границы -- опять-таки не могу использовать библиотеку.

--allow-newer не помогает?

[vshabanov]

Спасибо, не знал про --allow-newer. По-идее, должно помогать.

[thesz]

А представь себе, что есть какой-то тест к библиотеке и ты можешь при её установке сказать "мне нужны версии, на которых проходит вот этот тест".

Тогда условный "network 3.0" отвалится автоматически, без правки границ.

[vshabanov]

И еще не очень понял про :m Funck.Russian (я совсем не пользуюсь :m), import Funck.Russian в ghci вместо него не подойдёт?

[thesz]

Мой проект зависит от abanamat, который зависит от funck-i18n. В моём проекте я могу сделать cabal new-repl и подкачать Control.Abanamat. А вот Funck.Russian я подкачать могу, только если сделаю cabal new-repl в пакете abanamat или в самом funck-i18n. В моём проекте он недоступен.

[vshabanov]

Понятно, тогда да, или добавлять funck-i18n в зависимости или без cabal repl (что я обычно и делаю). В принципе, это правильно, т.к. вдруг abanamat заменит funck-i18n на eprst-i18n.

[vshabanov]

Ну и до кучи. Stackage тоже хорош: с одной стороны "вот, ребята, все пакеты собираются", а с другой, часто нужных последних версий пакетов в Stackage нет, а иногда нужно прямо с GitHub собирать исправленную версию. И получается, что старый Makefile, вызывающий cabal install в нужном порядке и/или в нужных папках, опять-таки работает лучше описания проекта в .cabal и cabal repl (или stack).

[helvegr]

> В переводе на русский, если ваш проект содержит ссылку на проект abanamat с Control.Abanamat, который использует Funck.Russian из проекта funcking-i18n, то вы не можете выполнить ":m Funck.Russian" напрямую - надо переходить в другой проект. Таким образом, для понимания работы требуется больше движений, чем надо.

import Funck.Russian разве не работает?

[thesz]

Подробней можно?

[helvegr]

Я проверил, и из v2-repl действительно не работает. Но можно сделать вот так:

$ 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.

[thesz]

Я вообще не понимаю, что вот выше происходит. Какие-то команды, что-то поднимается в интерпретатор...

Что происходит? Почему "можно ещё сказать v2-exec ghci"? Это единственное, что можно ещё сказать? Почему это можно?

Вот прямо обидеть охота.