Доброго времени суток всем.Тема актуальная, хотелось бы вербализовать ее как можно более подробно. Поэтому такой вот опрос:

1. Что конкретно Вам НЕ нравится в asdf-install
2. Что конкретно Вам НЕ нравится в cbuild.
3. Насколько полезным для себя Вы считаете использование методики сборки проектов, основанной на построении "песочницы", где создается избранное рабочее окружение.
4. Замечания, мысли, пожелания.

> Что конкретно Вам НЕ нравится в asdf-install
> Что конкретно Вам НЕ нравится в cbuild.
Это не portage :) Ну и по большому счёты - костыли. С asdf-install, впрочем, особо не работал (но слышал много не очень хорошего). clbuild, насколько я успел понять, может легко ставить только простые пакеты с простой процедурой инсталяции, плюс там слишком много берётся непосредственно из репозитариев, так что неизвестно что за систему ты получишь после обновления. Лучшее что сейчас есть - это portage и gentoo-lisp-overlay. Думаю, что оптимально было бы стремится к схожей системе, где для каждого пакета есть отдельное описание процедуры установки и что бы из этого описания можно было бы автоматом генерировать пакеты для различных дистрибутивов (целевых систем), либо ставить непосредственно средствами данной системы (т.е. обе эти возможности нужны).
> Насколько полезным для себя Вы считаете использование методики сборки проектов, основанной на построении "песочницы", 
> где создается избранное рабочее окружение

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

1. Не нравится в asdf-install.
1.1 asdf-install заточен на использование централизованного ресурса, cliki.net. Бывает, что cliki.net недоступен. Сайт слабо поддерживается (в частности, любой спаммер может зайти и изменить страницу, необходимую для инсталляции пакета).
1.2 На страницах cliki.net располагаются ссылки на внешние ресурсы. Бывает, что ссылки ведут в никуда.
1.3 Отсутствует версионирование. На странице не указывается версия пакета. Часто ссылка на архив исходников имеет вид package_latest.tar.gz, и нельзя понять, что за версия скачивается.
1.4 Если установлена старая версия пакета X, и устанавливается пакет Y, которому нужна новая версия X, то X не будет обновлен.
1.5 asdf-install делает непереносимые вещи: симлинки, вызывает gpg, вызывает tar
1.6 Нет возможности интегрироваться в пакетный менеджер дистрибутива
1.7 Нет управления системами (получить список, удалить, обновить и т.д.)
2. clbuild не пробовал, сказать мне нечего
3. Мне больше нравится, когда есть возможность установить и использовать общесистемные пакеты — мне это кажется гораздо более продуктивным и правильным. Но мне кажется иногда разумным создавать "песочницу" при распространении приложения в виде исходников (но при этом оставляя возможность использовать системные версии). Т.е., вот скажем может быть такая вот структура распространяемого приложения :
./my-app-1.0/
./my-app-1.0/src/ - тут лежат исходники
./my-app-1.0/src/my-app.asd - asd-файл для my-app
./my-app-1.0/deps/ - тут лежат зависимости
./my-app-1.0/deps/foo-0.1/foo.asd
./my-app-1.0/fasls/sbcl-linux-x86_64-1.0.34/ - тут лежат fasl'ы для быстрой загрузки
./my-app-1.0/image/sbcl-linux-x86_64-1.0.34-core - тут лежит сдампленный образ
./my-app-1.0/run.exe
./my-app-1.0/run.sh ;; или другие платформозависимые запускалки
Все это, конечно, может быть в архиве (как это принято в java; например, веб-приложение для j2ee распространяется в виде war-файла (web application archive), в котором лежат метаданные + данные веб-приложения (страницы + код) + зависимости в виде jar-файлов) и может быть некоторый установленный скрипт-"запускатель", который сделает с приложением, распространяемым в таком виде все, что нужно для запуска/установки. При этом за счет наличия зависимостей приложение может быть запущено в винде/маке, а в линуксе зависимости могут быть проигнорированы и приложение установлено в виде исходников.

>Что конкретно Вам НЕ нравится в asdf-install
>Что конкретно Вам НЕ нравится в cbuild.
Тем, что на винде ни одна из них не работает.

