[alexandria-devel] Maintenance
Hi folks! I had this idea to ask implementators how they'd feel inclined about including Alexandria as part of their implementations as most nowadays do with ASDF. For that to work, of course, there has to be Alexandria releases, and once something's officially released, backwards-compatiblity would have to be preserved. (I think there should be an official ALEXANDRIA package containing the stable API, and some -TESTBED or -BETA package with stuff being in flux, but for people to try out who are so inclined. Together with some ALEXANDRIA-VERSION<= stuff for conditionalization.) I'd offer to step up, polish the existing code base, write tests where needed, write documentation, do releases, and try to push the things down the implementations. I'd hope that the quality of my existing libraries speak for how severe I take all these steps to produce well-rounded releases. Nowadays, it's my impression that the only somewhat active people are Nikodemus and Attila, where Nikodemus seems to hold the power of ultimate decision making. There are probably more who feel strongly about Alexandria so I wanted to ask you first, because it'd mean a shift of responsibility and power. What do you think? -T.
On 3/2/10, Tobias C. Rittweiler <tcr@freebits.de> wrote:
Hi folks!
I had this idea to ask implementators how they'd feel inclined about including Alexandria as part of their implementations as most nowadays do with ASDF.
Some thoughts from a relative beginner :) I have settled upon Alexandria as my default utilities library, so I'm a happy user. To begin with, I consider myself relatively naive about module systems. However, I think the current arrangement is (while non-ideal) almost acceptable. Why don't we wait for an effective module and "installer" system (I have faith that the day will come)? In the meantime, asdf-install, cl-build, the "libraries" projects, or tarballs (ok...maybe not?), among many other ways, has been sufficient for me. I often reflexively avoid bundled libraries. In my experience, the problem with implementation bundled libraries is that they are often not complete enough -- older library versions, no version control, problems with stale fasls or confused versions when I upgrade manually, so there's no obvious way to upgrade or to hack on the bundled libraries. This may be made worse if you run multiple implementations - they will have separate (possibly incompatible) copies of libraries, managed in different ways. Compatibility issues are not common, but not so rare either. So every time there's a problem, my preference (though I don't quite get there) has been to use only one "main branch" of each library on my whole pc, shared by all Lisp implementations & implementation versions. I do use (have used) boxsets grudgingly :(
For that to work, of course, there has to be Alexandria releases, and once something's officially released, backwards-compatiblity would have to be preserved. (I think there should be an official ALEXANDRIA package containing the stable API, and some -TESTBED or -BETA package with stuff being in flux, but for people to try out who are so inclined. Together with some ALEXANDRIA-VERSION<= stuff for conditionalization.)
I'd offer to step up, polish the existing code base, write tests where needed, write documentation, do releases, and try to push the things down the implementations. I'd hope that the quality of my existing libraries speak for how severe I take all these steps to produce well-rounded releases.
Nowadays, it's my impression that the only somewhat active people are Nikodemus and Attila, where Nikodemus seems to hold the power of ultimate decision making.
There are probably more who feel strongly about Alexandria so I wanted to ask you first, because it'd mean a shift of responsibility and power.
What do you think?
As a user, I welcome any extra love for Alexandria :) Yong.
i'm not happy with the current situation (no "one-click" installation of lisp libraries), but i don't think bundling alexandria, or other libraries would help much on the situation. a portable installer that can automatically check out and update source repositories would help a lot though! but that's a different story... my 0.02, -- attila ps: which reminds me that i should get back playing with XCVB at least...
On Mar 3, 2010, at 09:02 , Attila Lendvai wrote:
a portable installer that can automatically check out and update source repositories would help a lot though! but that's a different story...
What does "portable" mean? Between Lisps or between OSes? Also, what if you install lisp software which depends on non-lisp tools provided by the OS/distribution, say tar or gnupg? Ideally, you want to be able to express such dependencies as well. This is where, e.g., the python and ruby library installers fail... Two options present themselves: * Leave software installation to the OS mechanism entirely, i.e., also the Lisp stuff. That's basically something like CLC. * Integrate the various distribution mechanisms (apt, rpm, yast, macports, fink, ...) into a lisp solution. This seems like a lot of tedious work, and it's not even clear what to do without administrator rights. -- Cheers, Michael
a portable installer that can automatically check out and update source repositories would help a lot though! but that's a different story...
What does "portable" mean? Between Lisps or between OSes?
portable between lisps. i can very well live without integration with the OS package manager... that 1% of the projects that need external tools can print a copy&paste-able apt-get line which is good enough until we'll have a better OS replacing linux (i.e. indefinitely long). -- attila
participants (4)
-
Attila Lendvai -
Michael Weber -
szergling -
Tobias C. Rittweiler