Куда относятся экземпляры QuickCheck в пакете Cabal?

Question

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

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

Мои идеи в произвольном порядке:

• Оставитьэкземпляр Arbitrary рядом с определением типа, и пусть клиенты занимаются теневым копированием или переопределением номера версии QuickCheck.
• Сделайте экземпляр Arbitrary потерянным экземпляром в отдельном модуле в том же модулепакет, скажем Data.NBT.Arbitrary.Зависимость от QuickCheck для всего пакета сохраняется.
• Предложите экземпляр Arbitrary в совершенно отдельном пакете, чтобы его можно было перечислить в качестве отдельной тестовой зависимости для клиентских проектов.
• Условновключите в основной пакет и экземпляр Arbitrary, и зависимость QuickCheck, но только если установлен флаг типа -ftest.

Я видел комбинации всех этих элементов, используемых в других библиотеках, но не нашли единого мнения о том, что работает лучше всего.Я хочу попробовать и получить это прямо перед загрузкой в ​​Hackage.

Answer 1

Исходя из небольшого конкретного опыта, но общего стремления к надежности, руководящий принцип для зависимостей пакетов, вероятно, должен быть

От каждого в соответствии с их способностями;каждому в соответствии с их потребностями.

Хорошо бы сохранить зависимости пакета до минимума, необходимого для его существенной функциональности.Это предполагает вариант 3 или вариант 4 для меня.Конечно, очень тяжело раскалывать посылку.Если варианты способны выразить обусловленные условия, тогда вариант 4 звучит как разумный подход, основанный на эффективном использовании языка, чтобы сказать, что вы имеете в виду.нужно щелкнуть, чтобы получить набор для тестирования, а также основные функции.

Также ясно, что здесь есть место для доработки.Удивительно, что Cabal работает так же хорошо, как и он, но он может допускать более сложные понятия «пакет», возможно, в духе модульной системы SML.Преобразуя зависимости в типы функций, мы в основном пишем

simplePackage :: (Dependency1, .., Dependencyn) -> Deliverable

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

fancyPackage :: BasicDependency -> (BasicDeliverable, HelpfulExtras -> Gravy)

. А пока выберите вариант, который наиболееточно отражает фактическую сделку.И расскажите нам об этом, чтобы мы могли достичь этого консенсуса.

Answer 2

Проблема заключается в следующем: насколько вероятно, что кто-то, использующий вашу библиотеку, захочет запустить тесты QuickCheck, используя ваш тип NBT?

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

Если тип является в основном внутренним по своей природе и вряд ли будет использоваться другими, желающими запустить тесты, то использование флага для условного включения QuickCheck, вероятно, является лучшим способом избежать ненужных зависимостей (т. Е. Набор тестов там просто так вы можете проверить пакет).

Я не фанат пакетов QuickCheck-only в целом, хотя в некоторых ситуациях это может быть полезно.