Hi,
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.
Currently on my machines live the following types of packages:
1. asdf-install-ed packages;
2. CVS (and similar) packages;
3. Packages installed using the OS package management;
4. Packages that I developed;
5. Packages that got shipped with other packages;
It's a hell of a job to deal with this without prior planning,
especially if one manages more than one machines.
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. Installing new machine is a lot of work. Sometimes the
software works on one of the machines and not on the other. I also
have problems with old FASL files.
How do you deal with the problem? Is ASDF a norm these days? What
about common-lisp-controller - do you use it?
Thanks,
--
Kamen
On Dec 10, 12:38 pm, Kamen TOMOV <·····@cybuild.com> wrote:
> Hi,
>
> 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.
>
> Currently on my machines live the following types of packages:
> 2. CVS (and similar) packages;
I know you are looking for a one-stop-shop, but nonetheless this:
http://common-lisp.net/project/clbuild/
appears to be tailored for package management based on packages under
source control.
"metaperl.com" <········@gmail.com> writes:
> On Dec 10, 12:38 pm, Kamen TOMOV <·····@cybuild.com> wrote:
>> Hi,
>>
>> 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.
>>
>> Currently on my machines live the following types of packages:
>
>> 2. CVS (and similar) packages;
>
> I know you are looking for a one-stop-shop, but nonetheless this:
> http://common-lisp.net/project/clbuild/
>
> appears to be tailored for package management based on packages under
> source control.
You might also like CL-librarian:
http://www.pasternacki.net/en/code/cl-librarian
I haven't tried it yet, but it's on my list.
--
Albert Krewinkel
On Mon, Dec 10 2007, Albert Krewinkel wrote:
> "metaperl.com" <········@gmail.com> writes:
>
>> I know you are looking for a one-stop-shop, but nonetheless this:
>> http://common-lisp.net/project/clbuild/
>>
>> appears to be tailored for package management based on packages
>> under source control.
>
> You might also like CL-librarian:
> http://www.pasternacki.net/en/code/cl-librarian
>
> I haven't tried it yet, but it's on my list.
Thanks! These look interesting, especially cl-librarian. However, I
couldn't find my way there fast enough, so I decided to check it up
some other time.
--
Kamen
Kamen TOMOV 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.
A side comment: The term "package" means something different in Common
Lisp. The things you're dealing with are called "modules" in the ANS
(although the ANS provides pathetically little machinery for dealing
with them) but more reasonably called "systems" as defined by various
implementations of defsystem, e.g. in asdf.
On Tue, Dec 11 2007, Steven M. Haflich wrote:
> A side comment: The term "package" means something different in
> Common Lisp. The things you're dealing with are called "modules" in
> the ANS (although the ANS provides pathetically little machinery for
> dealing with them) but more reasonably called "systems" as defined
> by various implementations of defsystem, e.g. in asdf.
Note taken.
It would be a great advancement if the standard is extended in this
direction.
--
Kamen
Kamen TOMOV <·····@cybuild.com> wrote on Tue, 11 Dec 2007:
> On Tue, Dec 11 2007, Steven M. Haflich wrote:
>> The things you're dealing with are more reasonably called "systems" as
>> defined by various implementations of defsystem, e.g. in asdf.
>
> It would be a great advancement if the standard is extended in this
> direction.
Why can't you just use ASDF? How would your life be significantly easier
if ASDF were formally added to the ANSI specification, as opposed to your
ability today to simply just use it?
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ ···@geddis.org
I'm like the guy who tells the psychiatrist that his brother thinks he's a
chicken, but refuses to bring him in because he needs the eggs.
On Tue, Dec 11 2007, Don Geddis wrote:
> Kamen TOMOV <····@cybuild.com> wrote on Tue, 11 Dec 2007:
>> On Tue, Dec 11 2007, Steven M. Haflich wrote:
>>> The things you're dealing with are more reasonably called
>>> "systems" as defined by various implementations of defsystem,
>>> e.g. in asdf.
>>
>> It would be a great advancement if the standard is extended in this
>> direction.
>
> Why can't you just use ASDF?
I use it.
> How would your life be significantly easier if ASDF were formally
> added to the ANSI specification, as opposed to your ability today to
> simply just use it?
I never said that. I said that it would have been great if the
standard was extended.
I wish we had a big good standard for module management that everybody
who distributes modules likes and complies with.
Anyway, now that you mentioned ASDF let me elaborate on it. ASDF is
very popular so it seems we have a winner and that's a good
start. However, ASDF doesn't address plenty of requirements one might
have and it has some current issues.
First of all, I wish it was better documented.
For example I recently tried to improve a piece of code. The problem
was that in one of the systems I wrote I had different configurations
that needed to be enforced during ASDF:OOS of the system. So I had:
(defsystem "foo" :serial t :depends-on (:bar) :components ((:file
"config") (:file "start-something") (:file "baz")))
"start-something" is an operation and in order to have it executed
after dealing with "bla.lisp" and before dealing with "baz.lisp" I had
to create a file "start-something.lisp" and put the operation there.
Next I tried something like this:
(defsystem "foo" :serial t :depends-on (:bar) :components ((:file
"config") (:file "baz" :perform (start-something))))
But, this approach had plenty of issues. First of all
(start-something) usually would use symbols that are defined in a file
that is part of one of the :file sections - which creates a vicious
circle.
So I looked the documentation up and couldn't figure out if I can do
that properly and within a reasonable amount of time so I dropped it
and now it is as it was - ugly.
I also wanted to load some of the systems in a
ext:without-package-locks form and I also couldn't figure out how to
do that.
Another issue was loading dependencies conditionally. For example
sometimes I want SWANK and other times - I don't. I couldn't define
that in the "config.lisp" file as :swank belongs to the :depends-on
section. In result I had the options either not to use ASDF or wrap it
in a macro definition. To be honest I didn't do either of those yet
and I load files manually.
All in all - if only ASDF was documented as in the HyperSpec. Yes, I
know it is open source and nobody owes me anything - thanks for
suggesting anyway.
ASDF has also some other issues that were discussed here recently so I
won't go any further.
Let me tell you about what we could have instead.
ASDF could require specifying which Lisps are supported in a system so
that when one looks at an ASDF file, he would be able to find that out
without inspecting the code.
ASDF could include an unit-test infrastructure (by the way I'm not
sure it doesn't have, but if it does - not many ppl use it).
We could have a module management system that deals with external
dependencies. Just imagine a world where one could type:
(asdf:oos 'asdf:load-op :my-great-system)
And the system would find, obtain, install, compile, load everything
one might need.
Not to mention that I'd love it if our module management system was
integrated with a version control system so that one doesn't have to
deal with CVS, git, darcs, Subersion and hell knows what else. It
could include a VCS abstraction layer so that we don't have to deal
with the particular VCS details. Speaking of VCS don't even ask me
what my requirements for it might be because I could tell you that I
would like it to understand some language semantics and be form based
and not file based.
Anyway, my list can go on and on and it might never be perfect if I'm
doing it alone. However, if that was a preposition for a standard and
we discussed it and agreed on it in a committee, the result would
probably be good as the CL standard is.
--
Kamen
Kamen TOMOV <·····@cybuild.com> writes:
> [...]
> Next I tried something like this:
>
> (defsystem "foo" :serial t :depends-on (:bar) :components ((:file
> "config") (:file "baz" :perform (start-something))))
>
> But, this approach had plenty of issues. First of all
> (start-something) usually would use symbols that are defined in a file
> that is part of one of the :file sections - which creates a vicious
> circle.
> [...]
You could write:
(defsystem "foo"
:serial t
:depends-on (:bar)
:components ((:file "config")
(:file "baz" :perform (funcall (find-symbol "START-SOMETHING" "BAZ")))))
--
__Pascal Bourguignon__
On Mon, 10 Dec 2007 19:38:17 +0200, Kamen TOMOV <·····@cybuild.com> 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.
>
> Currently on my machines live the following types of packages:
>
> 1. asdf-install-ed packages;
> 2. CVS (and similar) packages;
> 3. Packages installed using the OS package management;
> 4. Packages that I developed;
> 5. Packages that got shipped with other packages;
>
> It's a hell of a job to deal with this without prior planning,
> especially if one manages more than one machines.
Yeah, but I don't think it's very different from, say, managing Perl
libraries or something similar. You either trust that some external
entity (the Debian guys, the Lisp developers who cater to
ASDF-INSTALL, the CPAN guys, whoever) will make sure all the libraries
you need are automatically installed (in the right version) or you
don't. I've come to a point where I have /one/ directory which
contains all of the Lisp libraries I use (including my own) and I
update them when needed, either from a release tarball or from some
version control mechanism. I don't use ASDF-INSTALL, and on my Debian
boxes I don't use the Debian package system for Lisp libraries.
As for packages that ship with other packages - I think that's a bad
idea anyway and I would complain to the maintainers.
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
On Mon, 10 Dec 2007 19:24:28 +0100, Edi Weitz wrote:
> On Mon, 10 Dec 2007 19:38:17 +0200, Kamen TOMOV <·····@cybuild.com>
> Yeah, but I don't think it's very different from, say, managing Perl
> libraries or something similar. You either trust that some external
> entity (the Debian guys, the Lisp developers who cater to ASDF-INSTALL,
> the CPAN guys, whoever) will make sure all the libraries you need are
> automatically installed (in the right version) or you don't.
Note that:
1. "the CPAN guys" don't really exist as a coordinated group at all. It's
just that CPAN modules have some mechanisms to specify minimum versions
of their required libraries, so outdated modules will get automatically
updated if you install a library that depends on a newer version (which
is pretty limited, but seems to work most of the time, for modules that
are still under active development/maintenance).
As far as I can see there's no version management for asdf-install at all
or at least the packages I've looked at don't seem to specify any version
requirements (though I may be wrong, please correct me if so).
2. Even with CPAN, which is on avarage a pretty big success (and
certainly one of the biggest reasons I use perl), you may not want to mix
it with any other package management system (like debian's archives). For
perl I prefer to have a system perl managed via debian packages so that
all debian packages that rely on perl will work provided the maintainer
is awake, and a completely separate perl that I maintain myself, mostly
via the CPAN installer, with additional packages installed "manually"
that I use to develop my own software. This can be done fairly easily on
debian by installing your "own" perl and its dependancies in /usr/local
and installing local packages using the local perl.
> I've come
> to a point where I have /one/ directory which contains all of the Lisp
> libraries I use (including my own) and I update them when needed, either
> from a release tarball or from some version control mechanism. I don't
> use ASDF-INSTALL, and on my Debian boxes I don't use the Debian package
> system for Lisp libraries.
Currently I'm tending towards this system too. But that's mostly because
I've found asdf-install to be unreliable. Currently I just use asdf-
install first and if that doens't work I remove/re-install the things
that don't work in ~/.sbcl/site etc. I would love to have asdf-install
work at least as well as perl's CPAN/CPANPLUS shells.
Joost
On Mon, Dec 10 2007, Edi Weitz wrote:
> Yeah, but I don't think it's very different from, say, managing Perl
> libraries or something similar.
Sure.
> You either trust that some external entity (the Debian guys, the
> Lisp developers who cater to ASDF-INSTALL, the CPAN guys, whoever)
> will make sure all the libraries you need are automatically
> installed (in the right version) or you don't. I've come to a point
> where I have /one/ directory which contains all of the Lisp
> libraries I use (including my own) and I update them when needed,
> either from a release tarball or from some version control
> mechanism.
Thank you - that's a good advise.
> I don't use ASDF-INSTALL, and on my Debian boxes I don't use the
> Debian package system for Lisp libraries.
>
> As for packages that ship with other packages - I think that's a bad
> idea anyway and I would complain to the maintainers.
What about common-lisp-controller - do you use it?
--
Kamen
On Tue, 11 Dec 2007 00:08:34 +0200, Kamen TOMOV <·····@cybuild.com> wrote:
> What about common-lisp-controller - do you use it?
Nope.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Kamen TOMOV <·····@cybuild.com> writes:
> On Mon, Dec 10 2007, Edi Weitz wrote:
>> You either trust that some external entity (the Debian guys, the
>> Lisp developers who cater to ASDF-INSTALL, the CPAN guys, whoever)
>> will make sure all the libraries you need are automatically
>> installed (in the right version) or you don't. I've come to a point
>> where I have /one/ directory which contains all of the Lisp
>> libraries I use (including my own) and I update them when needed,
>> either from a release tarball or from some version control
>> mechanism.
>
> Thank you - that's a good advise.
>
>> I don't use ASDF-INSTALL, and on my Debian boxes I don't use the
>> Debian package system for Lisp libraries.
>>
>> As for packages that ship with other packages - I think that's a bad
>> idea anyway and I would complain to the maintainers.
>
> What about common-lisp-controller - do you use it?
In contrast to Edi, my experiences with the Debian (and Ubuntu) package
system are relatively good (you should use the testing release however).
Therefore, my approach is to use the Debian packages as much as possible
and only to download libraries separately if they are not (yet) available
or a patch is needed which is not available. I guess that Edi has a
different view because he uses several types of CL implementations on
different architectures (including Windows) whereas I use almost
exclusively Debian/Ubuntu for my work.
Nicolas
On Tue, Dec 11 2007, Nicolas Neuss wrote:
> In contrast to Edi, my experiences with the Debian (and Ubuntu)
> package system are relatively good (you should use the testing
> release however). Therefore, my approach is to use the Debian
> packages as much as possible and only to download libraries
> separately if they are not (yet) available or a patch is needed
> which is not available. I guess that Edi has a different view
> because he uses several types of CL implementations on different
> architectures (including Windows) whereas I use almost exclusively
> Debian/Ubuntu for my work.
I've been doing the same thing with Gentoo and although Gentoo has an
excelent support for CL modules in result I have the situation I
described. Now I have also an Ubuntu machine to support and although
its a similar case, it is not 100% the same. On top of that I also
have Windows and the possibility to deploy on a server that hell knows
what OS it runs. In a nutshell - the so called OS package management
is currently such a bad idea if used for CL modules.
--
Kamen
Kamen TOMOV <·····@cybuild.com> writes:
> I've been doing the same thing with Gentoo and although Gentoo has an
> excelent support for CL modules in result I have the situation I
> described. Now I have also an Ubuntu machine to support and although its
> a similar case, it is not 100% the same. On top of that I also have
> Windows and the possibility to deploy on a server that hell knows what OS
> it runs. In a nutshell - the so called OS package management is currently
> such a bad idea if used for CL modules.
OK, then Edi's remark are more relevant for you, of course. With these
requirements I probably would also keep my own library versions.
Nicolas
Kamen TOMOV <·····@cybuild.com> wrote on Mon, 10 Dec 2007:
> Currently on my machines live the following types of packages:
> 1. asdf-install-ed packages;
> 2. CVS (and similar) packages;
> 3. Packages installed using the OS package management;
> 4. Packages that I developed;
> 5. Packages that got shipped with other packages;
> It's a hell of a job to deal with this without prior planning, especially
> if one manages more than one machines.
Are you only talking about Common Lisp? Or are you concerned with overall
system maintenance?
At some point, you have to do system administration for an entire machine,
and all the interrelated dependencies for software. But you can't expect
a solution to that inside of a single programming language. Debian linux,
for example, manages software via "apt". You could use that as well, if
you're willing to work on linux.
If you want CL only, but cross-platform, you could use ASDF. Of course, if
you want to use some CL code that isn't organized via ASDF, you'd have to add
a system definition file yourself manually. But this is true no matter what
software management system you use, if the code's authors didn't use it also.
But if you somehow imagine something that is both cross-platform and also
cross-(programming)-language, I don't think that's a feasible request.
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ ···@geddis.org
When the only tool you own is a hammer, every problem begins to resemble a
nail. -- Abraham Maslow
On Tue, Dec 11 2007, Don Geddis wrote:
> Kamen TOMOV <·····@cybuild.com> wrote on Mon, 10 Dec 2007:
>> Currently on my machines live the following types of packages:
>> 1. asdf-install-ed packages;
>> 2. CVS (and similar) packages;
>> 3. Packages installed using the OS package management;
>> 4. Packages that I developed;
>> 5. Packages that got shipped with other packages;
>> It's a hell of a job to deal with this without prior planning,
>> especially if one manages more than one machines.
>
> Are you only talking about Common Lisp? Or are you concerned with
> overall system maintenance?
Only about CL of course.
--
Kamen
On Mon, 10 Dec 2007 19:38:17 +0200
Kamen TOMOV <·····@cybuild.com> 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 <·······@japhy.fnord.org> [ 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 ) -><-
Den Thu, 13 Dec 2007 18:13:30 +0100 skrev Maciek Pasternacki:
>> 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.
http://www.packagekit.org/ is designed to solve that (and some other)
problems. It's still WIP, but already works, with good support for
several package managers. Don't let the GUI bits put you off, it has
programmatic interfaces via D-BUS to do everything.
Cheers,
Maciej
On Thu, 13 Dec 2007 18:02:25 +0000 (UTC)
Maciej Katafiasz <········@gmail.com> wrote:
> >> 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.
>
> http://www.packagekit.org/ is designed to solve that (and some other)
> problems. It's still WIP, but already works, with good support for
> several package managers. Don't let the GUI bits put you off, it has
> programmatic interfaces via D-BUS to do everything.
It solves only first of issues I mentioned, and only partially (package names
also differ between distributions). And distribution I use most, PLD Linux,
is not supported.
I still think that touching distribution's packages in Librarian in any way
will make more problems than it would solve. And, I don't need it ;) but
prove me wrong, send me the code, and I'll be happy to include it. At the
moment, updating managed repos and stable APIs have greater priority.
Actually, this may be way to handle non-Lisp dependencies (libraries that
used by FFI bindings, detachtty, etc)... but I'm still not sure if I want
to put this into Librarian itself.
--
__ Maciek Pasternacki <·······@japhy.fnord.org> [ http://japhy.fnord.org/ ]
`| _ |_\ / { Any road followed to its end leads precisely nowhere. Climb
,|{-}|}| }\/ the mountain just a little to test it's a mountain. From the top
\/ |____/ of the mountain you cannot see the mountain. } ( F.Herbert ) -><-
On Thu, Dec 13 2007, Maciek Pasternacki wrote:
> On Mon, 10 Dec 2007 19:38:17 +0200
> Kamen TOMOV <·····@cybuild.com> 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.
>
Of course.
>> 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).
>
IMO the version control systems should be the most important source of
software for cl-librarian. I'd also give higher priority to git.
Software for abstracting the interface of a version control systems -
yummy!
>> 3. Packages installed using the OS package management;
>
> No support.
That's fine. There'd be no modules (SMH suggested that we do not use
the word packages and he's right) that couldn't be found on a version
control system. The only issue here is dependencies. OS maintainers
who deal with dependancies of CL modules usually make sure that a
release is a bunch of working software and the question is how
cl-librarian could benefit from all that work. Perhaps when you get to
a point when cl-librarian is well documented and likable, the OS
maintainers would support only the dependancies of cl-librarian only
;) as it would take care of everything else.
> 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.
I checked the web page and it didn't get very clear to me, so could
you please elaborate on that? Does it mean one specifies a set of
modules and cl-librarian takes care to find, obtain, install, update
(when commanded) them? So what's the idea of multiple shelfs?
Generally, when installing software, a management system should
download the latest and greatest software by default. However, in
certain cases (when the automatic unit-tests fail or when commanded by
the user) the system should communicate the problem with the user so
that s/he can take action like asking it to install an explicitly
chosen older version.
I'd suggest that you investigate the Gentoo package management system
that is called Portage. It has some very powerful ideas. That's its
handbook:
http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&chap=1#doc_chap2
> If you want to freeze some package, use tarball (TODO: specify
> branches/tags of repository).
>
Using branches/tags seems much more important than using tarballs to
me.
> 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.
>
Splendid!
>> 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 meant something different, e.g. when a package from the OS
management tool takes precedence over a package from asdf-install or
vice-versa.
>> 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).
Stelian Ionescu, the guy who currently maintains the Gentoo
distribution told me that they've decided to use asdf-binary-locations
instead of common-lisp-controller as the latter is not actively
supported. I plan to investigate the issues with the FASL files today.
A side question: why cl-librarian is targeted to power users? Does it
mean it would be hard to use by general users?
--
Kamen
On Fri, 14 Dec 2007 12:47:41 +0200
Kamen T <·····@cybuild.com> wrote:
> >> 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).
> >
> IMO the version control systems should be the most important source of
> software for cl-librarian. I'd also give higher priority to git.
They are indeed. Tarballs need to be supported anyway, since many important
libraries (e.g. Edi Weitz's software) don't publish source in version control
systems, but main reason was to automate updating libraries from VC.
Git is definitely on TODO and I will note it as higher priority.
> >> 3. Packages installed using the OS package management;
> >
> > No support.
>
> That's fine. There'd be no modules (SMH suggested that we do not use
> the word packages and he's right) that couldn't be found on a version
> control system. The only issue here is dependencies. OS maintainers
> who deal with dependancies of CL modules usually make sure that a
> release is a bunch of working software and the question is how
> cl-librarian could benefit from all that work. Perhaps when you get to
> a point when cl-librarian is well documented and likable, the OS
> maintainers would support only the dependancies of cl-librarian only
> ;) as it would take care of everything else.
I don't think so. Librarian is meant to create complete self-contained
deployment description rather than compose with OS.
> >> 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.
>
> I checked the web page and it didn't get very clear to me, so could
> you please elaborate on that? Does it mean one specifies a set of
> modules and cl-librarian takes care to find, obtain, install, update
> (when commanded) them? So what's the idea of multiple shelfs?
Idea of multiple shelfs comes from some of my usage patterns: single instance
of Librarian manages multiple shelves used by multiple projects. And, shelf
can include other shelves -- that means that in Web project using Hunchentoot
and Postmodern, I don't have to copy-paste all Hunchentoot and Postmodern
dependencies, I just include shelves HUNCHENTOOT and POSTMODERN (both are
included as example shelves in Librarian's repo):
(defshelf project (postmodern hunchentoot)
((cl-json darcs-repo :source "http://common-lisp.net/project/cl-json/darcs/cl-json")
(parenscript darcs-repo :source "http://common-lisp.net/project/ucw/repos/parenscript")))
Nevertheless, the `project' shelf directory contains *all* libraries and
modules, so that if I update nearby shelf to test latest-and-greatest
experimental Postmodern patches, I don't risk destabilizing the Project.
Only when I operate on Project itself, its contents are touched.
I just thought of other use of multiple shelves: when updating a shelf, I can
ask Librarian to update only subset of it: single specific repo (if I
actually want to ask for trouble), or only contents of included shelf (so
that I can, e.g., update Hunchentoot without updating Postmodern).
I will probably work on Librarian's documentation during Christmas. In
meantime, feel free to ask (here on the group, or to private mail, my name at
my surname dot net will get fastest reaction).
> Generally, when installing software, a management system should
> download the latest and greatest software by default. However, in
> certain cases (when the automatic unit-tests fail or when commanded by
> the user) the system should communicate the problem with the user so
> that s/he can take action like asking it to install an explicitly
> chosen older version.
I didn't think of tests yet. Testing downloaded modules can be good, as far
as they support a single protocol (ASDF defines TEST-OP, this should be
fine). Definitely for the TODO.
Hmm... if I could think of easy and cheap way of reversible upgrades, that
would be great for checking out new releases. As for now, I don't include
final application code in the shelf (I just use the shelf before loading
application's .asd file), but if I put application inside shelf and only
started it up from outside, this would be great way to deploy upgrades.
> I'd suggest that you investigate the Gentoo package management system
> that is called Portage. It has some very powerful ideas. That's its
> handbook:
>
> http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&chap=1#doc_chap2
I'll take look at it when I have a moment. Probably not before Christmas,
though.
> > If you want to freeze some package, use tarball (TODO: specify
> > branches/tags of repository).
>
> Using branches/tags seems much more important than using tarballs to
> me.
For time being: for two out of three supported version control systems (SVN
and darcs), branches are included in repository path, so they are supported.
As for tags, you can just make a tarball of any given tag and point Librarian
to a tarball in local filesystem. Yes, it is a kludge, and VC tags and CVS
branches will be supported -- I just said how you can work around it until
then.
> > 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.
>
> Splendid!
Deployment skeleton is now in skel/ directory of Librarian repository.
> >> 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 meant something different, e.g. when a package from the OS
> management tool takes precedence over a package from asdf-install or
> vice-versa.
Paths of shelved ASDF systems are PUSHed at beginning of
ASDF:*CENTRAL-REGISTRY*, so they should have priority over system-provided
ones. However, packages supplied by OS and not downloaded by Librarian are
visible. We try not to interact with OS-provided libraries, but if user uses
apt-get, ASDF-Install, and Librarian at once with the same libraries, he is
asking for trouble ;)
Do you think Librarian should detect if library it is about to download (or
enable already downloaded one) is already available in the system? I
personally try to avoid using any OS-supplied libraries, simply because they
too often become a pain when something goes wrong, so I don't have much
experience in resolving such conflicts.
> >> 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).
>
> Stelian Ionescu, the guy who currently maintains the Gentoo
> distribution told me that they've decided to use asdf-binary-locations
> instead of common-lisp-controller as the latter is not actively
> supported. I plan to investigate the issues with the FASL files today.
Oh, ASDF-binary-locations can be great addition to Librarian. I don't like
to stuff it with dependencies, but this one may be worth it: don't put
compiled FASL files into repositories, only in bin/ dir that can be just
simply removed, and which can have subdirectories for different Lisp
implementations... yes, I think I like it :)
> A side question: why cl-librarian is targeted to power users? Does it
> mean it would be hard to use by general users?
At this moment, certainly, it is work in progress. Finally there may be easy
way to use it, but I didn't mean `single-click ready Lisp installation for
newbies', but `simplify deployment for Lisp developers that already know
their way around ASDF', and they are my secondary target (my primary target
is specifically myself). If it becomes easy to use by general users, or even
newbies, I won't oppose, but only if it won't require making it less useful
for power users.
Regards,
Maciek
--
__ Maciek 'japhy' Pasternacki -><- http://www.pasternacki.net/
`| _ |_\ / { 2.718281828459045235360287471352662497757247093699959574966967
,|{-}|}| }\/ 62772407663035354759457138217852516642742746639193200305992181741
\/ |____/ 359662904357290033429526059563073813232862794349076... ( e ) -><-
Just wondering: I sent you an email with a small bugfix, but I never got
an answer. Not even about my patch being crap or something. Did you get
the mail?
--
Albert Krewinkel
On Mon, 17 Dec 2007 11:22:24 +0100
Albert Krewinkel <·········@gmx.net> wrote:
> Just wondering: I sent you an email with a small bugfix, but I never got
> an answer. Not even about my patch being crap or something. Did you get
> the mail?
It got stuck in antispam queue for public address. The address which I use
for Usenet has a very strong firewall which tends to have false positives --
I use it for many years, it is publically available, so it can gather as
much as a hundred spam messages per hour. I will add a note about primary,
less filtered address (which is my name at my surname dot net) to my
signature and website contact page.
Sorry for problems, I am currently in process of transition from old
japhy.fnord.org domain to pasternacki.net, which is currently primary one.
I try to browse antispam queue for false positives regularly, but as you see I
can miss a mail or two occasionally. Sorry once more, and I go away now to
your private mail :)
Regards,
--
__ Maciek 'japhy' Pasternacki -><- http://www.pasternacki.net/
`| _ |_\ / { Mówi się kocham, bo chce się odzewu -- i śmierć się odpowiada,
,|{-}|}| }\/ choć inaczej trzeba; dotyka się łagodnie, każdy dotyk ma echo --
\/ |____/ i oczy się odwraca z delikatnością zwierząt } (M.Świetlicki) -><-
On Mon, Dec 17 2007, Maciek Pasternacki wrote:
> On Fri, 14 Dec 2007 12:47:41 +0200
> Kamen T <·····@cybuild.com> wrote:
>
>> >> 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).
>> >
>> IMO the version control systems should be the most important source
>> of software for cl-librarian. I'd also give higher priority to git.
>
> They are indeed. Tarballs need to be supported anyway, since many
> important libraries (e.g. Edi Weitz's software) don't publish source
> in version control systems, but main reason was to automate updating
> libraries from VC.
loliveira supports darcs repos of Edi's software. They can be found
here: http://common-lisp.net/~loliveira/ediware/
> Git is definitely on TODO and I will note it as higher priority.
>
>> >> 3. Packages installed using the OS package management;
>> >
>> > No support.
>>
>> That's fine. There'd be no modules (SMH suggested that we do not
>> use the word packages and he's right) that couldn't be found on a
>> version control system. The only issue here is dependencies. OS
>> maintainers who deal with dependancies of CL modules usually make
>> sure that a release is a bunch of working software and the question
>> is how cl-librarian could benefit from all that work. Perhaps when
>> you get to a point when cl-librarian is well documented and
>> likable, the OS maintainers would support only the dependancies of
>> cl-librarian only ;) as it would take care of everything else.
>
> I don't think so. Librarian is meant to create complete
> self-contained deployment description rather than compose with OS.
>
It seems you misunderstood me. I do not find it a good idea OS
maintainers to support CL libs directly. I'd rather have an
architecture where that work is delegated to a module management
system (potentially Librarian).
>> >> 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.
>>
>> I checked the web page and it didn't get very clear to me, so could
>> you please elaborate on that? Does it mean one specifies a set of
>> modules and cl-librarian takes care to find, obtain, install,
>> update (when commanded) them? So what's the idea of multiple
>> shelfs?
>
> Idea of multiple shelfs comes from some of my usage patterns: single
> instance of Librarian manages multiple shelves used by multiple
> projects. And, shelf can include other shelves -- that means that
> in Web project using Hunchentoot and Postmodern, I don't have to
> copy-paste all Hunchentoot and Postmodern dependencies, I just
> include shelves HUNCHENTOOT and POSTMODERN (both are included as
> example shelves in Librarian's repo):
>
> (defshelf project (postmodern hunchentoot)
> ((cl-json darcs-repo :source "http://common-lisp.net/project/cl-json/darcs/cl-json")
> (parenscript darcs-repo :source "http://common-lisp.net/project/ucw/repos/parenscript")))
>
Hmm, I still don't understand. I have simple questions. Let me summarize:
project: name of the shelf
postmodern, hunchentoot: dependencies
cl-json, parenscript: what are they in your terminology?
What's more cl-json depends on Parenscript and I don't see how is that expressed?
> Nevertheless, the `project' shelf directory contains *all* libraries
> and modules, so that if I update nearby shelf to test
> latest-and-greatest experimental Postmodern patches, I don't risk
> destabilizing the Project. Only when I operate on Project itself,
> its contents are touched.
>
> I just thought of other use of multiple shelves: when updating a
> shelf, I can ask Librarian to update only subset of it: single
> specific repo (if I actually want to ask for trouble), or only
> contents of included shelf (so that I can, e.g., update Hunchentoot
> without updating Postmodern).
>
> I will probably work on Librarian's documentation during Christmas.
> In meantime, feel free to ask (here on the group, or to private
> mail, my name at my surname dot net will get fastest reaction).
>
Thanks, I can wait for the documentation.
>> Generally, when installing software, a management system should
>> download the latest and greatest software by default. However, in
>> certain cases (when the automatic unit-tests fail or when commanded
>> by the user) the system should communicate the problem with the
>> user so that s/he can take action like asking it to install an
>> explicitly chosen older version.
>
> I didn't think of tests yet. Testing downloaded modules can be
> good, as far as they support a single protocol (ASDF defines
> TEST-OP, this should be fine). Definitely for the TODO.
>
> Hmm... if I could think of easy and cheap way of reversible
> upgrades, that would be great for checking out new releases. As for
> now, I don't include final application code in the shelf (I just use
> the shelf before loading application's .asd file), but if I put
> application inside shelf and only started it up from outside, this
> would be great way to deploy upgrades.
>
Gentoo's Portage supports "multiple slots" for that purpose. So you
can have two packages of the same software - for example Emacs-21 and
Emacs-22. By default Portage installs the latest version of a
package. However, if the user wishes to, he can install an older (or
newer unstable) version of the package in a different "slot".
>> I'd suggest that you investigate the Gentoo package management system
>> that is called Portage. It has some very powerful ideas. That's its
>> handbook:
>>
>> http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&chap=1#doc_chap2
>
> I'll take look at it when I have a moment. Probably not before
> Christmas, though.
>
>> > If you want to freeze some package, use tarball (TODO: specify
>> > branches/tags of repository).
>>
>> Using branches/tags seems much more important than using tarballs
>> to me.
>
> For time being: for two out of three supported version control
> systems (SVN and darcs), branches are included in repository path,
> so they are supported. As for tags, you can just make a tarball of
> any given tag and point Librarian to a tarball in local filesystem.
> Yes, it is a kludge, and VC tags and CVS branches will be supported
> -- I just said how you can work around it until then.
>
>> > 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.
>>
>> Splendid!
>
> Deployment skeleton is now in skel/ directory of Librarian
> repository.
>
>> >> 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 meant something different, e.g. when a package from the OS
>> management tool takes precedence over a package from asdf-install
>> or vice-versa.
>
> Paths of shelved ASDF systems are PUSHed at beginning of
> ASDF:*CENTRAL-REGISTRY*, so they should have priority over
> system-provided ones. However, packages supplied by OS and not
> downloaded by Librarian are visible. We try not to interact with
> OS-provided libraries, but if user uses apt-get, ASDF-Install, and
> Librarian at once with the same libraries, he is asking for trouble
> ;)
>
What about the use case multiple applications to run in the same Lisp
process? Although it is a remote possibility I still find it
possible. How will an application find the way to its libraries in the
*central-registry*?
> Do you think Librarian should detect if library it is about to
> download (or enable already downloaded one) is already available in
> the system? I personally try to avoid using any OS-supplied
> libraries, simply because they too often become a pain when
> something goes wrong, so I don't have much experience in resolving
> such conflicts.
>
I'd rather not allow anything (OS or else) mess with my
*central-registry* except my library management system. I'd reset the
registry and completely ignore the OS-supplied libraries.
>> >> 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).
>>
>> Stelian Ionescu, the guy who currently maintains the Gentoo
>> distribution told me that they've decided to use asdf-binary-locations
>> instead of common-lisp-controller as the latter is not actively
>> supported. I plan to investigate the issues with the FASL files today.
>
> Oh, ASDF-binary-locations can be great addition to Librarian. I don't like
> to stuff it with dependencies, but this one may be worth it: don't put
> compiled FASL files into repositories, only in bin/ dir that can be just
> simply removed, and which can have subdirectories for different Lisp
> implementations... yes, I think I like it :)
>
>> A side question: why cl-librarian is targeted to power users? Does it
>> mean it would be hard to use by general users?
>
> At this moment, certainly, it is work in progress. Finally there may be easy
> way to use it, but I didn't mean `single-click ready Lisp installation for
> newbies', but `simplify deployment for Lisp developers that already know
> their way around ASDF', and they are my secondary target (my primary target
> is specifically myself). If it becomes easy to use by general users, or even
> newbies, I won't oppose, but only if it won't require making it less useful
> for power users.
--
Kamen
On Mon, 17 Dec 2007 13:16:29 +0200
Kamen T <·····@cybuild.com> wrote:
> >> >> 3. Packages installed using the OS package management;
> >> >
> >> > No support.
> >>
> >> That's fine. There'd be no modules (SMH suggested that we do not
> >> use the word packages and he's right) that couldn't be found on a
> >> version control system. The only issue here is dependencies. OS
> >> maintainers who deal with dependancies of CL modules usually make
> >> sure that a release is a bunch of working software and the question
> >> is how cl-librarian could benefit from all that work. Perhaps when
> >> you get to a point when cl-librarian is well documented and
> >> likable, the OS maintainers would support only the dependancies of
> >> cl-librarian only ;) as it would take care of everything else.
> >
> > I don't think so. Librarian is meant to create complete
> > self-contained deployment description rather than compose with OS.
>
> It seems you misunderstood me. I do not find it a good idea OS
> maintainers to support CL libs directly. I'd rather have an
> architecture where that work is delegated to a module management
> system (potentially Librarian).
I see now. A bit like distros not packaging Ruby libraries, just the gems
system? It would be great :) but that's rather far future.
> >> > Central concept in Librarian is a `library shelf', which is a set
> >> > of libraries. Such shelf should be updated at once.
> >>
> >> I checked the web page and it didn't get very clear to me, so could
> >> you please elaborate on that? Does it mean one specifies a set of
> >> modules and cl-librarian takes care to find, obtain, install,
> >> update (when commanded) them? So what's the idea of multiple
> >> shelfs?
> >
> > Idea of multiple shelfs comes from some of my usage patterns: single
> > instance of Librarian manages multiple shelves used by multiple
> > projects. And, shelf can include other shelves -- that means that
> > in Web project using Hunchentoot and Postmodern, I don't have to
> > copy-paste all Hunchentoot and Postmodern dependencies, I just
> > include shelves HUNCHENTOOT and POSTMODERN (both are included as
> > example shelves in Librarian's repo):
> >
> > (defshelf project (postmodern hunchentoot)
> > ((cl-json darcs-repo :source
> > "http://common-lisp.net/project/cl-json/darcs/cl-json") (parenscript
> > darcs-repo :source
> > "http://common-lisp.net/project/ucw/repos/parenscript")))
> >
> Hmm, I still don't understand. I have simple questions. Let me summarize:
>
> project: name of the shelf
Yes.
> postmodern, hunchentoot: dependencies
No. Librarian doesn't do dependencies: that's what ASDF does. These are
included shelves (defined elsewhere -- in this case, included with
Librarian, in shelves/ subdirectory).
> cl-json, parenscript: what are they in your terminology?
Single repositories, included in the shelf (shelf's `immediate contents').
> What's more cl-json depends on Parenscript and I don't see how is that
> expressed?
There is no notion of dependencies in Librarian. Library shelf is just a
bunch of libraries. ASDF does dependencies, Librarian does downloading and
managing.
I have on TODO to make Librarian do test loading of shelf's packages after
downloading/updating, catch ASDF's missing system condition, and possibly
implicitly add repositories to shelf (by default, from ASDF-Install), sort of
like ASDF-Install does it. It is a bit down the TODO list, and I don't want
Librarian to mess with dependencies more than this.
> >> > 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 meant something different, e.g. when a package from the OS
> >> management tool takes precedence over a package from asdf-install
> >> or vice-versa.
> >
> > Paths of shelved ASDF systems are PUSHed at beginning of
> > ASDF:*CENTRAL-REGISTRY*, so they should have priority over
> > system-provided ones. However, packages supplied by OS and not
> > downloaded by Librarian are visible. We try not to interact with
> > OS-provided libraries, but if user uses apt-get, ASDF-Install, and
> > Librarian at once with the same libraries, he is asking for trouble
> > ;)
> >
> What about the use case multiple applications to run in the same Lisp
> process? Although it is a remote possibility I still find it
> possible. How will an application find the way to its libraries in the
> *central-registry*?
I can't see any problem that Librarian would create or need to solve. If two
applications in single image need different versions of the same library,
user has a problem. It won't be automatically manageable anyway. If there
is no such case, simply make sure all libraries are visible -- you can use
many shelves at once.
> > Do you think Librarian should detect if library it is about to
> > download (or enable already downloaded one) is already available in
> > the system? I personally try to avoid using any OS-supplied
> > libraries, simply because they too often become a pain when
> > something goes wrong, so I don't have much experience in resolving
> > such conflicts.
>
> I'd rather not allow anything (OS or else) mess with my
> *central-registry* except my library management system. I'd reset the
> registry and completely ignore the OS-supplied libraries.
That's how Librarian is supposed to work. It will be the best environment for
it.
Regards,
Maciek
--
__ Maciek 'japhy' Pasternacki -><- http://www.pasternacki.net/
`| _ |_\ / { ...don't just call me pessimist, try and read between the
,|{-}|}| }\/ lines, I can't imagine why you wouldn't welcome any change my
\/ |____/ friend, I wanna see it all come down... } ( M. J. Keenan ) -><-