скрыть информацию о deps в цепочке лишних

Question

Это вопрос конфигурации зависимости пакета стека Haskell.

1. Я создал библиотеку Haskell git:LibA
2. Я создал другую библиотеку Haskell git:LibB в зависимости от git:LibA
3. Я создал приложение на Haskell AppC в зависимости от git:LibB

Для компиляции LibB мне нужно указать git:LibA в extra-deps секции LibB stack.yaml с контрольной суммой фиксации, что является разумным.

Для компиляции AppC кажется, что мне нужно указать оба следующих пакета в extra-deps разделе AppC stack.yaml

• git:LibB с контрольной суммой фиксации
• git:LibA с контрольной суммой фиксации

Можно ли указать git:LibB в AppC или настроить LibB, чтобы скрыть git:LibA информацию для приложений?

Мотивация вопроса: мои текущие AppC stack.yaml подвержены ошибкам: если я обновлю LibA и контрольную сумму фиксации в LibB, но забуду обновить контрольную сумму в AppC, тогда я не получит новый LibA в AppC. По моему мнению, более новая контрольная сумма LibB должна уже содержать информацию о более новом LibA, и разработчику AppC не нужно обновлять контрольную сумму LibA в AppC, а только LibB контрольная сумма.

Answer 1

Нет, стек не "видит" stack.yml каких-либо зависимостей, только их соответствующие дескрипторы .cabal.

Если вы создаете несколько внутренних пакетов, вы можете просто поместить их все в одно дерево исходных текстов и перечислить их в списке пакетов в вашем stack.yaml:

packages:
- LibA
- LibB
- AppC

Обратите внимание, что это не означает, что вы все должны поместить их в одну и ту же VCS, если не хотите - вы можете использовать подмодули git; Или вы могли бы даже перечислить git-местоположения / хэши практически так же, как вы делаете это непосредственно с extra-deps.

Это, конечно, не вариант, если ваши пакеты должны быть полностью независимыми, но в этот момент вы, вероятно, захотите посмотреть на более структурированное решение, например, сделать пользовательских снимков в любом случае.

Answer 2

Нет, это невозможно. По замыслу stack использует только stack.yaml проекта, который вы строите. Он не читает и не использует файл stack.yaml, который может существовать в любой из ваших зависимостей. Одним из преимуществ этой конструкции является то, что существует единственное место для указания версий пакета. Иначе не ясно, как обрабатывать разные stack.yaml, запрашивающие разные версии одного и того же пакета.

Есть несколько вариантов, если вам нужно больше удобства при совместной разработке этих пакетов, и вам не нужно заботиться о их независимости. Вы можете указать относительные пути в вашем stack.yaml и всегда строить с теми версиями, которые вы локально проверили. Или вы можете объединить все три в одно хранилище VCS и использовать VCS для управления тем, какие изменения в A должны быть связаны с какими в C.