On Thu, 2007-10-18 at 01:27 -0500, Ryan Schmidt wrote:
On Oct 18, 2007, at 01:16, Anders F Björklund wrote:
Randall Wood wrote:
I like the idea of a server part in php as it's easy to code and maintain. For the client I would prefer ruby, because it's installed on each mac and is very powerful in parsing the port output and also easy to read. But that's a detail we can work out later.
BTW, I use the built-in php that comes with OS X for scripting myself...
I would go for python since (cool sexy feature in 10.5) XCode 3 knows what it is, Apples supports Cocoa in Python (if I read it correctly) and it has shipped with OS X in one form or another for a while.
Why not Tcl ? (apart from the total lack of sex appeal, that is)
Right. I don't know Ruby or Python and am not planning on learning them at this point. Would be unfortunate to introduce yet another language one has to learn to contribute to MacPorts. IMHO PHP would be ok, since we already use that for the web site. But my opinion may be influenced by the fact that I already know PHP very well and already use it for web sites and command-line scripts. But Tcl would also be a good choice given the rest of the project's source.
It also makes evaluation much easier if we don't need to parse the output of port(1) but use the API instead. The parsing approach will break every time someone fiddles with the logging stuff in port(1). Using the API would also make it much easier to build ports "in order", that is if the dependency chain is like A -> B, the best approach would be to build B then A. Otherwise the output of B will be missing. Someone knows the state of the "chroot-build"? This would make building all ports much easier as it wouldn't be necessary to remove all ports before building another one. -Markus -- Markus Weissmann http://www.mweissmann.de/ http://www.macports.org/