[Lisp] Pakethantering

[Linus Nordberg]

Hej!

Jag ägnade just en stund åt att försöka förstå lite mer av
paketinstallation och användning och har nu några nya kunskaper och en
fråga.


- Om cl+ssl saknar libssl.so och du sitter på ett Debian (-derivat) så
kan sudo apt-get install libssl-dev vara lösningen (istf att symlänka
själv och riskera att det går sönder om ett år i samband med något
till synes orelaterat).

- Om iolib gnäller över att cffi:foreign-pointer inte finns så kan det
bero på att releasad cffi (0.9.2) inte innehåller denna symbol. Något
åt det här hållet kan hjälpa (SBCL @ Debian):

$ wget http://common-lisp.net/project/cffi/tarballs/cffi-080106.tar.gz
$ tar xzf cffi-080106.tar.gz -C ~/.sbcl/site
$ rm ~/.sbcl/systems/cffi*.asd
$ for f in ~/.sbcl/site/cffi-080106/*.asd; do ln -s $f ~/.sbcl/systems/; done

Ev. måste man städa bort gamla .fasl-filer också. Dom hamnar tydligen
under
/var/cache/common-lisp-controller/<PID>/sbcl/local/<PATH>. Ytterligare
en kunskap för mig -- på FreeBSD hamnar .fasl direkt under
sås-katalogen i ~/.sbcl/site/<PACKAGE> men det här var onekligen
smart.


Så till frågan. Är det så här man gör (andra punkten)? Dels det här
manuella symlänkandet av .asd-filer och dels städningen av .fasl? Det
sistnämnda har jag sett någonting om där man specialiserar ngn
asdf-funktion så att den städar automagiskt men, återigen, är det så
"man gör"? I praktiken.

Jag hade nog två frågor egentligen: Är det vanligt att man releasar ett
paket som beror på features i ett annat paket som ännu inte är
releasade? (I det här fallet fick jag iolib-0.5.4 och cffi-0.9.2 genom
asdf-install, som fann dom på cliki.net antar jag.)

[Henrik Hjelte]

Ett långt och lite osammanhängande svar,
det finns flera skolor ang paketinstallation.
1. Att använda asdf-install
2. På debian: använda common-lisp-controller och debians paket.
3. Inte använda paket, istället arbeta med versionshanterade system direkt.

jag är lite skeptisk mot idén om "releaser", och så vill jag enkelt
kunna bidra med patchar om så behövs till de paket som finns,
så jag vill använda versionshanterade setup.
Distribuerade VC system som darcs gör det ju suveränt enkelt att
mixtra med pathcar, brancha osv.

Jag har en setup som är starkt inspirerad av en blogpost
från BIll Clementson: http://bc.tech.coop/blog/051004.html
Använder nästan endast darcs, och tailor för att konvertera
från andra system (typ cvs), och en katalogstruktur ungefär
som BC. Se beskrivningen nedan om någon är intresserad.

Svar på fråga 1:
Ja jag tror det, rensa gamla fasl filer och länka asd filer, men med
min setup länkar jag sällan asd filer manuellt.

Ett skript för att rensa gamla .fasl filer är oumbärligt:
#!/bin/sh
# Grep is: Make sure that no files below acl directory is removed
find -name "*.fasl" -print0 | grep -z -v /acl | xargs -0 rm

Svar på fråga 2:
Är det vanligt att man releasar ett
paket som ....
Det är inte direkt en stab av personer som kollar varje release,
det är en anledning till att jag inte riktigt tror på konceptet.
Så, jag skulle tro att det är vanligt att man gör fel avseende beroenden

Jag har en idé att göra en cpan eller asdf-install killer, men det
skulle basera sig på versionshanteringspatchar (darcs) och inte "releaser",
kombinerat med automatisk testning varje natt i olika miljöer som
körs i Xen/VmWare el dyl. Skriver lite på det i tunnelbanan då
och då, men tiden räcker inte riktigt till. Finns det ingen som
smyger på listan och vill ha idé till exjobb, och vill be en
stjärna på Lisp-himlen?

/Henrik



Directory structure: inspired by Bill Clementson
-------------------------------------------------

lisp/: The ~/lisp/ directory is the "root" directory for all lisp libraries
and source code.
docs/: The location of my local copy of the CL Hyperspec and a number of
other lisp-related documents.
site/: Contains all of the directories of lisp libraries that are installed
via asdf-install.
src/: Contains directories with lisp source code that I keep for reference
only or that can't be loaded with asdf.
systems/: Contains the symbolic links to the .asd files that are in the
~/lisp/site/* directories. These symbolic links are created automatically by
asdf-install.
pub-vc/: Code from version controlled repositories rater than asdf
vc/: own local darcs branches (working copies) of repos in pub_vc that I
have modified
systems-vc/: symlink to asd files in vc OR pub_vc
systems-other/: symlinks to asd files elsewhere on the computer
unstable/: Contains directories of "bleeding-edge" versions of lisp
libraries that I have downloaded from version control repositories.
Dynamically added by ~.swank.lisp

Scripts to update repositories:
-------------------------------------------------
lisp/pub-vc/update-ucw-stuff.sh :darcs pull of latest ucw repositories
lisp/vc/pull.sh : darcs pull from repositories in lisp/pub-vc

Scripts to make correct symlinks to .asd files:
-------------------------------------------------
/lisp/pub-systems-vc.sh : Erases all symlinks in systems-vc, then symlink to
all .asd files in lisp/pub-vc.
Use when you want to try the latest unmodified copy of ucw
#!/bin/sh
rm systems-vc/*.asd
# find asd files | show NOT matching _darcs | symlink
find /home/henrik/lisp/vc/ -name *.asd | grep -v _darcs | xargs ln
-s -t ./systems-vc/

/lisp/update-systems-vc.sh : Erases all in systems-vc, then symlinks to all
.asd files in lisp/vc (higher priority) and lisp/pub-vc (lower priority)
Use for my local branch of ucw
#!/bin/sh
rm systems-vc/*.asd
# find asd files | show NOT matching _darcs | symlink
find /home/henrik/lisp/vc/ -name *.asd | grep -v _darcs | xargs ln
-s -t ./systems-vc/
# If not in vc, take asd from pub-vc
find /home/henrik/lisp/pub-vc/ -name *.asd | grep -v _darcs | xargs
ln -s -t ./systems-vc/

Other relevant files
----------------------------------------
.asdf-setup : Setup asdf search paths, copied from Bill Clementsons blog
http://bc.tech.coop/blog/051004.html and slightly adapted
(push (conc-to-pathname *lisp-dirs* "systems/") asdf:*central-registry*)
(push (conc-to-pathname *lisp-dirs* "systems-vc/")
asdf:*central-registry*)
(push (conc-to-pathname *lisp-dirs* "systems-other/")
asdf:*central-registry*)
~/.sbclrc : Loads .asdf-setup (sbcl)
~/.clinit.cl : Loads .asdf-setup (allegro)

.asdf-install: Makes asdf install install at the right place.
(setf asdf-install:*locations*
'((#p"/home/henrik/lisp/site/"
#p"/home/henrik/lisp/systems/"
"Install at location specified in my .asdf-install file")))

Post by Linus Nordberg
Hej!
Jag ägnade just en stund åt att försöka förstå lite mer av
paketinstallation och användning och har nu några nya kunskaper och en
fråga.
- Om cl+ssl saknar libssl.so och du sitter på ett Debian (-derivat) så
kan sudo apt-get install libssl-dev vara lösningen (istf att symlänka
själv och riskera att det går sönder om ett år i samband med något
till synes orelaterat).
- Om iolib gnäller över att cffi:foreign-pointer inte finns så kan det
bero på att releasad cffi (0.9.2) inte innehåller denna symbol. Något
$ wget http://common-lisp.net/project/cffi/tarballs/cffi-080106.tar.gz
$ tar xzf cffi-080106.tar.gz -C ~/.sbcl/site
$ rm ~/.sbcl/systems/cffi*.asd
$ for f in ~/.sbcl/site/cffi-080106/*.asd; do ln -s $f ~/.sbcl/systems/; done
Ev. måste man städa bort gamla .fasl-filer också. Dom hamnar tydligen
under
/var/cache/common-lisp-controller/<PID>/sbcl/local/<PATH>. Ytterligare
en kunskap för mig -- på FreeBSD hamnar .fasl direkt under
sås-katalogen i ~/.sbcl/site/<PACKAGE> men det här var onekligen
smart.
Så till frågan. Är det så här man gör (andra punkten)? Dels det här
manuella symlänkandet av .asd-filer och dels städningen av .fasl? Det
sistnämnda har jag sett någonting om där man specialiserar ngn
asdf-funktion så att den städar automagiskt men, återigen, är det så
"man gör"? I praktiken.
Jag hade nog två frågor egentligen: Är det vanligt att man releasar ett
paket som beror på features i ett annat paket som ännu inte är
releasade? (I det här fallet fick jag iolib-0.5.4 och cffi-0.9.2 genom
asdf-install, som fann dom på cliki.net antar jag.)
--
Linus
_______________________________________________
Lisp mailing list
http://mailman.nocrew.org/cgi-bin/mailman/listinfo/lisp

[Ties Stuij]

Post by Henrik Hjelte
Ett långt och lite osammanhängande svar,
det finns flera skolor ang paketinstallation.
1. Att använda asdf-install
2. På debian: använda common-lisp-controller och debians paket.
3. Inte använda paket, istället arbeta med versionshanterade system direkt.
jag är lite skeptisk mot idén om "releaser", och så vill jag enkelt
kunna bidra med patchar om så behövs till de paket som finns,
så jag vill använda versionshanterade setup.
Distribuerade VC system som darcs gör det ju suveränt enkelt att
mixtra med pathcar, brancha osv.

Jag vill bara komplementera det här med att saga min erfarenhet är att
det är bäst att tar senaste utväklar version. Det har hänt mig flera
gänger att en pakket använder features som är inte med i officiella
versionen. Om man titta frän en annan sida, så är min erfarenhet att
en skedje bryter mer oftas när man tar releases istället av
cvs/darcs/git/etc..

Och jag skulle inte använda common-lisp-controller, eller emerge eller
nånt. Dom liggar oftas några releases efter realiteten.

/Ties

[Linus Nordberg]

"Henrik Hjelte" <***@evahjelte.com> wrote
Tue, 8 Jan 2008 16:15:07 +0100:

| Distribuerade VC system som darcs gör det ju suveränt enkelt att
| mixtra med pathcar, brancha osv.

Låter bra. Men hur gör man för att byta ut en version av PAKET? I
fallet cffi får jag en massa symbolkonflikter (jag tror att det beror på
att symboler exporteras om igen). Försökte lite lamt med UNINTERN av
(APROPOS-LIST "" :PAKET) men det verkar ganska fel.

[Ingvar]

Post by Linus Nordberg
| Distribuerade VC system som darcs gör det ju suveränt enkelt att
| mixtra med pathcar, brancha osv.
Låter bra. Men hur gör man för att byta ut en version av PAKET? I
fallet cffi får jag en massa symbolkonflikter (jag tror att det beror på
att symboler exporteras om igen). Försökte lite lamt med UNINTERN av
(APROPOS-LIST "" :PAKET) men det verkar ganska fel.

I en körande lisp? Med viss svårighet. Primärt är det DEFPACKAGE som
interagerar rätt dåligt med EXPORT/IMPORT, det är odefinierat vad som händer
om en DEFPACKAGE-form inte stämmer med nuvarande export-status av ett paket
(det är explicit OK om paketet INTE finns, då skapas det och symboler sätts
upp som formen angiver).

Då olika versioner av ett paket kan ha olika symbolsynlighet och det
vanligtvis inte finns automagiska fjukar för att synka symbolsynligheten så
klagas det. Eftersom det är odefinierat vad som händer är det HELT OK att
signalera ett ERROR snarare än ett CERROR och saker stannar fort.

I princip borde det inte vara speciellt svårt att introspektera detta (läs en
systemdefinition, jaga igenom alla filer m.h.a READ, snarare än LOAD,
identifiera alal DEFPACKAGE-former och se till att de synkar med någon slags
körande verklighet), men det är lite knepigare än att jag kan slänga ihop en
lösning i marginalen.

//Ingvar (släpper versionerade paket eller packade snapshots, bara)

[Ingvar]

Post by Henrik Hjelte
Ett långt och lite osammanhängande svar,
det finns flera skolor ang paketinstallation.

Jag såg precis att jag hade missat lite post på lisplistan.
Det där med hur man installerar saker verkar det finnas en hel del
åsikter om. Enligt min erfarenhet ska man i alla fall inte syssla med
operativsystemets paketsystem alls, eller *bara* använda det.
Kombinationer verkar bli konstigt.

Jag blandar ASDF och APT-baserade CL-paket, det funkar för det mesta (fast jag
borde egentligen sätta mig ner och bygga en omkompilerare så att jag slipper
att saker inte kan köra precis efter att SBCL blivit uppdaterat).

Post by Henrik Hjelte
Är det vanligt att man releasar ett
paket som ....
Det är inte direkt en stab av personer som kollar varje release,
det är en anledning till att jag inte riktigt tror på konceptet.
Så, jag skulle tro att det är vanligt att man gör fel avseende beroenden

Riktiga, testade och dokumenterade paket ska ha en färdig .asd fil man
kan peka ut i sin asdf:*central-registry* anser jag. Att ständigt leva i
versionshanteringsklientträsket (har ni märkt hur många
versionshanteringsklienter man måsta ha installerade numer? git, svn,
cvs, darcs m.fl.?!) tror jag är en linuxism, det som kallas "perpetual
beta hell". Lisp är iofs ett dynamiskt språk där du kan ladda på patchar
medan du kör processer i din world, men ändå. Det som oftast brukar
klagas mest på i Common Lispsammanhang är ju att de libbar som finns är
otestade, icke underhållna och svåra att finna. Personligen tror jag på
värdet av releaser! Det går att göra det, även om man är ensam och inte
har en stab.
Ingvar har väl lyckats med att ensam hacka fram nåt som är
mer än beta, testa det mer än en del andra jag sett, ge det ett
versionsnummer och distribuera det till folk med enbart en webbklient.
Praktiskt sånt.

Ähvanu? Har jag? Oj! :) Jag versionsnumrerar mina ASDF-paketerade saker på ren
reflex (de brukar dessutom ha ett allt-som-oftast relaterat versionsnummer i
tarbollen), men det är för att jag har stödverktyg för paketering och så. Fast
jag har faktiskt funderat på att bygga ett Annat Hack<tm>, i lisp, som
faktiskt kan introspektera ett ASDF-paket (fast då behöver jag, ju, markera
upp dokumentation och så, också). Jag tänkte mig i princip ett shellscript,
som startar en SBCL som kompilerar ASDF-filen (eller systemdefintionsobjektet)
till ett shellscript, som paketerar och signerar.

Post by Henrik Hjelte
Jag har en idé att göra en cpan eller asdf-install killer, men det
skulle basera sig på versionshanteringspatchar (darcs) och inte "releaser",
kombinerat med automatisk testning varje natt i olika miljöer som
körs i Xen/VmWare el dyl. Skriver lite på det i tunnelbanan då
och då, men tiden räcker inte riktigt till. Finns det ingen som
smyger på listan och vill ha idé till exjobb, och vill be en
stjärna på Lisp-himlen?

[snip]
Det snackar lite då och då om en lösning för autobyggande och
distribuerande. Det vore ju kul om någon kunde få med sig en signifikant
mängd med folk på en lösning. CPAN har jag personligen aldrig lärt mig
använda, men det anses ju av många vara perls stora styrka och det som
gjorde att det tog över världen. Kunde man bygga nåt sånt för lisp vore
mycket vunnet. Gary King har skrivit saker på sin blog på sistone om att
bygga nåt. Vete 17 vad det blir av det. Jag vet att ASDF-INSTALL inte
duger som det är, men det beror mest på att det är drabbat av single
point of failure-problemet.

CCLAN var ett tidigt försök, det är därifrån stora bitar av ASDF-INSTALL
kommer. Den stora vinsten med CPAN är att det finns ohygglomånga paket i det,
att det finns versionsnummer och beroenden som (tror jag) kan ta
versionsnummer i hänseende.

//Ingvar

[Ingvar]

Tja, dina projekt ser hyggligt välpaketerade ut. :)

Hare build-asdf-package ! Lös problemet en gång, bygg ett shell-script som datar
ihop dina paket och sedan är Bob din onkel. (finns att slanga ner:
http://src.hexapodia.net/build-asdf-package )

Intressant Annat Hack för ASDF introspektion. Det skulle inte vara så
dumt...

Vid närmare eftertanke borde det vara enklare att data en moj som
läser en ASDF-definition och sedan helt enkelt uppdaterar .version och
.filelist (eventuellt med lite mellanklister, så att man slipper joxa
med dokumentationen i ASDF-definitionen). Ska fundera på det och
kanske till och med knappa ihop en prototyp innan jag släpper
CL-Defence (ett spel i "Tower Defence"-traditionen, fast vagt
annorlunda, med en "väg" som definieras av en Bezier-kurva och man kan
köpa fler kontrollpunkter).

//Ingvar

[Ingvar]

Gah. Jag måste få tummen ur och fixa nåt släppbart själv snart.

Komplettera Vanlig Lisp innan 1:a april och släpp?

//Ingvar

[Linus Nordberg]

Ingvar <***@hexapodia.net> wrote
Tue, 29 Jan 2008 06:49:10 +0000:

| Jag blandar ASDF och APT-baserade CL-paket, det funkar för det mesta (fast jag
| borde egentligen sätta mig ner och bygga en omkompilerare så att jag slipper
| att saker inte kan köra precis efter att SBCL blivit uppdaterat).

clbuild?
http://common-lisp.net/project/clbuild/

[Ingvar]

Post by Linus Nordberg
| Jag blandar ASDF och APT-baserade CL-paket, det funkar för det mesta (fast jag
| borde egentligen sätta mig ner och bygga en omkompilerare så att jag slipper
| att saker inte kan köra precis efter att SBCL blivit uppdaterat).
clbuild?
http://common-lisp.net/project/clbuild/

Jag tror inte att ett tredje system för att hantera byggmojutter skulle göra
saker bättre. :) Jag har ingen som helst avsikt att sluta använda Debians
paketsystem och clbuild är i dagsläget inte ens i närheten av tillräckligt för
att jag orkar bryta mig ur APT+ASDF-install. Hm, fast... Skippy är supportat.
Men jag skulle fortfarande behöva bryta ut SBCL ur APT:s klor och det är för
jobbigt.

Att däremot installera en felhanterare som fångar "Aha! Laddar gammal FASL!
Kompilera om och fortsätt!" är enklare och löser faktiskt precis alla problem
jag i dagsläget ser (nämligen att jag glömmer att kolla om SBCL ska uppdateras
och sedan kompilera om Skippy, så snooper-körningen ballar ut under natten).

//Ingvar (insnöad)