Lisp packaging and version management..
in [Lisp]
|
From: D Herring on 23 Jan 2010 20:27 Steffen Schulz wrote: .... > In the end, I have to resolve any dependencies by hand, visit the individual > websites and keep track of their latest tarball, svn, cvs, darcs or git > repository. > > Debian also ships quite a bit of cl packages, but of course they don't have all > of them. I would end up with a mixture of current and older packages, which is > at least as complicated as finding the most recent version of all of them. > > Did I miss something? Is there a hidden package server that you only tell your > friends about? Do you all do the package management on your own? This is a common issue with all languages; but CL's diverse nature does aggravate the problem. Here's my attempt at making life easier: http://libcl.com - Daniel
From: Nicolas Neuss on 24 Jan 2010 05:05 pjb(a)informatimago.com (Pascal J. Bourguignon) writes: > You're right, the situation is a mess. > > There's asdf-install/cliki.net and asdf, but they have the drawbacks > you noted (and some more). > > There are newer and different attempts, such as xcvb, cl-build, libcl, > etc, but AFAIK, nothing is comprehensive and definitive. > > You might want to have a look at libcl, it's the approach I take for > the dependencies of my own lisp application. > > But really, we were waiting for somebody like you, motivated to solve > this mess with a great definite solution. Serriously. I have the impression that for this really important issue it would really be time that the maintainers of the different implementations, system definition facilities and packaging systems should try to agree on a common solution working under most CL implementations. The best possible outcome would probably be a substandards document on KMP's <http://substandards.org/> accompanied with a reasonable CCLAN-like server. Who could participate in a committee? Here a proposal: Whoever is interested out of the following groups: 1. Implementors (Franz, Lispworks, SBCL, ECL, ...) 2. System definition facility maintainers (Dan Barlow, Fare Rideau, Marco Antoniotti, ...) 3. Package system maintainers (Kevin Rosenberg, Dan Herring, Dan Barlow, ...) Work involved would probably not be terribly large for the members of the committee, but would be quite large for a single individual who would act as chairman. Therefore it would be necessary to compensate that person financially for this effort which might be done by collecting money from all of us here interested in such an effort. I personally think that I would pay around 200 EUR, probably even more, to someone having the right qualification for doing such a job. The following questions remain: 1. Who else would like to contribute financially to something like that? Would there be sufficiently many contributions? I would really like to know how much money one could expect here out of a community effort. 2. Is there anyone with high reputation (i.e. who would be agreed on by the committee) who would act as chairman of that committee, who would write the standards document proposal and final document, and possibly also implement a reference implementation (extracting parts out of MK-DEFSYSTEM/ASDF/ASDF-INSTALL/etc, maybe adding some missing parts like versioning)? 3. Further ideas? Opinions? Nicolas
From: Tamas K Papp on 24 Jan 2010 05:35 On Sun, 24 Jan 2010 11:05:00 +0100, Nicolas Neuss wrote: > pjb(a)informatimago.com (Pascal J. Bourguignon) writes: > >> You're right, the situation is a mess. >> >> There's asdf-install/cliki.net and asdf, but they have the drawbacks >> you noted (and some more). >> >> There are newer and different attempts, such as xcvb, cl-build, libcl, >> etc, but AFAIK, nothing is comprehensive and definitive. >> >> You might want to have a look at libcl, it's the approach I take for >> the dependencies of my own lisp application. >> >> But really, we were waiting for somebody like you, motivated to solve >> this mess with a great definite solution. Serriously. > > I have the impression that for this really important issue it would > really be time that the maintainers of the different implementations, > system definition facilities and packaging systems should try to agree > on a common solution working under most CL implementations. > > The best possible outcome would probably be a substandards document on > KMP's <http://substandards.org/> accompanied with a reasonable > CCLAN-like server. > > Who could participate in a committee? Here a proposal: Whoever is > interested out of the following groups: > > 1. Implementors (Franz, Lispworks, SBCL, ECL, ...) > > 2. System definition facility maintainers (Dan Barlow, Fare Rideau, > Marco Antoniotti, ...) > > 3. Package system maintainers (Kevin Rosenberg, Dan Herring, Dan Barlow, > ...) > > Work involved would probably not be terribly large for the members of > the committee, but would be quite large for a single individual who > would act as chairman. Therefore it would be necessary to compensate > that person financially for this effort which might be done by > collecting money from all of us here interested in such an effort. I > personally think that I would pay around 200 EUR, probably even more, to > someone having the right qualification for doing such a job. > > The following questions remain: > > 1. Who else would like to contribute financially to something like that? > Would there be sufficiently many contributions? I would really like > to know how much money one could expect here out of a community > effort. > > 2. Is there anyone with high reputation (i.e. who would be agreed on by > the committee) who would act as chairman of that committee, who would > write the standards document proposal and final document, and > possibly also implement a reference implementation (extracting parts > out of MK-DEFSYSTEM/ASDF/ASDF-INSTALL/etc, maybe adding some missing > parts like versioning)? > > 3. Further ideas? Opinions? I am bit skeptical that this is going to work. The problem is a hard one, and a good solution, if any, will most likely be the result of an evolutionary process. Don't forget that it is not only the development of such a framework that requires effort---the integration of libraries into this system requires a lot of continued dedication. Testing that your library integrates well is not a trivial task. I would settle for a system that would follow dependencies and make sure that the correct version of libraries is on the hard disk. For now, I would leave loading these libraries out of it: ASDF may or may not be replaced in the near future, but maybe we can treat loading as an orthogonal issue. Libraries would include some meta-information, like a Debian package (name, version, short description, and most importantly, dependencies). The system would just make sure that it got everything. Many people use version control systems (eg git, svn, darcs). I don't know about the others, but git can "tag" states of the repository (so you can refer to something with 1.14.9a instead of 59f45c3245e...). Even if people come up with an excellent system, it will not be widespread unless it requires no more than a minimal effort from library authors. Let's face it, many people write free software for their own use, and fixing it for someone else is not always a priority. So any solution would have to be automated, and only require minimal intervention. My 2 cents, Tamas
From: Stelian Ionescu on 24 Jan 2010 06:51 On Sat, 23 Jan 2010 18:13:15 -0500, Raffael Cavallaro wrote: > On 2010-01-23 10:19:57 -0500, Steffen Schulz said: > >> I'm pretty sure I stumbled on one of the reasons today, while trying to >> deploy my work on a different machine: Much worse than the lack of >> certain libraries and tools, I think, is the lack of a well-maintained >> Lisp distribution. > > Don't confuse Common Lisp the language with whatever free implementation > you're using. There are non-free implementations of common lisp that > don't have these sorts of configuration issues - they more or less just > work, which is a big part of what their users are paying for. Such as ? -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib
From: Pascal J. Bourguignon on 24 Jan 2010 08:18 Nicolas Neuss <lastname(a)math.uni-karlsruhe.de> writes: > I have the impression that for this really important issue it would > really be time that the maintainers of the different implementations, > system definition facilities and packaging systems should try to agree > on a common solution working under most CL implementations. Well, I would argue the contrary: it is actually not an important issue. What good is a system definition facility (basically, a "makefile")? In what situation is it really useful? When you program, the advice is to use emacs+slime and program interactively and incrementally: you type a function in the editor file, and C-x C-e to send it to the REPL so the image is updated. Basically, the image is always up to date, and it's incrementally updated. So there's no need here for a makefile equivalent. When you start with a virgin image, then you will want to load all your code: there is no point in finassing with the dependencies, just loading in sequence all the needed files will do. So there's no need here for a makefile equivalent. Finally, when you gather libraries, you need indeed to identify the other libraries they depend on (and it's nice to have here some formal or at least homogenous lists of required libraries), but the problem here is more of finding the right version (when you use library A needing library C version C1, and library B needing library C version C2, you will have fun whatever the kind of system definition facility). The solution is to do that work once and for all (ie. LibCL), but this may again reduce to a list of load expressions. Remember, today, the minimal PC configuration buyable comes with 2.5 GHz dual core processors and with 3 GB of RAM, and a developer computer will be more like a 3 GHz octo-core with 16 GB of RAM. There's no point in trying to load or to compile only the "modified" sources. Just reload everything (I mean, all the existing libraries), or program incrementally. -- __Pascal Bourguignon__ http://www.informatimago.com/
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 4 5 Prev: clisp on emacs+slime Next: How to turn on multithreading capability in CLISP? |