Re: package management



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 ) -><-

.



Relevant Pages

  • Re: package management
    ... Fetching packages from version control systems (CVS, SVN, and ... No support. ... Librarian is meant to create complete ... Such shelf should be updated at once. ...
    (comp.lang.lisp)
  • Re: package management
    ... Fetching packages from version control systems (CVS, SVN, and darcs ... No support. ... Librarian is meant to create complete self-contained ... Such shelf should be updated at once. ...
    (comp.lang.lisp)
  • Re: package management
    ... CL Librarian can fetch packages from ASDF-Install (no GPG signature ... No support. ... I don't consider support in Librarian, ... distribution has its own system for package management and one ...
    (comp.lang.lisp)
  • Re: Anybody Tried Novell Desktop Yet?
    ... who will pay out for the support ... > upgrades for NLD as a default. ... Which is a place where users are not normally allowed to install their own ... software or upgrade packages themselves; it is all done in a controlled ...
    (alt.os.linux.suse)
  • Re: ANN: some new freeware and freeware updates for VMS
    ... Mozplugger will activate XPDF ... > provide great support for viewing those web pages with sound on them. ... > allows one to specify a URL as the MP3 filename so that it works on VMS. ... > All of the packages build without error on any supported version of VMS. ...
    (comp.os.vms)