Пакет package.yaml стека против stack.yaml

Куча поддерживает файлы конфигурации package.yamlhpack, по крайней мере, примерно с это коммит, насколько я могу судить, но документации о различиях между ним и файлом stack.yaml не так много.

Одна из немногих ссылок, которые я нашел, говоря об этом, - это эта документация, где говорится:

package.yaml is a file format supported by hpack. It adds some niceties on top of cabal. For example, hpack has YAML syntax support and will automatically generate of exposed-modules lists. However, it's just a frontend to cabal package files.

Таким образом, похоже, что package.yaml предоставляет расширенный набор возможностей конфигурации файла *.cabal, как и файл stack.yaml.


документация здесь подразумевает, что stack.yaml - это файл конфигурации:

Next, let's look at our stack.yaml file, which gives our project-level settings.

... и позже говорит, что package.yaml предназначен для хранения зависимостей:

To tell stack to use text, you need to add it to your package.yaml file — specifically in your dependencies section...

Есть этот связанный вопрос, но, к сожалению, он не проясняет разницу между двумя файлами.

Я использовал package.yaml для всех конфигураций своего проекта и никогда не использовал stack.yaml.


Итак, какова взаимосвязь между файлами стека package.yaml и stack.yaml? Если / когда их обязанности совпадают, что лучше использовать?

Вы используете stack? Может ли stack build действительно добиться успеха без stack.yaml?

Li-yao Xia 11.04.2018 14:24

@ Li-yaoXia Только что проверил, и он не может собрать без stack.yaml, но единственные вещи в файле (который был сгенерирован стеком 1.6.5) - это resolver и тег packages - все остальное находится в package.yaml. Я даже могу закомментировать тег packages, и сборка работает нормально.

hnefatl 11.04.2018 14:35

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

Potato44 11.04.2018 14:52
16
3
3 252
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

So from this, it seems like package.yaml provides a superset of the *.cabal file's configuration ability, like the stack.yaml file also does.

stack.yaml не предоставляет расширенного набора конфигураций *.cabal.


Файл *.cabal - это конфигурация уровня пакета. Он может быть сгенерирован hpack из package.yaml. Эта конфигурация предоставляет важную информацию о пакете: зависимости, экспортируемые компоненты (библиотеки, исполняемые файлы, наборы тестов) и настройки для процесса сборки (препроцессоры, пользовательский Setup.hs). Многие проекты также не используют hpack и не имеют package.yaml, только файл *.cabal.

Файл stack.yaml представляет собой конфигурацию на уровне проекта, которая определяет конкретную среду, чтобы сделать сборку воспроизводимой, закрепляя версии компилятора и зависимостей. Обычно это указывается преобразователем (например, lts-11.4).

stack.yaml не дублирует package.yaml. package.yaml указывает, какие зависимости необходимы. stack.yaml указывает один способ согласованного разрешения зависимостей (конкретная версия пакета и / или откуда ее взять, например: в Hackage, в удаленном репозитории или в локальном каталоге).

stack.yaml наиболее полезен для разработчиков: мы не хотим, чтобы наша сборка внезапно сломалась из-за обновления зависимости во время работы над другим проектом, поэтому мы закрепляем все с помощью stack.yaml. Этот файл менее полезен для пользователей, у которых могут быть внешние ограничения (обычно версии уже исправлены некоторым дистрибутивом).

  • Во многих случаях достаточно просто указать преобразователь в stack.yaml. Следовательно, новым пользователям stack обычно не нужно беспокоиться о настройке stack.yaml.

  • Решатель определяет тщательно подобранный набор пакетов с определенными версиями (стандартные перечислены на stackage.org). Если зависимость пакета отсутствует в выбранном преобразователе, она должна быть указана в поле extra-deps файла stack.yaml.

  • Проект может охватывать несколько пакетов, которые, таким образом, добавляются в поле packagesstack.yaml, поэтому они могут быть построены в единой общей среде и зависеть друг от друга.

  • Другой распространенный вариант использования - создание множества stack.yaml (с разными именами) для простого тестирования различных конфигураций (например, версий GHC или флагов пакетов).

Спасибо, это хороший ответ - просто чтобы уточнить: нужно ли вам помещать зависимость в stack.yaml только в том случае, если вам требуется, чтобы его версия была закреплена? В то время как установка его в package.yaml позволяет преобразователю выбрать версию?

hnefatl 11.04.2018 15:31

В stack.yaml фактически указываются версии для всех пакетов. Большинство из них обычно подразумевается при выборе решателя. Существуют резолверы без пакетов (ghc-*), с которыми каждая отдельная зависимость, включая транзитивные, должна быть указана как extra-deps.

Li-yao Xia 11.04.2018 15:38

@hnefatl Запись в extra-deps требуется только в том случае, если зависимость не содержится в преобразователе или если вы хотите иметь определенную версию. Обратите внимание, что пакеты и версии, содержащиеся в преобразователе, не должны изменяться, и, насколько мне известно, stack будет кэшировать данные преобразователя. С другой стороны, зависимости в *.cabal и package.yaml должны быть мягкими, чтобы не потерять возможность сделать версию совместимой с несколькими преобразователями.

MauganRa 27.05.2018 18:19

Возможно, это немного поздно для комментариев, но: я думаю, следует также отметить, что package.yaml ни в коем случае не является обязательным - это просто тонкий слой над файлом *.cabal, и многие люди (включая меня) предпочитают редактировать файл *.cabal напрямую .

bradrn 26.05.2019 04:47

«Другой распространенный вариант использования - создание множества stack.yaml (с разными именами) для простого тестирования различных конфигураций (например, версий GHC или флагов пакетов)». @ Li-yaoXia, знаете ли вы место, где есть примеры того, что вы говорите?

Nicolas Henin 25.07.2020 15:12

Одно из мест - искать файлы вроде stack-lts*.yaml на Github: github.com/search?p=1&q=filename%3Astack-lts * .yaml & type = Code Я знаю, что у aeson есть куча файлов стека в корне, я не уверен, используются ли они до сих пор, но я впервые взял его здесь .

Li-yao Xia 25.07.2020 18:25

Другие вопросы по теме