Как уже было сказано у asdf-install очень плохо с отслеживанием версий пакетов, практически её нет. Помнится мне asdf-install поставил IOLib с зависимостями, только ничего не заработало.
>>clbuild
>там слишком много берётся непосредственно из репозитариев, так что неизвестно >что за систему ты получишь после обновления.
Вообще то там практически всё из git/mercurial/darcs/svn/cvs. Авторы считают, что за счёт вытягивания HEAD/tip/etc ревизий достигается синхронизация версий пакетов. Надо сказать, что (в большинстве случаев она действительно достигается). Например у меня пару раз вылезал конфликт символов из-за новой версии closer-mop, но затем в cl-gtk2 стали использовать новую версию closer-mop и конфликты прекратились. Разработчики clime вообще велят сидеть на cvs и ничего -- нет ощущения от жизни как на вулкане. Кроме того clbuild легко позволяет добавлять свои проекты.
>>Что конкретно Вам НЕ нравится в clbuild.
>Тем, что на винде ни одна из них не работает.
Вообще то:
>It used to work on cygwin.
Подытоживая: если нужно быстро поставить нужные библиотеки с зависимостями (без привлечения пакетного менеджера системы) -- то это clbuild. Иначе ... впрочем петь дифирамбы gentoo-lisp-overlay -- это уже не ко мне.

s/clime/slime/ естественно

>Разработчики clime вообще велят сидеть на cvs и ничего -- нет ощущения от жизни как на вулкане.
Не могу не заметить, что у меня время от времени слайм ломался при обновлении.

> Разработчики slime вообще велят сидеть на cvs и ничего -- нет ощущения от жизни как на вулкане. 
Ну так это вопрос к их дисциплине и организации процесса разработки, если они гарантируют, что в главной ветке всегда стабильная версия, то конечно. Т.е. что бы сидеть на версии из репозитария это нужно быть уверенным в желании разработчиков держать там только стабильную версию. Но разве разработчики других пакетов дают такие возможности? А отсутствие существенных проблем на практике скорей всего означает низкую скорость разработки большинства пакетов.

Я тут пока водичку подогреваю, но кой-какие соображения есть. Почему бы не организовать распределённый репозиторий типа git со специальной оболочкой, в которой можно выбрать версии всех нужных библиотек. Текущее состояние этой как бы "песочницы" автоматом отправляется на "трекер" и от него же загружается список возможных репов-источников перед установкой. Также если где-то возник конфликт, можно эту инфу тоже на трекер отослать, и если кто-то выберет такой же набор, перед загрузкой сразу увидит предупреждение. Такой типа осёл - "Donkey-Style Fucken Asdf" (dsfa). :)

libcl.com?
"LibCL is a self-contained collection of portable, free Common Lisp libraries. 
Today, it has the feel of a linux distribution -- a bundle of packages that are mostly developed independently. Tomorrow, it will grow into a more cohesive system, built around a community of developers who write Common Lisp."

Если уже на то пошло, то lispy Сравнение с другими системами
Типичная проблема Common Lisp'а: вы редко в нём найдёте один способ решения какой то проблемы, скорее всего вы найдёте зоопарк этих самых способов (а когда ни один из предложенных способов вас не устроит, то вы ещё увеличите количество этих самых способов).  

>Вообще то: It used to work on cygwin.
Cygwin это... Ну вобщем, проще линукс поставить.

> вы редко в нём найдёте один способ решения какой то проблемы,> скорее всего вы найдёте зоопарк этих самых способов

Полагаю, что дело в отсутствии хороших решений ;)

> типичная проблема Common Lisp'а: вы редко в нём найдёте один способ решения
> какой то проблемы, скорее всего вы найдёте зоопарк этих самых способов
В коммерческих версиях (Lispworks & Allegro CL) все в разы лучше и без зоопарков.

> В коммерческих версиях (Lispworks & Allegro CL) все в разы лучше и без зоопарков.
Что "всё"? Совсем "всё"?

>>Что конкретно Вам НЕ нравится в asdf-install
>>Что конкретно Вам НЕ нравится в cbuild.
>Тем, что на винде ни одна из них не работает.
Плоностью  поддедживаю это мнение! Посему, приходится многие вещи реализовывать самостоятельно "с нуля", вместо того, чтобы использовать готовое.

Пользовался и тем и другим. Минусы есть, точнее у clbuild нет за исключением его репа и bash-а.

