Re: package management
- From: Maciek Pasternacki <maciekp@xxxxxxxxxxxxxxx>
- Date: Thu, 13 Dec 2007 18:13:30 +0100
On Mon, 10 Dec 2007 19:38:17 +0200
Kamen TOMOV <kamen@xxxxxxxxxxx> wrote:
Am I the only one who has difficulties from doing package management
in CL? I'm wasting huge resources to deal with that and I'm looking
for a methodology to deal with it once and for all.
Shameless plug: http://www.pasternacki.net/en/code/cl-librarian . I am
developing it (it's a work in progress) and I use it for managing libraries
in my projects. It was already mentioned in this thread, but I'd like to
expand on your problems.
Currently on my machines live the following types of packages:
1. asdf-install-ed packages;
CL Librarian can fetch packages from ASDF-Install (no GPG signature checking
though) and tarballs with http (actually, with any protocol that is supported
by wget).
2. CVS (and similar) packages;
Fetching packages from version control systems (CVS, SVN, and darcs are
supported, plugins for other systems are possible. I am considering at least
Bazaar-NG, Mercurial, and git. Arch/baz will not be supported, unless
someone else writes and tests the code -- I can't handle those, I need a
tutorial to simply check out the code).
3. Packages installed using the OS package management;
No support. If your Lisp implementation can see those by default, you can
use those. I don't consider support in Librarian, because:
- Every distribution has its own system for package management and one
should use it for managing distribution's packages,
- Distribution's library packages are meant to be used by applications from
distribution, these are often outdated and/or not really suited for
new application developers (or maybe I just don't understand
common-lisp-controller),
- I develop Librarian to scratch my own itch, and distribution's package
management doesn't itch me, since I just don't use those in my work. If
someone has an idea (and implementation) how Librarian would be able to
interact with those, I will consider it and probably include with
Librarian.
When I don't use PLD Linux Distribution, which I co-develop and am able to
compile newest package from CVS repo (usually updating .spec files by the
way), I even ignore distro's Lisp implementation and install sbcl locally
in /usr/local. This way I can get relatively current version with no hassle,
and no c-l-c getting in my way.
4. Packages that I developed;
It is supported, since you keep your packages in some kind of version
control, don't you? If you don't, just import into darcs. Or, you can use
tarballs from http or local filesystem as well.
5. Packages that got shipped with other packages;
Also no problem, supposing those packages-in-packages have .asd files in
top-level directory of package, or that package's .asd file takes care of
setting necessary paths. Using .asd files from packages' subdirectories is
on my TODO list.
I have plenty of issues. I update a package to the latest version to
find out that I had to update another package that had higher
priority.
Central concept in Librarian is a `library shelf', which is a set of
libraries. Such shelf should be updated at once. If you want to freeze some
package, use tarball (TODO: specify branches/tags of repository).
There is no actual support for updating yet, but it should not be much work.
Installing new machine is a lot of work.
Not anymore ;) I think I will put up a skeleton project out of my first
serious Librarian deployment as a usage example.
Sometimes the
software works on one of the machines and not on the other.
I didn't try to solve any portability issues (that's one more reason to just
ignore distribution-provided Lisp libraries), and I have no idea how a
Librarian could be useful for this. I just use compatibility layers, like
usocket, to handle differences.
I also have problems with old FASL files.
I haven't thought of this yet, one more thing to the TODO section. It will
certainly be useful.
One more thing: Librarian works only with ASDF systems. (LOAD "load.lisp")
style packages are not and will not be supported. You can work around this
by creating fake .asd files that loads load.lisp. MK-Defsystem is also not
supported (unless someone helps me with supporting it -- I didn't ever need
to use it and I don't suppose I will).
Regards,
Maciej
--
__ Maciek Pasternacki <maciekp@xxxxxxxxxxxxxxx> [ http://japhy.fnord.org/ ]
`| _ |_\ / { -It's possible that people in my life are actually detrimental
,|{-}|}| }\/ to what I'm trying to do right now--And what is it you're trying
\/ |____/ to do? -- I'm trying to stay sane. } ( I Feel Sick ) -><-
.
- Follow-Ups:
- Re: package management
- From: Kamen T
- Re: package management
- From: Maciej Katafiasz
- Re: package management
- References:
- package management
- From: Kamen TOMOV
- package management
- Prev by Date: Re: multicore lisp?
- Next by Date: Re: array-iota
- Previous by thread: Re: package management
- Next by thread: Re: package management
- Index(es):
Relevant Pages
|