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

Я поддерживаю пакет для взлома, lrucache. Недавно я получил запрос функции для добавления экземпляров для Binary и NFData. Обе эти вещи полезны, и в принципе у меня нет проблем с этими примерами.

Однако оба из них представляют новые зависимости пакетов, и я хочу, чтобы список зависимостей пакета был как можно меньше. Есть ли разумный способ справиться с этим? Вероятно, существует более двадцати различных пакетов, которые предоставляют полезные классы типов, которые могут реализовывать структуры данных в lrucache, и получить некоторую выгоду.

Очевидно, что добавление всех из них в качестве зависимостей является не стартером. Но что еще можно сделать?

Я могу добавить флаги в lrucache.cabal, которые позволят скомпилировать различные экземпляры. Это работает с точки зрения минимального списка зависимостей, за исключением случаев, когда вы этого хотите. Но это ужасно в реальном мире, потому что вы не можете указывать флаги сборки в разделах, зависящих от сборки. Таким образом, вы можете зависеть от пакета с определенным флагом, но не указывать эту зависимость. Это быстро сводится к почти бесполезности.

Я могу создать кучу пакетов сиротских экземпляров. Это имеет то преимущество, что позволяет определять зависимости от этих экземпляров в разделе, зависящем от сборки. Его основным недостатком является добавление тонны дополнительных пакетов для взлома и необходимость их сохранения в виде отдельных пакетов.

Что еще я могу сделать? Какая правильная вещь?

Ответы

Ответ 1

За исключением дополнительной системы зависимостей в самой системе упаковки (сама система упаковки), параметры не слишком хороши.

Один из вариантов заключается в следующем. Вы можете создать собственный дополнительный пакет для каждого дополнительного пакета, с которым вы можете интегрировать свой основной пакет.

Например, если вы хотите, чтобы lrucache интегрировался с binary, вы могли создать дополнительный пакет lrucache-binary, содержащий интеграцию (в этом случае введите экземпляры класса). Аналогично, новый пакет вашего собственного lrucache-nfdata для интеграции lrucache с nfdata.

Тогда, если кто-то хочет как lrucache, так и его интеграцию с binary, он может зависеть от [binary, lrucache, lrucache-binary] вместе.

Ответ 2

Что делать, если вы просто поддерживаете два пакета: lrucache, который зависит от множества разных вещей, а затем lrucache-lite (или lrucache-minimal), который больше или меньше того, что у вас есть сейчас. Затем, если люди хотят минимизировать свои зависимости, они используют облегченную версию, и если они не заботятся о наличии зависимостей zillion, они используют стандартную версию. Большая, вероятно, будет зависеть от облегченного, чтобы избежать дублирования кода.

Ответ 3

Немного поздно в игре, но мои два цента:

  • Открытый API библиотек (который включает экземпляры классов) никогда не должен изменяться в зависимости от флагов сборки или доступности пакета - он наказывается для разработчиков down-stream и поддерживающих дистрибутив пакетов.

  • Я добавлю зависимость без вопросов к чему-либо на платформе Haskell (за исключением, может быть, "unix" или "win32" или тому подобное).

Это все еще оставляет "двоичный", однако, согласно его странице Hackage, он доступен в нескольких дистрибутивах Linux, и по моему опыту он устанавливается на Windows. В этом случае я бы принял патч, но не сам автор.

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

Ответ 4

Я могу добавить флаги в lrucache.cabal, что позволит компилировать различные экземпляров. Это работает с минимальным минимальным списком зависимостей, кроме тех случаев, когда вы этого хотите. Но это ужасно в реальном мире, потому что вы не можете указывать флаги сборки в разделах, зависящих от сборки. Так что вы можете зависят от пакета с определенным флагом, но не указывают, что зависимость. Это быстро сводится к почти бесполезности.

Это может быть именно то, что вы говорите, не работает для вас выше, но можете ли вы включить импорт и определения классов в условно скомпилированный CPP прагмы? Я полагаю, что обернуто вокруг imports внутренних модулей, которые, в свою очередь, импортируют одну из ваших "необязательных зависимостей".

Я не пробовал это, но мне очень интересно знать ответ.