Извиняюсь, небольшой up по техническим причинам :(

За хорошим менеджером пакетов посмотрите PLaneT http://planet.plt-scheme.org для plt-scheme. Примерно тот же asdf, но1. Есть версионифицирование.
2. Субъективно производит впечатление системы, которая "просто работает", в отличие от asdf, как это ни прискорбно.

Троллие с ЛОРа?
Каким местом asdf не работает?
Ну на винде я бы еще понял, хотя и то, у меня, например, на знакомство с азами ее ушло час максимум.
Но на других системах?!
Она именно что "просто работает".

> Троллие с ЛОРа
Очень приятно.
> Каким местом asdf не работает?
(asdf-install:install 'cells-gtk)
[...]
Server responded 404 for GET http://www.cliki.net/CL-CAIRO2-X11?download
(asdf-install:install 'commonqt)
[...]
Server responded 404 for GET http://www.cliki.net/COMMONQT?download
Возможно это проблемы админов CLiki.net, а не asdf.
И вот ещё недостаток. Не все пакеты можно уcтановить через asdf-install. т.е. он не считается стандартным всеобъемлющим репозиторием.
И ещё один. Чтения документации не хватило чтобы найти способ высказать эту Scheme'овую мысль в CL:
(require (planet jaymccarthy/sqlite:4:5/sqlite))
При отсутствии указанного пакета указанной версии он будет скачан и установлен, при его наличии имя пакета будет просто передано require.

>> Каким местом asdf не работает?
> (asdf-install:install 'cells-gtk)
naryl, ASDF-INSTALL не является частью ASDF и если ASDF-INSTALL не работает (а она действительно не работает), то это не имеет никакого отношения к ASDF, вы путаете совершенно разные понятия и системы. 

Прошу прощения, archimag. Тогда вот самый серьёзный недостаток asdf: Нет стандартной возможности убедиться в наличии пакета и автоматически установить его при его отсутствии.

> Нет стандартной возможности убедиться в наличии пакета и автоматически установить его при его отсутствии.
Задача ASDF загружать систему в образ. Ты не же требуешь, что бы ./configure автоматически загружал и компилировал недостающие зависимости? Управление пакетам это задача менеджера дистрибутива, но ни как не ASDF. Возможно, подобная возможность удобна для начинающих если хочется просто поиграться. Но к разработке реальных систем на практике это не имеет никакого отношения.

У всех менеджеров пакетов есть один серьёзный недостаток. Невозможно установить пакет, не имея доступа на запись в /. Этого недостатка лишены как asdf-install, так и planet.
Тогда нужно чинить portage, dpkg и т.д., впрочем это уже оффтопик. :)

> У всех менеджеров пакетов есть один серьёзный недостаток. Невозможно установить пакет, не имея доступа на запись в /. 
В чём суть недостатка? Что левый пользователь не может поломать систему?
> Тогда нужно чинить portage, dpkg и т.д.,
Точно, именно это и надо делать.
> впрочем это уже оффтопик
Почему? Я  считаю "самым правильным" иметь мета-описание пакетов, из которых будут автоматически генерироваться пакеты для различных дистрибутивов.

> В чём суть недостатка?
Невозможность установки левого софта без помощи root'а. root по понятным причинам редко соглашается ставить левый софт. Если нужно что-то, чего в системе нет - ставь из сорцов себе в home и надейся, что разработчик предусмотрел такую возможность. В обход менеджера пакетов в любом случае. Да и
> Что левый пользователь не может поломать систему?
некоторый софт как-раз таки во избежание поломки системы лучше в / не ставить.

Только ИМХО это уже совсем оффтопик для этого форума. :)

naryl, да это всё мне кажется не очень существенно. Главная проблема для меня - CL-пакеты не являются вещью в себе, где-то что-то надо компилировать, другие зависят от каких-то внешних "не CL" пакетов. И системы типа asdf-install и clbuild не в состоянии это разрулить и попытка обойтись без системного менеджера пакетов превращается в танцы с бубном. Для Gentoo сейчас есть gentoo-lisp-overlay и это прекрасно. Если бы схожий набор пакетов появился для Debian, то все эти asdf-install по большей частью умерли бы за ненадобностью. turtle начал эту работу, но, вероятно, его ресурсы (как и энтузиазм) ограничены.

А вот идея касательно распространения готовых приложений на Common Lisp, с помощью которой можно избавиться от мук, связанных с распространением приложений, созданных с помощью свободных реализаций Lisp, как образов и лисп-рантайма и даже добиться некоторой кроссплатформенности.
Имеется архив, подобный jar, с определенной структурой и зарезервированным расширением (скажем, lispx):
/
/lib/
/application.lisp
/application.meta

Корневая директория и все поддиректории /lib/* рассматриваются как ASDF-репозитарии (т.е. добавляются в asdf:*central-registry* перед выполнением приложения).
Файл application.meta содержит некоторые метаданные о приложении (предпочтительная реализация CL для выполнения на, подсистема [консоль, графическая] и т.п.).
Файл application.lisp является точкой входа и загружается первым при выполнении приложения.
На целевой системе устанавливается некое приложение-прокси - системный обработчик расширения архива. Оно отыскивает, или выбирает из явно указанных, установленную в системе реализацию CL, передает ей архив для выполнения, перед этим, заставляя ее выполнить некий промежуточный код, необходимый для загрузки файлов в архиве. Таким образом, мы можем выполнять такие приложения как обычные системные приложения ОС.
Единственная сложность здесь - нужно будет создать серьезный промежуточный слой между ASDF и библиотекой для работы с архивами либо продумать кэш скомпилированного кода, чтобы не распаковывать и компилировать все приложение каждый раз.
Как вам такая идея?

Я не очень понял чем это отличается от общей схемы установки в большинстве пакетных менеджеров :) Архив или тот или иной способ паковать файлы с метаинформацией (или без), прослойка которая занимается развёртыванием - это всё очень общие вещи.
Сейчас существует по крайней мере 12 решений (список тут). Из них http://www.quicklisp.org/ сейчас больше всех хочет быть универсальным (но пока не понятно что там и как). А ещё вот lisp-cabinet 13 появился :)
Лично мне правильным кажется подход, который я описывал в этой теме - но это только задумка.

Нет, здесь речь идет не о пакетном менеджере для библиотек, а о способе распространения уже готовых приложений (которые понетциально включают в себя все необходимые зависимости), как новой вехе, так сказать, в мире свободных реализаций Common Lisp.
Т.е. сейчас для того, чтобы создать дистрибутив приложения с помощью свободной реализации Common Lisp требуется создать образ лисп-среды и распространять его с платформо-зависимым рантаймом. Предлагаемый же способ позволяет распространять приложение в исходных кодах, потенциально способное выполняться на любой системе, где установлена одна из реализаций CL и приложение-прокси для обработки архивов. Т.е. фактически предлагается создать некий стандарт для паковки распространяемых приложений и общисистемное ПО для поддержки их выполнения в таком виде подобные jar/JRE (однако, из за зоопарковости лиспов, он конечно будет не так консистентен, как последние).
Или потребности в таких средствах нет, так как Лисп приложения исполюзуются либо на серверах, либо самими разработчиками в рамках среды разработки?
Изменит ли создание подобных средств такое положение вещей?

> Изменит ли создание подобных средств такое положение вещей?
Мне кажется что подобные средства создаются очень просто - для этого нужно сложить директории всех проектов в одну директорию /path/to/general-libs и добавить в корень файл setup.lisp
(in-package :asdf)
(defun define-searcher (path)
  (lambda (system)
    (let ((latter-path (make-pathname :name      (coerce-name system)
                                      :directory (list :relative :wild)
                                      :type      "asd"
                                      :version   :newest
                                      :case      :local)))
      (let* ((wild-path (merge-pathnames latter-path path))
             (files (directory wild-path)))
        (when files
          (first files))))))
(pushnew (define-searcher #p"/path/to/general-libs/") *system-definition-search-functions* :test #'equal))
Далее из любой реализации загружается setup.lisp и по (require :lib-x) (при наличии хука на require) загружется lib-x со всеми зависимостями именно из среза /path/to/general-libs - компилируется, инкрементально обновляется и т.д. ASDF это всё делает.
Т.е. это вопрос простого распространения а не программирования. Было бы что распространять :) А вот после распространения уже встаёт вопрос об обновлении - это уже пакетный менеджер. Я например пока все распространяю банально поставив хук в ASDF который не найденные библиотеки скачивает/обновляет из git (т.е. без политики версий - всё самое последнее), для этого же зеркал назаводил.

Частично, идея из поста http://lisper.ru/forum/thread/145#comment-4314 была реализована тут: http://lispx-proxy.sourceforge.net/
Получился пока лончер командной строки, который, конечно, был добавлен в последнюю версию Lisp Cabinet-а. Подробнее здесь:
http://rsdn.ru/forum/decl/3991180.1.aspx

Советую ещё попробовать включить в lispcabinet http://www.quicklisp.org/ - вероятно, что ими будет поддерживаться большое количество пакетов, поэтому это облегчит их централизованное развёртывание при наличии в базовой поставке минимального по объёму среза системы :)

treep, ты писал в конференции что это "просто работает". И что, даже не нашлось ложки дёгтя? :))

Я пока крупномасштабного тестирования не проводил (так чтобы вообще всё удалить и поставить с помощью quicklisp - неохота, так как всё и так работает), но с задачами своими quicklisp вполне справляется - работает быстро, на обеих ОС что мне нужны, за версиями и зависимостями следит, ну и вообще интерфейс хороший. То есть да - пока претензий нет :) Собственно, и PR тоже хороший :)

Have I said yet how awesome Quicklisp is? All Common Lispers should check it out. — Peter Seibel
I must say that I am pleased and impressed. — Hans Hübner
Quicklisp is exactly the system I would have built. — Drew Crampsie
Quicklisp is really what you always wished existed for installing and managing Common Lisp libraries. — Jorge Tavares
I've been trying out Quicklisp for a while now, and am duly impressed. — Nikodemus Siivola

Где можно почитать, что из себя этот quicklisp представляет? Чем отличается от существующих asdf-install и clbuild?

В основном можно посмотреть, здесь: http://www.quicklisp.org/

> В основном можно посмотреть, здесь: http://www.quicklisp.org/
Там всего четыре странички. Информации ноль.
Не понятно, как оно устроено. Там централизованный каталог библиотек? Тогда, чем это лучше asdf-install?

> Где можно почитать, что из себя этот quicklisp представляет?
Есть примеры базовых команд на страничке беты (и это пока только бета), есть скринкаст. Т.е. с точки зрения пользователя представляет из себя обычный пакетный менеджер с типичным набором команд - названия пакетов, поиск пакетов по словам, версии, зависимости, установка/обновление/удаление, проверка md5sum, пакеты связаны с URL (в принципе не только с их сервера, но пока они все библиотеки сначала к себе архивируют, потом привязывают url, у официальных portage кстати также, это по крайней мере решает проблему недоступности пакетов). Конечно, это по прежнему не portage, но уже очень хорошо :)
Файл quicklisp.lisp из quicklisp-bootstrap устанавливает quicklisp-client и скачивает информацию о известных системах в два plain-text файла (отдельно [имя] + [url] + [hash] + [asdf файлы], отдельно [имя] + [список зависимостей]).
> Чем отличается от существующих asdf-install
От asdf-install отличается во-первых стабильностью работы на windows, во-вторых quicklisp-projects содержит гораздо больше более свежих портов, в-третьих в будущем возможна децентрализация (по крайней мере технически в этом пробле нет), в-четвёртых в SBCL quicklisp скорее всего заменит asdf-install, ну и сам код quicklisp просто больше - система более полноценная чем asdf-install.
Ну и ещё 50 последователей на github и уже форки с обратным вливанием кода - просто активность, который нет ни у одного подобного проекта (а таких около пяти штук всего).

Посмотрел quicklisp. Очень и очень обнадёживающе. Всё максимально просто и понятно.
Никаких сюрпризов не было (ubuntu linux, sbcl). Если и дальше всё будет в таком духе, то это просто Класс!

Подтверждаю ещё раз, потому что это важно :) Работает без всяких нареканий на системах:

• GNU/Linux (Gentoo, Ubuntu - проверял, ну и так далее) / SBCL,
• Windows Vista, Windows 7 / SBCL (и 1.0.37, и версия с тредами).

Думаю, нужно будет написать доку по базовым командам.

Попытка добавить Quicklisp в Lisp Cabinet: http://rsdn.ru/forum/decl/3997953.1.aspx
Работает со всеми включенными в Lisp Cabinet CL-реализациями, за исключением ECL.
Так как его система версионирования отличается от оной у ASDF-INSTALL (похоже, он просто выкладывает репозитории систем управления версиями, используемых для хранения исходного кода самих библиотек), то совместно их использовать вряд-ли получится, и нужно будет оставлять что-то одно (пока они используют разные репозитории, хотя, может быть так их следует и оставить). Пока предпочтение отдается ASDF-INSTALL, так как ASDF2, используемый QuickLisp-ом, не очень совместим с ASDF-BINARY-LOCATIONS, и встроенными ASDF большинства реализаций CL.

> ASDF2, используемый QuickLisp-ом, не очень совместим с ASDF-BINARY-LOCATIONS
Конечно, ведь при использовании ASDF2 пакет asdf-binary-locations больше не нужен ;)

Да, но переводить встроенные ASDF на ASDF2 может быть чревато (по крайней мере сразу нельзя сказать насколько это будет безоблачно), поэтому, возможность по релокации скомпилированных файлов пришлось отключить и использовать все тот же ASDF-BINARY-LOCATIONS. Однако, ASDF2 компилирует сам ASDF-BINARY-LOCATIONS (чего он по идее не должен бы делать) в место его установки, поэтому, чтобы этого избежать, нужно извращаться (можно просто загрузить основной файл ASDF-BINARY-LOCATIONS и не использовать его как ASDF систему).

Сейчас под виндой пробовал один код и получил жалобу `undefined function: ITER', я написал
(ql:quickload "iterate")
и через пару секунд продолжил свои эксперименты. Мелочь, а приятно :)