On Wednesday 04 November 2009 11:06:33 Jonas Karlsson wrote: > 2009/11/2 Michael Homer <mich...@gobolinux.org>: > > On Monday 02 November 2009 21:31:35 m...@svn.gobolinux.org wrote: > >> Author: mwh > >> Date: 2009-11-02 00:31:35 -0800 (Mon, 02 Nov 2009) > >> New Revision: 4110 > >> > >> Added: > >> trunk/Scripts/bin/Alien-LuaRocks > >> Log: > >> Add Alien-LuaRocks script, implementing the Aliens interface. > >> > >> This script gives an example of the proposed interface and has been > >> written for clarity in that mor than for any other goal. It is likely > >> that the final interface script will be in Lua and access the LuaRocks > >> database directly, rather than parsing the output of the command-line > >> tool. The same interface is proposed for every wrapper of an alien > >> package manager. > >> > >> This script does not support installing yet, and does not specifically > >> use the /System/Aliens tree nor create the /S/A/LuaRocks hierarchy. > > > > I would like feedback on this series (back to r4108). This is how I > > intend to build the /S/A system in terms of interface, calling out to > > external wrappers for each alien type. The wrappers could be anything > > executable, but this sample one is a basic shell script wrapping the > > command and parsing its output. The interface arguments are at the bottom > > of this script. > > I'd prefer a library interface, like BuildType_foo, with a well > specified API, much like the one you have now, e.g. > LuaRocks_getversion(). It just feels cleaner. > Otoh I can understand that using wrappers and keeping is sh-compatible > is better if we want portability and adaption by others. Yes, this is pretty much the reasoning behind it. It also allows the wrappers to be written in the other languages themselves, and potentially to leverage the existing code for it. The Perl wrapper would be able to "use CPAN;" and access the database directly.
Shell scripts like this are the lowest common denominator when there isn't anything better possible, or to get things up and running. I prefer something out-of-process so that they can potentially be portable to other implementations of the Aliens system, and I prefer using executables with command-line parsing over bash -c 'source ...; LuaRocks_getversion' as well for the above reason. It also avoids having more processes spawned than absolutely necessary. I am going to be describing this all in the miniconf paper at LCA, so I do want it to be generally applicable. > > The changes committed to date do not include installing, and do not > > include anything to support the backend changes in the various languages > > to set their search paths appropriately. It also does not handle any > > reverse dependencies (Ruby-GTK+ depends on GTK+, etc). Install support > > only requires an extension to the interface and a couple of insertions at > > the beginning of Compile and InstallPackage. Installation should be a > > transparent process to the user. > > What do you mean by reverse dependencies? "Normal" dependencies? Dependencies from alien packages on system packages. RubyGems:Ruby-GTK+ depends on GTK+, and so forth. I may just ignore them for the time being and require listing GTK+ as a direct dependency of the recipe. -Michael
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ gobolinux-devel mailing list gobolinux-devel@lists.gobolinux.org http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
