NonTcl Portfiles

George Armah armahg at
Sun Jul 20 16:27:24 PDT 2008

Jordan K. Hubbard wrote:
> Now you're just talking crazy talk, George! :-)
> Seriously, we we have looked at this a few times in the past (in 
> response to the "everyone hates Tcl" as well as other concerns) and 
> debate generally seems to polarize around two positions:
> A)  Tcl, with its simplistic and context-sensitive syntax, is already 
> far more of a textual format than a structured language.  Just make 
> the various verbs and nouns in the macports infrastructure a bit more 
> descriptive, clean things up here and there, done:  A description 
> format that's 90% "option value" and 10% high level functions that 
> could read more like english if that was really the goal (Note:  I 
> just made those numbers up - it could be substantially more options 
> and less functions with certain design decisions).  No need to create 
> yet another "user friendly" description format.
I did notice that whilst reading the guide. The portfile itself IS very 
self descriptive. In fact i'm a sure some of the Tcl apprehension stems more
from the fact that newcomers will be encountering the language for the 
first time, rather than from any actual "difficulty" in the portifile 

> B) Tcl is totally NOT machine readable by anything but a Tcl 
> interpreter, something which makes data harvesting and/or mass-changes 
> across the ports collection really really painful.  It is time for 
> Portfiles to be written in XML with a proper DTD!  We can use 
> translators to get to and from a human readable format when and if 
> editing is actually required, so don't be such a bunch of sissies, 
> running away every time the letters X, M and L are mentioned together!
> Since no battle like that can ever truly have a clear winner (they're 
> both "right" for some value of "right"), we generally decide in the 
> end to just leave things alone, which is probably the right decision 
> for this iteration of MacPorts.   If we ever do see such a sweeping 
> change of the collection, I think it will be because someone decides, 
> one day, to write MacPorts "3.0 or later" completely from scratch.   
> New Portfile syntax, new infrastructure to go with it, and probably 
> some monster Perl script (in Perl6, of course) which manages to 
> convert some significant percentage of the old ports into the new format.

So basically it would be a hefty change requiring lots of time and 
resources. I get that. The driving factor behind my suggestion however was
getting more people to contribute to the project. From your comments, 
allowing more than one file format  does not seem like a good

I just started reading more on MacPorts Web Application. Its goals are 
exactly what I had in mind when made this suggestion :).
I guess this thread can end  and hopefully we'll have  something up and 
running after SoC.

Thanks for enlightening me on the Tcl argument though,


> - Jordan
> On Jul 20, 2008, at 3:38 PM, George Armah wrote:
>> (First two attempts at sending this email failed. Hope this one works)
>> Hello,
>> I was reading through the Portfile Development section of MacPorts Guide
>> and an idea occurred to me.
>> It has been mentioned before that having Tcl as MacPorts' base language
>> does shy away some potential developers and port contributers / 
>> maintainers.
>> The Basic Portfile example (or some variant of it) looks like something
>> that could easily be typed in a plain old text file. Would it be 
>> possible to create a Tcl
>> tool that parses Portfiles that are in for example .txt file formats? 
>> The exact format of the text in
>> the file would probably be different from the current Tcl portfiles 
>> (and hopefully simpler as a
>> result).
>> That way potential port maintainers who don't know any Tcl won't shy
>> away from contributing and maintaining ports.
>> I myself don't know too much Tcl (but am willing to learn) and currently
>> have my hands full with GSoC. I'll however be willing to work on such 
>> a project after
>> summer is over if I have some help getting started.
>> Let me know if this idea sounds feasible or if there is already such a
>> tool out there which I didn't know about,
>> Thanks,
>> George.
>> _______________________________________________
>> macports-dev mailing list
>> macports-dev at

More information about the macports-dev mailing list