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

Question

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

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

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

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

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

Что еще я могу сделать? Что нужно сделать?

Answer 1

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

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

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

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

Answer 2

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

Answer 3

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

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

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

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

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

Answer 4

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

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

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