Тогда та же ошибка.

src/Dmsr/Recognize/Faces/Faces.hs:31:1: error: Could not find module ‘Foreign.Storable.Generic’ Perhaps you meant Foreign.Storable.Record (from storable-record-0.0.3.1) Foreign.Storable.Newtype (from storable-record-0.0.3.1) Use -v to see a list of the files searched for. | 31 | import Foreign.Storable.Generic | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

В stack.yaml: extra-deps: - generic-storable-0.1.0.0

использовать cabal new-build с .project не предлагать?

Привет. Так хотелось же на stack перейти.

А то у меня Warning: Package name not specified, inferred 'prj'

name: pupsik в кабалфайле или package.yaml только это имя пакета, а не проекта

Ну у меня есть готовый проект, на кабале. Я хочу перевести в stack. Частично это получилось, но при сборке проекта выяснилось, что нужно дополнительные зависимости прописать.

stack init - специальная команда для этого

В cabal-файле у меня прописано имя проекта, Name: dmsr. Однако, когда я пытаюсь stack install hpack-convert, то stack берёт имя текущей директории.

Ага, с этого всё и началось. Теперь пытаюсь зависимости забороть.

А, ну вот если прописать name: dmsr в stack.yaml, то stack install hpack-convert всё-таки выполняется, но с Warning: stack.yaml: Unrecognized field in ProjectAndConfigMonoid: name

Странный этот ваш stack...

они переизобрели парсинг кабал файлп

нет никакого name в stack.yaml, ЕЯПП

можешь попробовать обновиться до head

а блин

Ну я сделал stack update, половина ошибок ушло...

я криво ошибку читаю

@astynax Ну откуда оно имя берёт???

из cabal-файла, конечно же

stack не отменяет необходимости иметь cabal-файл

Оно там есть, но stack всё равно вместо этого берёт имя директории.

куда "берёт"?

См. начало дискуссии. Я выполняю: stack install hpack-convert. Дальше: Warning: Package name not specified, inferred "datamarket" Multiple .cabal files found in directory /home/dima/datamarket.exp/: dmsr.cabal, datamarket.cabal

ну так всё верно

dmsr.cabal -- это мой старый cabal-файл, datamarket.cabal -- это то, что он автогенерирует по package.yaml.

стэк сошёл с ума от нескольких кабалофайлов в одной папке

могу его понять

Ага. Только один из них он сам сделал.

стек файл в этом же каталоге7

packages - . точно указан в стэкфайле?

там есть packages: . ?

его файл можно удалить

Да, stack.yaml и старый dmsr.cabal в одном месте. В stack.yaml есть: packages: - .

оставь один кабал файл - свой. пекеджямл удали

Хорошо, но как тогда дополнительную зависимость добавить?

```

дополнительную относительно снапшота?

в stack.yaml

extra-deps

extra-deps: - generic-storable-0.1.0.0Вот на такое никак не реагирует.

в кабал-файле этот пакет используется?

если нет, то стэк и не будет ничего делать

Только вчера спорил на фриноде что Ямл хуже .cabal...

Стандартный синтаксис, говорят

А, так эту зависимость в двух местах надо прописывать o_O

Ну в cabal-файле прописал, теперь ошибка другая, связанная с тем, что generic-storable старый

Error: While constructing the build plan, the following exceptions were encountered: In the dependencies for generic-storable-0.1.0.0: base-4.10.1.0 from stack configuration does not match ==4.5.* (latest matching version is 4.5.1.0) needed due to dmsr-0.1.0.0 -> generic-storable-0.1.0.0 Some potential ways to resolve this: * Recommended action: try adding the following to your extra-deps in /home/dima/datamarket.exp/stack.yaml: - base-4.5.1.0 * Set 'allow-newer: true' to ignore all version constraints and build anyway. * You may also want to try using the 'stack solver' command. Plan construction failed.

allow-newer: true в stack.yaml

в сообщении это предлагают даже

А ведь просто cabal'ом это всё как-то собиралось и даже не требовалось этот generic-storable.

Да, сейчас попробую.

Пакет конфигурируется только кабал-файлом. Стекфайл описывает условия, в которых должна происходить сборка. По-умолчанию подразумевается, что пакету хватит снапшота. Иное - те же доп.пакеты - надо доуказывать в стэкфайле, ибо это "особые" условия сборки

При этом версию в кабалфайле можно не указывать, если в стэкфайле указана

А если собирать только стэком, то вообще версии пакетов можно не указывать.

Но всё это применительно к приложению, про которое можно явно сказать "собирать стэком"

В публикуемых либах надо указывать всё, т.к. не все будут собирать стэком

"снапшота" -- это lts?

Напр., lts-10.3

Да?

да

Да?

Да.

Спасибо за помощь, вроде частично собралось...

Если я всё-таки переведу проект на stack, надо будет из cabal-файла выпиливать все эти >= 0.1.2.3? Я просто stack'ом только сегодня занялся, до этого жил на cabal'ах, и что-то не до конца понимаю, какую задачу stack решает...

Не то чтобы надо. Но можно

stack решает (по мере возможность) за пользователя проблему совместимости пакетов

если б не совместимость пакетов - уже все давно бы писали все подряд на хаскеле

Т.е. пакеты одного снапшота должны мирно билдиться в одном проекте

..но это не точно

Такие проблемы есть в любых языках, которые компилируют либы из исходников и при этом имеют типизацию

В питонах нет такой проблемы (точнее есть, но в рантайме, и лишь иногда - при установке пакетов с прогоном тестов)

А можно использовать свежий lts-10.3, но при этом компилятор 8.0.2, а не 8.2.2 из lts? А то у меня тут ошибки, не хочу с ними пока заниматься.

лтс прибит к версии компилятора, т.к. с этой версией тестировался

Ну ладно...

По идее можно подхачить - с неизвестным результатом

Возьми LTS постарее (с нужной версией компилера) и временно бампни (в extra-deps) те пакеты, которые тебе критичны в плане свежести

А, вариант. Спасибо!

lts это удобно!

dependency resolution ненужно

Привет! Подскажите, в чем может быть проблема с vscode + hie? Бинарник hie из терминала доступен, hoogle generate + stack exec hoogle generate выполнил, расширение на vscode поставил. Но все равно не работает, и при наведении на функцию могу лишь на надпись Loading.. посмотреть

попробуй запустить vscode из того же терминала

возможно, ты изменяешь PATH в терминале, но не изменяешь при запуске vscode