Как обрабатывать запросы функций, которые добавляют новые зависимости пакета
Я поддерживаю пакет для взлома, 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
внутренних модулей, которые, в свою очередь, импортируют одну из ваших "необязательных зависимостей".
Я не пробовал это, но мне очень интересно знать ответ.