Hi guys, (Skip to "to sum up" if you want the very short version of the following blob.) On Sat, Oct 17, 2009 at 11:39:35AM +0200, Marc Balmer wrote: > I am suggesting to add the language Lua to the NetBSD base system as a [...] I won't add any fuel on that discussion, but I'd like to add a few points that I haven't really seen mentioned in the rest of the thread. FWIW, Core had been contemplating the idea of a "modern" scripting language for inclusion in base. It's not my place to give any details of what was discussed, but I did play around with Lua and later Python. My opinion is that the very first requisite for such a piece of software to be included in base is that it has to be easy to integrate. This is the case with Lua; integrating it into the build was a matter of a few hours of work, and that includes a couple extensions such as lcurses and a regex module. Then I went on and tried with Python. I didn't try for very long; not only the build system is close to a nightmare, but it now has some MD components that I am not sure we have yet support for on all archs. Not that it would be a lot of work, but it adds to the complexity and thus make it even harder to maintain. This is very important: doing the reachover build once is one thing, but what matters is when you have to update. In that respect, Lua is a clear winner. There is, however, a second thing that I see as an absolute requisite for inclusion in base. For many kinds of software, interaction between base and pkgsrc is not a problem. But when a piece has a notion of modules, it becomes a hairy problem. It is actually two folds: the first issue is how to install additional modules from pkgsrc. I think Marc argued that one that that could be done is completely shielding the base language (Lua in his case, but really it applies to anything) from the rest of the world, including pkgsrc). This appears to me as a very short sighted opinion, especially coming from someone who claims a scripting language should be included in base for the sole reason of generic usefulness. Well, if something can be used for "stuff", someone will want to use it for "stuff and more". Therefore people will want to install additional modules from pkgsrc. The thing is, pkgsrc is very independent from its base system, NetBSD for the sake of that discussion, which means paths can't be hard-coded, not in base nor in pkgsrc to help the scripting language find its modules. That leaves the options of either pkgsrc installing files outside of LOCALBASE, or devising a way to patch the base scripting language to be configured an extra search path. The second issue regarding interaction with pkgsrc is what is supposed to happen when the base system is upgraded. That can lead to very harmful ABI issues, especially if the scripting language gets wide use, and solving them is far from easy. One can always start properly versioning modules, so that scripts could fail similarly to ELF binaries that can't find their libraries. But it also means that one kryteryon to choose a scripting language would be to have a module API (and ABI, for many languages, including Lua, can see their modules compiled one way or another) as stable as possible. Finally, and this is in my opinion the only real thing worth debating, there is the question of whether inclusion of a scripting language should precede its use in base, or whether it should be the other way around. I tend to be of the opinion that many things could be done with a scripting language, so that if it exists, it will find its place. But I know that many people feel that it shouldn't be included before someone has something else worth inclusion that uses it. I think this discussion can serve as a midway, giving a short list of languages to consider for anyone to, say, write a script-based sysinst or something. So, to sum up, my opinion is that the three following things are requisites to consider inclusion of any scripting language: 1 easy integration, to make future maintainance possible 2 full interaction with pkgsrc 3 immediate use case. how immediate is up for debate, though. Now, there can be a lot of arguing over the features of the scripting language. For the language itself, I honestly think it is completely irrelevant. The amount of available extensions, however, is more relevant. In that respect, Lua does not do as good as Python, for instance. In the end, there is something I think NetBSD could do, especially given how straightforward it is to integrate Lua into the tree. Why not simply give it a try for NetBSD 6.0, and see what people do with it? I don't see how -current could instantly be irremediably dependent on Lua, which means removing later won't really hurt anyone if doesn't see any relevant use. If it *does* get immediately dependent on Lua, then it will be a sign that it wasn't a bad idea after all. And if it is somewhere in the middle, seeing use but not being critical, then it can be discussed for the next major version. But I don't think that NetBSD has to take an oath about supporting a scripting language from the very start to the end of time. (If you're insterested, you may find my patches for Lua here: http://vert-toit.net/~cube/lua/ They might still compile with current -current, or might not. I really have no idea.) -- Quentin Garnier - cube%cubidou.net@localhost - cube%NetBSD.org@localhost "See the look on my face from staying too long in one place [...] every time the morning breaks I know I'm closer to falling" KT Tunstall, Saving My Face, Drastic Fantastic, 2007.
Attachment:
pgpXz70dCWtGz.pgp
Description: PGP signature